Multi-Agent Tool Sharing and Delegation — Tool Use, Function Calling & MCP

It is tempting to introduce multi-agent systems as an architecture problem: how do you route work between agents, what protocol do they speak, how many should there be. That framing skips the question that actually decides whether delegation helps or hurts, which is a context question, not an architecture one. A subagent's real product is never the work it did -- it is the compressed result of that work. Six research steps, four file reads, and a dozen tool calls can happen entirely inside a subagent's own window and never touch the parent's context at all, as long as what crosses back is a short, structured summary rather than the trail that produced it.

That is also the reason to reach for a subagent in the first place. The question is not "is this task hard" -- plenty of hard tasks are fine to run inline. The question is "would the intermediate work of doing this task, if it happened in my own context, crowd out everything else I need to keep reasoning about." A task that requires reading fifteen files to answer one question is a textbook case: the parent does not need those fifteen files' contents, it needs the answer. Delegating is how you get the answer without paying for the fifteen files in your own window.

Once that framing is in place, the mechanics turn out to be almost entirely familiar. A subagent is a tool: from the parent's point of view it is one more entry in the tool list, called the same way, returning a `tool_result` the same way. Everything lesson 6 established about writing a description the model actually understands, everything lesson 3 established about a tight input schema, everything lesson 9 established about recoverable errors, and everything lesson 20 established about idempotent, explicit state -- all of it applies to a `delegate_to_researcher` tool exactly as it applies to `search_orders`. This lesson is about what changes when a tool's handler happens to run another full agent loop instead of a database query, and where that similarity stops being enough on its own.

Analogy🏏Cricket

🏏 Think of it like cricket: a Test captain does not personally review every ball of a rival team's last six months of footage before setting a field. He asks the team analyst to do it and come back with three sentences: this batter is weak outside off in the first ten overs, strong through the leg side after that, and has never gotten off strike quickly against a leg-spinner bowling around the wicket. The analyst may have watched forty hours of footage, cross-referenced it against three tours, and argued with two other analysts about a borderline case -- none of that reaches the captain. What reaches the captain is the compressed verdict, because the captain's actual job in the ten minutes before the toss is to hold a field plan and a bowling order in his head, not forty hours of raw footage. If the analyst instead read out everything he'd watched, the captain would walk out to the toss with a head full of footage and no field plan at all. That compression -- forty hours in, three sentences out -- is exactly what a subagent is for. The work happens somewhere else, in its own space, and the only thing that crosses back is small enough that the person receiving it can still think.