• AI agents are stateful, long-running, and mostly idle — the opposite of the microservice model.
• The actor model maps to that shape exactly: state encapsulation, async messaging, location transparency.
• Two independent projects — Dapr Agents and Google's Agent Substrate — converged on actors from opposite ends of the stack. That convergence is a signal.
• You don't need a specific framework. LangChain + Dapr, C# MAF + Dapr Actors, Python + Workflows — the model travels. The framework is the implementation detail.
The wrong execution model
Most teams reached for microservices when they started building agents. Containers, Kubernetes, one pod per agent, stateless REST. It works in demos.
It breaks at scale because agents aren’t microservices:
- They’re stateful. Conversation history, tool call logs, task context — this state needs to survive between turns, not get rebuilt from scratch on every request.
- They’re long-running. An agent interaction is seconds or minutes of elapsed time, not milliseconds. It’s orchestrating tool calls, waiting on LLM output, pausing for human approval.
- They’re almost always idle. The majority of that elapsed time is waiting — for the LLM to generate the next token, for a human to approve an action, for an external API to respond. Keeping a full pod warm for each idle agent is economically indefensible at scale.
The right model already exists. It was built for this shape of work fifty years ago.
The actor model
Carl Hewitt proposed it in 1973, in a paper titled A Universal Modular Actor Formalism for Artificial Intelligence. He was building it for AI tasks. Its return here is less a revival than a correction.
Three rules:
- Each actor owns its own state — nothing outside can read or write it directly.
- Actors communicate only by passing messages asynchronously — no shared memory, no locks.
- On receiving a message, an actor can: update its state, send messages to other actors, create new actors.
These rules map onto the three problems agents have:
| Agent problem | Actor solution |
|---|---|
| State must survive between turns | Actor owns its state; runtime persists it when idle |
| Collaboration without blocking | Async message passing; mailbox absorbs bursty load |
| ”The agent should exist” even when not running | Location transparency — actor identity is decoupled from execution |
That third property is where the infrastructure problem gets solved. If an actor exists logically regardless of where it’s executing physically, you can suspend it, store its state, and resurrect it on demand. That’s not a hack. That’s the model.
Two independent proofs
The clearest signal that the actor model is the right primitive: two teams arrived at it independently, from opposite ends of the stack.
Application layer — Dapr Agents (GA, March 2026):
- The Floki framework (built on Dapr by Roberto Rodriguez) was donated to the CNCF Dapr community in March 2025.
- Twelve months of hardening with NVIDIA later, Dapr Agents v1.0 shipped at KubeCon Amsterdam.
- Idle actors unload from memory. State persists to a pluggable state store (Redis, Cosmos DB, Postgres, 30+ backends). Re-activation at tp90 ~3ms.
Infrastructure layer — Agent Substrate (Google, early dev):
- A Kubernetes extension that multiplexes logical actors onto a small pool of worker pods via gVisor kernel snapshots.
- 250 actor sessions across 8 worker pods. 90% reduction in CPU and memory resource requests. Cold-wake under 25ms.
- Not production-ready — the GitHub repo is explicit. But the architectural proof is clear.
Neither project started knowing about the other. Both landed on actors.
How Agent Substrate works
The core mechanism is dense multiplexing. Rather than one pod per agent, Substrate maps many logical actors onto a small warm-worker pool — suspending idle actors as full kernel checkpoints in GCS, restoring them on demand.
6 logical actors, 3 physical workers. Cold-wake latency ~15ms; warm ~3ms. 30×+ oversubscription — 250 actors on 8 workers in production benchmarks.
The key components:
- ateapi — control plane, actor and worker lifecycle over gRPC
- atelet — per-node DaemonSet, drives
runsccheckpoint/restore, streams snapshots to/from GCS - atecontroller — Kubernetes controller, reconciles
WorkerPoolandActorTemplateCRDs - atenet — DNS, Envoy routing, proxy sidecars — traffic follows the actor when it moves between workers
- ateom-gvisor — executes the actual checkpoint/restore via gVisor’s
runsc
What Substrate proves is that the actor model isn’t just a useful abstraction at the application layer — it’s a schedulable unit at the infrastructure layer. Kubernetes already knows how to schedule pods. Substrate teaches it to schedule actors.
The model, not the framework
This is the point worth sitting with.
You don’t need Dapr Agents specifically. The actor model is the primitive. The framework is an implementation choice. All of these are valid paths to the same model:
- Python + LangChain + Dapr Workflows/Actors — use LangChain for the agent reasoning loop, Dapr for durable execution, state management, and pub/sub between agents
- C# + Microsoft Agent Framework + Dapr Actors + state store — MAF provides the agent orchestration layer; Dapr Actors give you virtual actor semantics and pluggable persistence
- Any language + Dapr Workflows + state store — Dapr’s API is HTTP/gRPC; the agent logic can be written in anything
What you’re committing to in each case isn’t a product. It’s a set of guarantees:
- Agents encapsulate their own state — nothing reaches in
- Agents communicate through messages — coordination is explicit, not shared-memory
- The agent identity is stable — the runtime handles where and when it executes
Teams that internalise those three guarantees can migrate frameworks, swap LLM providers, and onboard engineers from different language backgrounds without relearning the architecture. That’s the actual value.
Where this is heading
The pattern Agent Substrate demonstrates has already appeared in smaller forms:
- Cloudflare Durable Objects — actor-per-entity, hibernated when idle, restored on request
- AWS Lambda SnapStart — JVM snapshot restore to eliminate cold-start latency
- Azure Durable Functions — workflow checkpointing and replay
Agent Substrate is the Kubernetes-native version of the same idea, extended to arbitrary containerised processes via gVisor. When this stabilises (and it will), the actor model won’t be something you implement in a framework — it’ll be something your cluster does by default.
The teams that will adapt easiest are the ones who already think in actors. Not because they picked the winning framework, but because the model their framework taught them is the same one the platform will eventually offer for free.
The practical read
- Now: pick a runtime that gives you actor semantics — Dapr Actors, Orleans, Durable Objects. The specific one matters less than using one.
- Language: Dapr’s HTTP/gRPC API means your agent code can be in Python, Go, Java, or C#. Don’t let language lock you into the wrong execution model.
- Agent Substrate: watch it, don’t ship it. The proof-of-concept is solid; the production story isn’t there yet.
- The mental model: stateful, async, location-transparent. Once you can describe your agent system in those three terms, the infrastructure decisions get easier.
Carl Hewitt built the actor model for AI in 1973. It took fifty years and a generation of LLMs for AI to find it again. That’s usually a sign the idea was right the first time.
Related posts
- Agents, Routing, Patterns, and Actors — EIP patterns and actor runtimes for multi-agent coordination
- From Process Managers to Stable Agent Workflows — stability and SAGA patterns for production agent systems
- Agents Are Still Just Software — the distributed systems frame for agent architecture
Loading comments...