2.3.1. Designing Multi-Agent Solutions
💡 First Principle: The child-versus-connected decision is an organizational decision wearing a technical costume. Child agents suit one team decomposing one solution; connected agents suit multiple teams owning separate solutions. Ask "who builds, ships, and maintains this specialist?" and the architecture answers itself.
Child agents are the lightweight move: they live inside the parent, share its configuration and authentication, and exist to group related tools, topics, and knowledge under a description the orchestrator can route to. They shine when a single agent has accumulated so many similar-sounding tools that routing degrades — the documented pressure point is roughly 30–40+ tools/topics with overlapping descriptions — and the fix is to cluster them into intent-shaped subagents. No separate deployment, no separate ALM.
Connected agents are the federated move: independent agents with their own settings, publication channels, and lifecycles, maintained by whoever owns that domain. Choose them when different teams manage different agents, when a specialist must also be published on its own channels, when it needs independent model or auth configuration, or when it should be reused across several parent agents. Two structural rules to remember: delegation adds an orchestration hop (latency is the tax on specialization), and hierarchy is constrained — an agent that has connected agents cannot itself serve as a connected agent elsewhere, which rules out deep chains and circular wiring.
⚠️ Exam Trap: "One developer, one use case, grouping tools for routing accuracy" → child agent. "Another team maintains it / it ships separately / other parents reuse it" → connected agent. The distractor is always the other one.
Reflection Question: A support agent has 45 tools and its routing has gotten unreliable; meanwhile Finance wants your returns specialist inside their agent too. Which mechanism fixes each problem, and why can't one mechanism fix both?
