7 min read
One agent trying to do everything eventually does everything a little worse. Splitting work across specialized sub-agents fixes that, as long as the handoffs between them do not drop the context that made the first agent's work useful. Get the handoffs wrong and the split creates new problems instead of solving the old one.
One agent trying to do everything eventually does everything a little worse. Splitting work across specialized sub-agents fixes that, as long as the handoffs between them do not drop the context that made the first agent's work useful. Get the handoffs wrong and the split creates new problems instead of solving the old one.
Why Split Into Sub-Agents
A single agent covering scheduling, billing questions, and technical troubleshooting has to hold three different sets of instructions, tools, and tone in one prompt, and it shows: instructions bleed into each other and the agent gets less reliable at all three. A planner-plus-specialist structure, the same shape Agentforce uses with topics and sub-agents, lets each piece stay narrow, well-tested, and easier to reason about on its own.
There is a testing benefit here that is easy to undervalue. A narrow billing sub-agent can be evaluated against a focused set of billing scenarios, and a regression in that sub-agent shows up as a clear, attributable failure. A monolithic agent handling everything makes it much harder to tell whether a regression came from the billing instructions, the scheduling instructions, or an interaction between the two.
Where the Split Goes Wrong
Splitting is not free. Teams that split too eagerly end up with sub-agents so narrow that most real conversations require three or four handoffs to complete a single request, and every handoff is a chance to lose context or add latency. The right granularity is usually coarser than the first instinct: split along genuinely different domains of knowledge and tooling, not along every possible sub-task.
Passing State Without Losing It
The failure mode in multi-agent setups is rarely the individual agents. It is the handoff: a specialist finishes its task and the next agent starts from a blank slate, re-asking the user for information that was already given. Define an explicit handoff contract for every transition: what state gets passed forward, in what shape, and what the receiving agent is guaranteed to have. Treat the shared context object as part of the architecture, not an afterthought bolted on after the agents are already built.
A Concrete Handoff Contract
In a support scenario, a triage agent that hands off to a billing specialist should pass forward the account identifier, a summary of what the customer already said, and any record lookups it already performed, not just a one-line intent label. The receiving agent should never need to ask the customer to remind it what account this is about when the triage agent already resolved that. If your handoff contract cannot answer what specifically gets passed at each transition, that is the gap to close before you add another sub-agent to the graph.
Conclusion
Multi-agent graphs are only an improvement over a single agent if the handoffs are designed as carefully as the agents themselves. Get that right and you gain specialization without losing continuity.
Design the handoff contracts before you design the sub-agents. It is tempting to build the specialists first and figure out how they talk to each other later, but that order tends to produce exactly the context-loss problem this pattern is supposed to solve.