Most multi agent architectures are one agent wearing several hats, and the hats cost latency.

The pattern is appealing because it mirrors how organisations work. A researcher, a writer, a critic. In practice, splitting a task across several models with the same tools and the same context usually produces the same answer more slowly and more expensively than a single well scoped agent would have.

The test for a genuine split

A split is real when the parts differ in something structural. Not in personality, in capability or authority.

Different tools is a real difference. An agent that can read Salesforce records and an agent that can send email have genuinely different surfaces, and separating them means a compromise in one does not become a compromise in the other.

Different permissions is a real difference, and the strongest one. If one component runs as a user who can only read and another as a user who can write, the boundary is enforced by the platform rather than by instruction.

Different context is a real difference. If one part needs an enormous document and another needs a small structured record, keeping them separate stops the small task from paying the large task's attention cost.

• Real: different tools, different permissions, different context budgets.

• Not real: different personas, different tones, different names in the prompt.

• Not real: a critic agent reviewing the writer agent, both with identical access.

Why the critic pattern usually disappoints

The most common multi agent design is a producer and a reviewer. It underperforms expectations reliably enough to be worth naming.

If the reviewer has the same information and the same model as the producer, it shares the producer's blind spots. It will catch formatting problems and surface level inconsistencies, and it will miss the thing that was wrong for the same reason the producer missed it: neither of them had the information that would have revealed it.

A reviewer becomes useful when it has something the producer did not: a schema to validate against, a permission to check, a second source to compare with. That is not a second agent so much as a verification step, and calling it a step rather than an agent leads to better designs.

The cost nobody budgets for

Every handoff between components is a place where context is lost and latency accumulates.

Passing a summary between agents means the receiving agent works from a lossy compression of what the sender knew. Each hop compounds this. Three agents in sequence is three opportunities for a detail to be dropped, and the failure is silent because each individual handoff looks reasonable.

Latency is the more visible cost. A user waiting on four sequential model calls is waiting several times longer than they would for one, and in an interactive setting that is the difference between a tool people use and one they route around.

• Each handoff loses detail that nobody sees being lost.

• Sequential calls multiply latency and cost.

• Debugging spans components, so no single trace explains the outcome.

What we actually build

The pattern that holds up in Salesforce deployments is one agent with a router and narrowly scoped topics, rather than several agents in conversation.

The router picks a topic. The topic has its own instructions and its own small set of actions. Context stays in one place, there is one trace, and permission boundaries are enforced by the actions rather than by which agent is speaking.

Where a genuine second agent earns its place is when the work leaves the platform: a long running process outside the org, on a different runtime, with different credentials. That is a real architectural boundary rather than a rhetorical one.

The short version

Split on tools, permissions, or context budget. Do not split on persona.

If two components have the same access and the same information, you have one agent and two invoices. Collapse it, keep the router, and spend the saved latency on retrieving better context for the single call that remains.