A team we advised was building a consumer buying assistant to help you switch from different subscription plans or a new company all together. One agent held the conversation, collected parameters from the user, decided which data source to query, ran the math, and formatted a comparison table. It worked in demos. Then it started skipping the table entirely and answering in freeform prose, even when the user had handed it every piece of information it needed.
Their first instinct was that the table tool was broken. It was not. The agent had simply run out of room.
Every agent has a finite budget, and you are spending it
When the budget runs out, the model does not announce it. It starts dropping the least anchored responsibility, which is almost always the one with the weakest instruction attached. In this case that was calling the formatting tool, so it fell back to writing prose, which is the thing language models do by default when nothing else wins.
This is why the fix is rarely a better prompt. You can rewrite the instruction telling it to call the table tool as many times as you like. If the agent is holding six responsibilities and has capacity for four, you are just changing which two get dropped. This failure has a name in our own postmortems, the universal agent trap, and it is one of the most common reasons a working prototype stops working.
Split the work, not the wording
The team eventually restructured around a kitchen. A planner agent works out the answer and gathers the data, like a chef. A voice agent talks to the shopper and never touches a tool, like a waiter. A scribe holds the memory so neither of the other two has to carry it.
That shape matters more than the names. Each agent is defined by its own system prompt and its own tool set, so each one has a scope small enough to actually hold. The voice agent’s prompt ended up roughly a third the length of the original, and it became the most reliable part of the system almost immediately, because talking well is the only thing it has to do.
There is a counterintuitive token benefit too. In a single-agent setup, every tool call means resending the entire conversation plus the tool result back to the model just to produce one reply. Split the work and the conversational agent never resends anything for data collection, because the agent in front of it already saw the message and already wrote the data down.
The part almost everyone misses about child agents
Multi-agent architecture has a reputation for being something you build when you want to look sophisticated. That is backwards. The most valuable thing a child agent does is contain failure.
Consider a conversation carrying forty thousand tokens of context. Your agent calls a tool, gets one parameter wrong, and retries. That retry costs you the whole context again, so a single typo just cost sixty thousand tokens and polluted your main conversation with a visible stumble.
Now put that tool behind a child agent instead. The parent sends something loose, like a plain sentence describing what the user wants. The child agent has its own prompt, its own narrow tool set, and one job, which is mapping that sentence onto the right fields. If it gets it wrong four times before getting it right, none of that touches the parent. From the main conversation’s perspective, it asked for a table and received a table. The struggle happened somewhere the user and the context window never saw.
The buying assistant hit exactly this with their comparison table. The planner was trying to hand-type every value into a tool call with a dozen interdependent requirements, and when any requirement failed, the tool returned nothing, so the voice agent invented prose from memory. Moving the table behind a dedicated child agent that could iterate privately solved a problem that no amount of prompt tuning had touched.
Worth saying plainly, because it confuses people. There is no real boundary between a tool and a child agent. From the calling agent’s point of view it is just a tool in its prompt. If that tool accepts loose instructions within a defined scope, there is an agent behind it, even if it is a single model call.
Three ways to decompose, and how to choose
There are three patterns worth knowing, and most systems end up using more than one.
Staged handoff is when your system controls the sequence and swaps the agent as the conversation moves through defined phases. It works well when the flow really is linear, and it costs you something when a user doubles back, since an agent that no longer holds a tool cannot politely accept information it could have taken two minutes earlier.
Child agents are delegation, described above, and they are the right first move because they generalize. Build one and you have a primitive you can apply everywhere, rather than a fix for one tool.
Handoffs between peers, where one specialist redirects to another that owns its own memory, are the most flexible and the most work to manage. Most teams do not need them yet.
Picking between them is empirical. We have shipped support workflows that run close to fifty steps before returning anything to a user, where latency was measured in hours and the tradeoff was obviously worth it, and conversational systems where a hundred milliseconds matters. The honest answer is that you have to test it and see where each shape breaks. What is not negotiable is that your platform supports all three primitives, because you will be reassembling from them, and that orchestration layer is the piece most teams discover they are missing.
The latency trade is real and worth naming. Splitting agents adds round trips. You are choosing between higher latency and a higher error rate, and for most production systems that is not a close call. This is the same architecture question underneath our agent automation work, and you can see a multi-agent split running at scale in our work with a support platform serving 15,000 brands.
If your agent is dropping steps
That is the symptom worth acting on. Not wrong answers, which usually point at data or schemas, but correct-looking answers that quietly skip a stage of your process. It means the agent is over capacity, and the next fix is structural.
Start by finding the single tool with the highest failure rate and moving it behind a child agent. If you do not know which tool that is, running your agent on a deliberately smaller model will tell you within a day. If the failures turn out to be wording rather than structure, start with the four anti-patterns that rot a system prompt instead.
If you would rather have someone map the decomposition with you, that is the core of our workflow orchestration work, and you can bring the system to the founders.
