Actor-Model Agents

Problem

If the agents are modelled as a request-and-response conversation, they are pinned to one thread of control and cannot easily run concurrently. If they share mutable state — a common dictionary, a shared queue, a global cache — concurrent reads and writes produce race conditions, and a crash in one agent corrupts state the others were relying on. Ad-hoc locking solves neither problem cleanly: it slows the system down and still leaves failure containment as an afterthought.

Solution

Model each agent as an actor: a process or coroutine with its own mailbox, its own local state, and a message-handler that runs messages in receive order. Agents communicate only by sending messages — directly to a known agent id, or by publishing to a topic (see topic-based-routing). The runtime supervises actor lifecycles, restarts on crash, and routes messages across processes or machines. Pair with role-assignment when agents do have stable personas, and with supervisor when a coordinator is needed.

When to use

• Agents must run concurrently with isolated state.
• The system must survive partial failures of individual agents.
• Communication is naturally event- or message-driven rather than turn-based dialogue.
• The agent population is expected to scale to dozens or more participants.