Presentation: Actors for Agents: Patterns for Production AI

What happened

At QCon AI Boston (June 2026), a former early Twitter engineer described rebuilding a production agent platform on the actor model. The source here is the talk abstract and summary, not a full transcript.

1. The team started with a prompt-chain framework, glue code and a job queue. It demoed well.
2. Real workloads broke it: agents delegating to other agents, tool calls running for hours, workflows that had to survive process restarts, and users asking follow-up questions about jobs still in flight.
3. The fixes piled up as locks, ad-hoc state machines and recovery code nobody trusted.
4. They rebuilt on actors, treating agents as a distributed system rather than a chain of function calls, and distilled five patterns:
   • Tasks as the one execution primitive, so a chat turn and a long workflow are the same thing.
   • Write-through state, so recovery after a crash runs the same code path as normal resumption.
   • Indirect continuation, so a chain of delegations does not pin a thread or process while it waits.
   • Mutable execution graphs that agents can extend at runtime.
   • Supervision boundaries placed where failures actually happen: tool calls, model calls, rate-limited APIs, restarted workers and redelivered queue messages.

Why it works

An agent run is a long-lived, stateful process that talks to unreliable services. Prompt-chain frameworks assume a short request-response call with state held in memory. Actors fit better because each actor owns its state and only changes it by handling one message at a time, so you get no shared locks. If every state change is written through to durable storage before the next message, a restarted actor just reloads and continues; there is no separate recovery mode to get wrong. Supervisors restart a failed child without taking down its parent, which contains a flaky tool call to one subtree.

The bigger pattern

This is the Erlang/OTP and Akka playbook, plus ideas from durable execution engines like Temporal. None of the primitives are new. What is new is the claim that LLM agents need them by default: model and tool calls fail often, take seconds to hours, and the execution graph is not known up front because the model decides the next step. Static DAG orchestrators struggle with that last point.

What it means in practice

• If your agent state lives in process memory, a deploy or OOM kill loses every in-flight run. Persist state per step, keyed by task id.
• Make tool and model calls idempotent or deduplicated, because queues will redeliver (the same rule as Sidekiq jobs or Kafka consumers with at-least-once delivery).
• Do not hold a worker while waiting on a slow tool. Park the task, store a continuation, and resume on a callback message.
• Draw supervision boundaries around each external dependency so a rate limit retries one step, not the whole workflow.
• Test recovery by killing workers mid-run. If resume and recovery are the same path, this test is cheap and meaningful.