![\"\"](\"https:\/\/sqlhammer.com\/wp-content\/uploads\/2026\/05\/t-shaped-agents.png\")
<\/figure>\n\n\n\nThe Handoff Is the Failure Surface<\/h2>\n\n\n\n
Multi-agent systems fail in production between 41% and 87% of the time, and roughly 79% of those failures trace to coordination and specification rather than model quality (Maxim<\/a>, Future AGI<\/a>). Inter-agent misalignment alone accounts for nearly 37% of the total: communication breakdowns, context lost in transit, format mismatches, conflicting outputs. The model is rarely the problem. The seams between models are.<\/p>\n\n\n\n Each handoff is a lossy compression step. Agent A holds a rich working context; it passes a message rather than that context to Agent B; Agent B treats the degraded summary as ground truth and builds on it. Redis calls this a “high-tech telephone game,”<\/a> and the metaphor is exact. Errors do not stay local. They compound downstream and surface three stages later as symptoms with no stack trace to follow.<\/p>\n\n\n\n Cognition, in “Don’t Build Multi-Agents,”<\/a> names the mechanism underneath: actions carry implicit decisions, and conflicting decisions produce broken results. Their illustration is a parallel build where one subagent renders a game background in one visual style while another builds a character that clashes with it; neither agent saw the other’s assumptions, so the outputs collided at integration. Their prescription is a single-threaded agent operating on one continuous context. One worker. One unbroken picture of the task.<\/p>\n\n\n\n The fix is not a new idea. It is a thirty-year-old one.<\/p>\n\n\n\n The T-shaped model describes broad competence across many areas with deep expertise in one. It originated at McKinsey in the 1980s and was popularized by IDEO’s Tim Brown<\/a>. Agile software organizations adopted the same shape under a different name, the generalizing specialist<\/a>: the engineer who goes deep in one discipline but carries enough range to bridge the others. The rationale never changed. Pure specialists create coordination bottlenecks and become single points of failure; pure generalists lack the depth to do hard work well. The T-shape holds the middle, and it holds the whole picture without a handoff.<\/p>\n\n\n\n A T-shaped agent is the same construct rebuilt in software. Broad working knowledge, depth in the task at hand, and one continuous context window that never has to survive a translation step.<\/p>\n\n\n\n This does not argue for one agent doing everything. The honest counter-evidence is real, and it draws the line.<\/p>\n\n\n\n Anthropic’s multi-agent research system beat its single-agent baseline by more than 90%<\/a>, but the win came specifically on wide-and-shallow work, where the advantage is parallel reasoning across more aggregate context than one agent can hold. Searching a hundred sources at once is genuinely parallel; the subtasks are independent, and the contract between them is small enough to write down. Deep-and-narrow work is the opposite. Coding, long-form writing, debugging: these demand memory consistency and logical coherence that a single continuous context preserves and a pipeline destroys.<\/p>\n\n\n\n The boundary is the decision. Split the work when the subtasks are genuinely independent and the handoff contract is small. Keep it in one agent when the work has to hold a single coherent picture.<\/p>\n\n\n\n In my own practice that line is concrete. I folded code review and quality assurance into one agent because the two share most of their context; running them separately only rebuilt the same understanding twice and forced a handoff between them. My DevOps agent owns the entire adjacent territory: infrastructure, infrastructure as code, project builds, and CI\/CD pipelines. Those concerns are continuous, not independent. A change to the build affects the pipeline; a change to the infrastructure affects the code that provisions it. One agent holding that whole surface reasons better than four agents negotiating across it.<\/p>\n\n\n There is a hard limit, and it has nothing to do with performance.<\/p>\n\n\n\n Consolidate purposes far enough and a single agent accumulates system access that should never sit in one place. The capability argument says merge the code-writing and the deploy abilities into one efficient worker; separation of duties says do not. A code-writing agent and a production-deploy agent stay apart not because one agent could not perform both, but because the blast radius of a compromise, a defect, or a bad decision has to stay contained. Least privilege<\/a> is a constraint that overrides the consolidation instinct, and the stakes of the action decide how hard it binds<\/a>.<\/p>\n\n\n\n So the rule carries two clauses. Default to the broadest agent the work’s coherence justifies; stop the moment consolidation would escalate access beyond what separation of duties permits. Capability argues for fewer agents. Security sometimes argues for more. Where they conflict, security wins.<\/p>\n\n\n\nWhat the T-Shaped Agent Borrows<\/h2>\n\n\n\n
The Boundary: Deep and Narrow vs. Wide and Shallow<\/h2>\n\n\n\n
![\"\"](\"https:\/\/sqlhammer.com\/wp-content\/uploads\/2026\/05\/separation-of-duties.png\")
<\/figure>\n\n\nWhere Consolidation Stops<\/h2>\n\n\n\n
The Principle<\/h2>\n\n\n\n