Have your people call my people

 

Forwarded this email? Subscribe here for more Agents are actors Multi-agent is actor model Gordon Brander Apr 20   READ IN APP   How should AI agents cooperate? What should a multi-agent system look like? Everyone is trying to figure this out right now. Should our agents be thought of as a team that coordinates over an issue tracker? Are they more like a swarm of bees or ants? Should they be arranged into command-and-control hierarchies of agent and sub-agent? Or should we trust the bitter lesson and bet on one big model? Here’s my take: Agents are actors. Multi-agent is just the actor model. An actor… Receives messages Updates its internal state May spawn other actors And generate messages in response That sounds a lot like an agent! An agent receives a user message, it updates its context, it may spawn other agents, and generate messages in response. It also sounds a lot like Von Foerster’s non-trivial machine, a cybernetic model of the minimal system that can generate agentic behavior: a function that accumulates state through feedback (aka, a reducer). The Non-Trivial Machine, a function with feedback. The minimal definition of agency. Source: Heinz von Foerster, “Understanding Understanding: Essays on Cybernetics and Cognition”. Actors can also be seen as an idealized biological cell. A cell has a membrane that protects its internals. It sends and receives signals that pass through the membrane. It may also occasionally spawn other cells. This cell analogy is what Alan Kay was reaching for when he designed one of the earliest manifestations of Object-Oriented Programming: I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning—it took a while to see how to do messaging in a programming language efficiently enough to be useful)… OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. (Alan Kay in an Email to Stefan Ram, 2003) I have a degree in molecular biology, and one of the things that struck me as I was studying molecular biology, was that, compared to the kinds of structures that we tend to build here on earth, the average biological structure is more than a thousand times as complex… For instance, a grand piano, a rather complex machine, has about 20,000 parts. Our bodies have approximately a trillion cells, and each cell has many millions of components in its own right… One of the ways nature discovered to control complexity, and the kinds of interactions that are likely to happen, is to try and encapsulate them in various ways… What biological systems encapsulate is the environment in which processing takes place… If you give each cell its own captured ocean, and let it devote about 90% of its energies toward protecting itself from the outside world, then you get a situation where you can build very large structures rather safely. (Alan Kay, OOP talk) Wassily Kandinsky, 1938, “Entassement réglé” If each agent is a cell, how can we make the jump to multicellularity? OOP never properly made this jump, and it never attained the sublime levels of biological complexity that Kay envisioned. This is because mainstream OOP languages had fatal design mistakes that broke compositionality. Actors fix this. There are multiple formal mathematical models that let us reason about actor composition at scale. To scale up our multi-agent systems, we could borrow some ground rules from actors: Strong encapsulation: Actors never share state. They are strongly-encapsulated black boxes. Information sharing happens exclusively through sending messages. State machines: Messages that get sent to an actor’s inbox are processed one at a time, sequentially, resulting in discrete state updates. Concurrent messages: Actors process messages sequentially, but the messages themselves are sent and received asynchronously. Location transparency: Because messages are sent asynchronously, sending a message to another actor looks the same whether the actor is running locally, or remotely on another computer. These qualities make it very easy to parallelize actors. You don’t have any of the problems of shared mutable state, because there is no shared mutable state. The system can scale horizontally, from one process to many, and from one computer to many. Designing our agents as actors lets us spin up lots of parallel agents. Now what? How should these swarms of agents interact and be structured? Here too, the actor model offers useful patterns: Supervisor trees: parent actors manage children, handling any failures by restarting them, stopping them, or escalating the failure up the tree. Request-response: short-lived actors get spawned to perform a request. They respond with the result, then die. Become: an actor replaces its own message-handling behavior based on reaching. a state, effectively becoming another actor. Scatter-gather: A coordinator sends queries to N actors in parallel, collects their replies, and produces an aggregated result once all have responded or a timeout fires. Routers and worker pools: a router actor parallelizes work by distributing incoming messages to a pool of identical worker actors using round-robin, random, smallest-mailbox, etc. Aggregators: collect related messages over time, then emit a combined result once a condition is met. This is just a sample of the patterns that emerge naturally from the actor model. It is pretty easy to imagine how they might be useful in a multi-agent system. Some of them are already common: scatter-gather is used for Claude Code’s Explore agents, and prompt resolvers are a riff on the become pattern. Actor agents could allow us to run hundreds of parallel agents on a computer, or thousands across load-balanced servers, or even millions of agents across the whole internet. With location transparency, “Have your agent call my agent” and “have your factory call my factory” become essentially the same move. Furthermore, if every agent signs its messages with a public key, we get a decentralized protocol for massively multi-agent systems. Signed messages give us the basis for untrusted coordination between agents. Because signed messages are non-repudiable, we can begin to accrue cryptographically-verifiable reputations for specific agents, and distribute those reputations through webs of trust. Our agents can decide whether to interact with another agent based on the agent’s reputation. It is also pretty easy to imagine how we might extend such a decentralized agent protocol to enable end-to-end encrypted communication between agents. In the actor model, actors send messages directly to other actors using an address, so just encrypt the message, and send directly to the other agent’s address. The implementation for such a protocol could be very simple. Sign JSON with an agent-controlled key, send it over the wire. For the details, I would be inclined to borrow from Nostr for message signing, ATProto for DID-based signing and key rotation, and UCAN for delegating authority from user to agent to sub-agent. But in many ways, this protocol problem is simpler than the problem of decentralizing social media. Actor communication is point-to-point, rather than broadcast, so it’s a good fit for HTTP. In its most basic incarnation, an agent could be a URL, its address could be a POST request to that URL, and messages could be signed with a JWT. Reflecting on this, I feel like I can begin to see the shape of a new internet, something that may supersede the web: the internet of agents