Multi-agent systems in production: split by responsibility, not by task
The common wrong split: an agent that searches, an agent that summarises, an agent that writes. These are not agents, they are functions with grand names, and every hop between them adds cost and latency along with one more chance of error.
The split that worked
By responsibility:
One agent per channel. A channel has its own rules: short on a messaging app, formal over email. The channel is context that changes behaviour, which is why it earns an agent of its own.
One agent per document type. A contract reader knows what a contract looks like and knows nothing about conversations.
One agent for the human decision. It collects what the others produced and puts it in front of a person to approve. There is no intelligence in this piece at all; it is a gate, and it is the most important piece in the system.
The test I apply to any split
If two agents share the same inputs and the same constraints, they are one agent.
Where the time actually goes
The agents' "intelligence" took very little of it. Most of the work went into three places:
- State between them: where the conversation is stored and who owns it, and what happens if one dies mid-flight.
- Boundaries: what no agent is permitted to do, however reasonable it looks.
- Recovery: what happens when the gateway returns an error.
All three are ordinary systems engineering questions, and they decide whether the system runs in production or only in the demo.
Related reading
Tell me what you want to build. Your first 15 minutes of consulting are free.
Book a consultation