Actor Model Underneath Agentic AI

🎯

In May 2026, Google released google/ax, a distributed agent runtime. The README never says "Akka" or "Erlang." Yet lines 60–63 carry this sentence:

"tools, skills and agents are deployed as isolated actors, a distributed runtime with dynamically spawned isolated workers becomes a necessity."

Google does not call it the actor model — but AX's design is exactly the model Carl Hewitt defined in 1973 and Erlang popularized. No surprise. Take agent orchestration seriously and the design converges on the actor model.

(Companion piece: the Korean original of this article is also published on this workspace.)

🌐

한국어 원문:

에이전틱에 액터모델, 놀랍지 않다 · Sister piece (Akka.NET port):

Building LLM Agents in Akka.NET — Porting Akka.io's Agent SDK to the Actor Model

This essay traces why that convergence is not an accident. The intended reader is a global IT engineer who has heard of the actor model but quietly wonders, "Is anyone still using it?"

📊

[Image #1 — Agentic AI standing on the actor model] Hero card visualizing Google AX's "isolated actor" metaphor.

File: 2026-05-24-agentic-actor-hero.png

1. The actor model never disappeared — it just became invisible

🎯

3-line summary

The actor model was first formalized by Carl Hewitt in 1973 and popularized through Erlang.

"It's out of fashion" does not mean it died — it means the model became so default that nobody mentions it anymore.

Chat servers, IoT platforms, financial trading engines, game backends — the systems we touch every day already ride on it.

The actor model fits in three lines.

An actor is a unit of concurrency that encapsulates state and behavior.

Actors only talk through messages. No shared memory, no locks.

Each actor owns a mailbox (message queue) and processes one message at a time.

📊

[Image #2 — Actor model fundamentals] Actors with mailboxes exchanging messages without shared memory.

File: 2026-05-24-actor-model-basics.png

Why does this win at distributed systems? Borrowing from the Akka literature Memorizer: Akka Actor Model — Core Concepts, the answer is location transparency. Whether an actor lives in the same process or on a remote machine, the code that sends it a message is identical. The model does not "treat remote like local" — it assumes everything is remote and optimizes some calls back to local. As the Akka.NET notes put it Memorizer: Akka.NET — Distributed Actor Framework, this is the right direction and the reverse — "generalize local to remote" — is the path that is bound to fail.

One myth to put down: people said for a while that "the actor model is over." The opposite is true. Erlang/OTP has held up telecom infrastructure since 1986. Akka runs JVM-side chat and game backends at Kakao, LINE, and several Korean game studios. Microsoft has Orleans. JavaScript has Vert.x. The cloud has Elixir, Erlang's modern descendant. The model did not leave — it slipped down into infrastructure where you stop noticing it.

2. Tyler Jewell's read — agentic systems are distributed systems

🎯

3-line summary

MIT (2025): 95% of AI projects fail to hit their expected outcomes. S&P Global reports the abandonment rate doubled from 17% to 42%.

Akka CEO Tyler Jewell's diagnosis: the failures are not failures of imagination — they are failures of infrastructure engineering.

Agentic systems are distributed systems, and the same problems distributed systems solved long ago (queue saturation, node crashes, retry storms, distributed debugging, time-spanning workflows) come right back.

Tyler Jewell, Akka's CEO, wrote a 2025 piece Memorizer: Agentic AI: Why Experience Matters More Than Hype whose core point is simple. While LangChain was carrying a $1B+ valuation on under $15M ARR, the teams that actually pushed agentic systems to production were saying — quietly — "this doesn't hold up."

The reason: agentic systems are a different class of distributed system from chatbots and request/response functions.

Dimension	Traditional system	Agentic system
State	None (stateless)	<strong>Long-lived (stateful)</strong>
Time scale	Request/response (ms–s)	<strong>Minutes / hours / days</strong>
Determinism	Deterministic	<strong>Stochastic (LLM)</strong>
Side effects	Pure data	<strong>Email, payment, infra changes</strong>
Resources	Uniform CPU	<strong>CPU + GPU mix</strong>

Tyler argues the same problems Akka has fought for fifteen years — queue saturation, node crashes, retry storms, distributed debugging, workflows that span time — show up again in agentic systems. And the solutions are already on the shelf: bounded mailboxes, event sourcing, circuit breakers, supervision hierarchies, durable resumable processes. The standard toolbox of the actor-model ecosystem.

At this point, calling the actor model a candidate for agent orchestration understates it. It is closer to a default answer, and the burden of proof shifts to anything else.

3. Why all four big platforms are actor-model

🎯

3-line summary

Google AX, Akka Agents, Microsoft Orleans, Ray Serve — every major Agent Orchestration platform that emerged in 2025–2026 is either actor-based or actor-shaped.

The shared traits are (1) isolated workers, (2) message-based communication, (3) durable state, and (4) location transparency.

"Why the actor model?" is the easier question. "How would you do this with anything else?" is the genuinely hard one.

📊

[Image #3 — Four platforms converging on the actor model] From a central core, five branches (AX · Akka · Orleans · Ray · Temporal) radiate out.

File: 2026-05-24-four-platforms-convergence.png

3.1 Google AX — calls them "isolated actors," still actor model

Here is the AX README diagram in text form.


graph LR
    Client --> Router
    Router --> Controller["AX Controller<br/>(executor, event log, registry)"]
    Controller <-->|resumable stream| RemoteAgent["Agent<br/>(isolated actor)"]
    Controller --> Env["Environment<br/>(isolated actor)"]
    Controller --> Tool["Tool<br/>(MCP server)"]

Five design decisions translated into actor-model vocabulary:

AX term	Actor-model counterpart
Controller	ActorSystem + Supervisor
Remote Agent / Environment (isolated actor)	Remote Actor + Sharding
Event Log	Event Sourcing (equivalent to Akka Persistence)
Resumable Stream	Mailbox + retryable delivery
Single-Writer Architecture	Actor's single-threaded per-actor execution

AX uses a single controller for consistency, an event log for recovery, and replays the log on restart to resume from the last committed step. This is almost 1:1 with Akka Persistence's EventSourcedBehavior.

3.2 Akka Agents — the original, going straight

Akka is the actor model, and the Akka Agents lifecycle Memorizer: Akka Agents — Structured Agent Development Platform — Context Gathering → Reasoning → Action Taking → Progress Evaluation — is a four-state FSM living inside one actor.


@ComponentId("activity-agent")
public class ActivityAgent extends Agent {
    public Effect<String> query(String message) {
        return effects()
            .systemMessage("You are an activity agent...")
            .userMessage(message)
            .thenReply();
    }
}

An Akka Agent receives a message, calls the LLM with system + user prompts, and replies. That is the actor itself. When the agent reaches out to a tool, an Akka Workflow — a durable process backed by Akka Persistence — records each step in the event log so another node can pick up exactly where a crashed one left off. This is the prototype Google AX's "resumable execution" is patterned after.

3.3 Microsoft Orleans — one virtual actor per agent

Orleans pioneered the Virtual Actor flavor of the model. A normal actor is created and destroyed explicitly; an Orleans Grain conceptually always exists. It activates on first access, deactivates when idle, and re-hydrates from persistent storage the next time anyone reaches for it.

That maps almost perfectly onto agentic systems. One persistent conversation agent per user. One RAG agent per enterprise tenant. You map one entity to one actor. When the user base grows, you add nodes to the silo cluster. Microsoft Agent Framework's 2026 release on both .NET and Python made running agents on Orleans a standard option rather than a niche choice.

3.4 Ray Serve — Python's distributed actors

Ray is the same Ray OpenAI used to train GPT-3 and GPT-4. A class decorated with @ray.remote becomes an actor distributed across the cluster. Anyscale's AI agents on Ray Serve: Single to multi-agent architecture shows a clean pattern:

LLM inference is a GPU actor that scales independently.

Tool calls are CPU actors that scale independently.

Routing and memory are yet another actor.

Each actor scales and rolls out separately. Exactly the distributed-systems answer Tyler Jewell points to — bounded queues, isolated failure domains, independent capacity planning.

3.5 Temporal — the durable-execution sibling

Temporal and Cadence are usually classified as deterministic workflow engines (durable execution) rather than strict actor systems. But the mapping one conversation = one workflow instance is, in spirit, identical to Orleans Grain or Akka's EventSourcedBehavior. The unit of work encapsulates state, communicates through messages (signals), and recovers automatically. OpenAI's VP of Application Infrastructure has gone on the record: "Temporal's durable orchestration framework is critical to handling our massive scale, complex agentic workflows." That is the production validation of this whole family.

3.6 The shared denominator

All five platforms collapsed into one table:

Platform	Core unit	Communication	Durability	Location transparency
Google AX	Isolated Actor	Resumable Stream (gRPC)	Event Log	⭕ (Kubernetes)
Akka Agents	Agent + Workflow	Message + Effect	Event Sourcing	⭕ (Cluster)
Orleans	Grain (Virtual Actor)	RPC	Storage Provider	⭕ (Silo)
Ray	@ray.remote Actor	Message	Externalized	⭕ (Cluster)
Temporal	Workflow Instance	Signal/Query	Event History	⭕ (Worker)

Five columns, all checked. If you try to satisfy all five with a non-actor distributed model, you end up reinventing something that looks like an actor system anyway. That is the heart of "actor model under agentic AI — no surprise."

4. Does the actor model fit single-machine agents too? — AgentZeroLite

🎯

3-line summary

The actor model is natural even for small agents running on one personal computer, not just at orchestration scale.

AgentZeroLite implements an on-device LLM toolchain on Windows using WPF + Akka.NET — actor model end to end.

On a single machine, the model still earns its keep for (1) separating UI / LLM / terminal, (2) modeling the agent loop as an FSM, (3) isolating per-workspace state.

📊

[Image #4 — Nested actor topology inside a single desktop] AgentZeroLite's five-level actor hierarchy visualized as concentric layers inside a Windows chassis.

File: 2026-05-24-agentzerolite-single-machine.png

At orchestration scale, the actor model is intuitive. But what about a small agent that only ever runs on one PC?

The hypothesis I explored in my own earlier essay — the sister page to this one on the same workspace,

Building LLM Agents in Akka.NET — Porting Akka.io's Agent SDK to the Actor Model — was yes, even on a single machine the actor model pays for itself. The concrete proof of that hypothesis is D:\Code\AI\AgentZeroLite.

Actor topology

From AgentZeroLite's CLAUDE.md:


/user/stage                  StageActor      — supervisor + message broker
    /bot                     AgentBotActor   — UI gateway: chat/key mode,
                                                peer routing, intro tracking.
                                                Spawns AgentLoopActor lazily.
        /loop                AgentLoopActor  — THE agent: owns one IAgentLoop,
                                                drives Idle→Thinking→Generating→Acting→Done FSM.
    /ws-<name>               WorkspaceActor  — one per workspace (folder)
        /term-<id>           TerminalActor   — wraps one ITerminalSession

Five places the actor model earns its keep on one machine

1. Separating UI, logic, and external resources. WPF's UI thread is single-threaded — drop a long LLM call or a ConPTY terminal onto it and it freezes instantly. Hand the work to an actor system and the UI only sends a message, then receives a callback (via AgentEventStream / SetBotUiCallback).

2. The agent loop is an FSM. Agents cycle through think → call tool → consume result → think again. With Akka.NET's FSM trait, the five states Idle → Thinking → Generating → Acting → Done line up exactly with five Receive handlers inside one actor.

3. Workspace = actor. Every folder a user opens spawns a WorkspaceActor, and the terminal tabs inside it become TerminalActor children. If one terminal crashes, the other workspaces don't notice. That is the supervision-tree isolation property in action, at desktop scale.

4. Messages are already the durability unit. All message types live in one Messages.cs file. Serialize those into SQLite (agentZeroLite.db) and you have an event log. The same pattern as Google AX's Event Log and Akka's EventSourcedBehavior — only the scale differs.

5. Future expansion = adding nodes. AgentZeroLite's PRO roadmap extends into AgentZeroRemote → AgentZeroCluster. Possible because the model is already actor-shaped. The same code that runs on one machine moves to a cluster with minor changes. Location transparency pays the future bill.

The takeaway

AgentZeroLite's purpose is on-device open-model leverage, not orchestration. It still chose the actor model for one reason: a Windows desktop is itself a small distributed system (UI thread + LLM worker + terminal processes), and the actor model is the cleanest way to handle it. The degree of distribution differs. The shape of the problem does not.

5. Closing — the value of "the obvious"

In April 2026, OpenAI announced the next Agents SDK Memorizer: OpenAI Agents SDK — Next Evolution Briefing with the headline framing of "harness/compute separation." Translate that back into actor-model vocabulary and you get control plane (harness) decoupled from workers (compute), with execution that survives via durable state. That is what Akka has done for 15 years and Erlang for 40.

Google AX introduces itself as a "distributed agent runtime" and pointedly avoids the word "actor" in its README. Why?

One hypothesis: it has become so taken-for-granted that flagging it is unnecessary. Distributed databases don't advertise "we honor ACID." A distributed agent runtime has arrived at the same point — "we use the actor model" is no longer a feature to brag about. The single label that did survive — isolated actor in the README's mermaid diagram — is, on this reading, deliberate restraint.

Another hypothesis: branding distance from the Erlang/Akka lineage. Even if true, lines 60–63 of that README — "agents are deployed as isolated actors" — quietly admit the design choice while keeping the lineage out of view.

🏁

Either reading lands on the same conclusion. The future of agentic AI is sitting on the actor model. For a global IT engineer the practical takeaways are simple.

When evaluating an agent orchestration tool, score it on four axes: isolation, messaging, durability, location transparency. The essence shows quickly.

Pick the actor system your stack already prefers — Akka for JVM/Java/Kotlin, Orleans / Akka.NET for .NET, Ray for Python/AI, Temporal when the workload is workflow-shaped. Battle-tested tools beat clever new wrappers.

Even a single-machine agent, if it may go distributed later, costs less to write actor-shaped from day one than to migrate later.

The actor model did not "come back." It never left. Now it's stepping up to the stage one more time, under a different banner — agentic.

Editor's intent map (for translators and reviewers)

A short table connecting Korean source intents to English rendering choices, included so future reviewers can audit the translation rather than guess.

Korean intent	English rendering	Reason
"놀랍지 않다" (a quiet, slightly dry "of course")	"No surprise" + closing "either reading lands on the same conclusion"	Avoids the more hype-flavored "Of course it is!" — keeps the cool senior-engineer voice
"한물갔다 / 사라진 게 아니라 너무 당연해진"	"never disappeared — it just became invisible"	Same dual point as the original without idiomatic loss
"카카오톡 채팅 서버…"	"chat servers, IoT platforms…"	Translated to globally recognizable categories rather than Korean-only brands
"이거 CLI보다 어렵습니다" register	(intentionally not used — Korean-only color)	EN version stays slightly more formal to land with a senior global audience
"마치며"	"Closing — the value of 'the obvious'"	"Closing" reads naturally in EN; "마치며" is a Korean convention not 1:1 translatable