The more I learn about actor systems and AI agent architecture, the more they remind me of how offices work: where people have separate inboxes, managers route tasks, teams hold their own context, messages move across departments, some requests get lost, and someone somewhere has to know who owns what.
In an actor system, each actor is an independent worker. It has its own state, its own inbox, and its own job. You send it a message, it handles that message, and it may then send messages to other actors.
That already sounds like an office.
The finance team doesn’t need to know exactly where legal sits. It sends the request to legal, and legal handles it. If legal moves from floor three to Slack to another country, the workflow should still work.
That is location transparency. The sender doesn’t need to know where the receiver lives; it just needs a reliable way to send the message.
In software, that actor might be running locally on your machine, on another server, or somewhere in a cluster. The useful part is that the code talks to it the same way either way. You build the logic once, and the system handles where the work happens.
Healthy offices work like this too.
You don’t rebuild the business every time someone changes desk, department, city, or reporting line. You preserve the message flow, the responsibility, and the contract between teams.
The gossip protocol follows the same pattern.
In distributed systems, gossip is how machines share updates across a cluster. One node tells a few others, those nodes tell a few more, and eventually the system has a shared understanding of who is alive, who has failed, and where work should go.
Every company runs on gossip protocols. Some are formal, such as standups, status docs, dashboards, and weekly updates. Some are informal, such as someone saying, “Sarah has moved to the platform team,” or “Don’t send that to procurement yet, because they’re backed up.”
Back pressure works the same way.
In software, back pressure happens when a system slows incoming work because the downstream part can’t keep up. Without it, queues grow, memory rises, and things break.
In an office, good managers apply back pressure all the time. A team gets too many requests, so the manager slows intake, pushes back on deadlines, rejects low-value work, or asks leadership to choose.
Bad managers do the opposite. They keep accepting work, forward everything downstream, and act surprised when the team burns out.
A dead-letter queue is also familiar.
In actor systems, a dead-letter queue captures messages that couldn’t be delivered. The target actor may no longer exist, the route may be broken, or the message may have expired.
In office life, dead-letter queues are the abandoned tickets, unread emails, stale Notion comments, orphaned Slack threads, and “circling back on this” messages that nobody owns.
They’re useful because they show you where the system thought responsibility existed, but where it’s actually disappeared.
Even idempotency has a workplace version.
An idempotent operation is something you can safely repeat without making a mess. “Set this customer’s status to active” is safe to retry. “Charge this customer £50” needs more care because running that action twice creates a different outcome.
Office work has the same problem.
“Send the client the latest policy” can be repeated without much damage, while “approve the invoice,” “publish the article,” or “email the entire customer list” needs more protection. If the same instruction runs twice, the system may create duplication.
This is why agentic AI needs more than smart prompts.
Once you have agents handing work to other agents, calling tools, retrying failed jobs, and making decisions across a workflow, you’re building a small organisation.
The agents need inboxes, ownership, state, handoff rules, safe failure modes, workload controls, and records of undelivered work.
The funny thing is most companies already understand many of these ideas, even if they don’t use distributed systems language.
A good office knows that people need protected state. A good manager knows that throughput drops when every request is treated as urgent. A good operations lead knows that work needs routing, retry rules, escalation paths, and ownership. A good executive knows that a system can look functional while messages are dying in the walls.
That’s why actor systems are such a useful mental model for AI agents.
They stop us from thinking of agents as magical assistants floating in isolation, and instead think of them as workers inside a communication system. Once you see it that way, the questions get better.
- Who owns this task?
- Where does this message go?
- What happens if the receiver is busy?
- What happens if the receiver disappears?
- Can this action be safely retried?
- How do we know when work has failed?
- How do we stop one overloaded actor from dragging the whole system down?
Those are software questions, but they are also management questions.
As AI systems become more agentic, the companies that understand both sides will build better systems than the ones still pretending agents are just chatbots with tool access.