Agent Routing Template

I built my first multi-agent setup on a Tuesday in March. By Thursday it had fourteen agents.

The reasoning seemed sound at the time. Three ventures, each with multiple domains — engineering, business, legal, product, content, ops. Each domain had distinct reasoning requirements. Distinct requirements justified distinct agents.

The system felt slower than my old one-agent setup by Saturday.

Not because the agents were bad. Each one was well-scoped in isolation. The engineering agent knew the codebase; the legal agent knew the IP situation; the content agent had the brand voice dialed in. But every request now had a who-handles-this decision attached *before* any productive work started. Most routes were obvious. Some were ambiguous. That ambiguous percentage was enough to make the whole system feel taxing.

I cut to 6 agents two months later. The same work happened faster. The eight I removed weren't bad ideas — they were too narrow. Each was generating routing overhead it couldn't justify with specialized output.

This bundle is the structure that would have saved me those two months.

What makes routing actually work

The problem isn't adding agents. The problem is adding agents without structure. Without a default agent, every request requires a who-handles-this decision. Without explicit trigger words, routing is inference. Without an escalation protocol, the first time a specialist hits something outside their lane, it either freezes or overreaches.

The fix is three things:

A chief-of-staff who owns routing by default. One agent handles everything unless a specialist's trigger fires. The operator routes only when neither path applies. Mental overhead drops to near-zero for 80%+ of requests.

Triggers that are observable, not inferred. The routing table has a column: "Activate when." The entries are words the operator will literally type — "code, debug, build, deploy, schema" for an engineering specialist; "NDA, contract, patent, compliance" for legal. When a trigger word appears in the request, the route is deterministic. No inference, no ambiguity.

Authority levels that are documented before they're needed. L5 for the chief (routes, drafts, never ships without approval). L4 for specialists who own their domain (decide most things, surface irreversible calls). L3 for specialists where every output warrants review (legal, compliance, brand-level content). Three levels cover most setups.

The reasoning-style split

The most consequential structural decision in a routing system: split agents on reasoning style, not on company.

The intuitive approach is one agent per venture — VENTURE-A handles all Venture A work. The problem is that each venture has multiple reasoning modes: engineering, investor narrative, legal, operations. A venture agent that handles all of them has to context-switch its reasoning mode every turn. It produces generalist output under a specialist label.

Engineering reasoning is specific and testable — it cites code, proposes verifiable solutions, weighs tradeoffs in terms of performance and maintainability. Investor-narrative reasoning is different — it constructs a story, anticipates counterarguments, optimizes for credibility over completeness. Legal reasoning is different still — it flags ambiguous clauses, quantifies risk, defers to jurisdiction. These modes don't mix well in the same agent.

A specialist that embodies one reasoning style produces consistently better work in its lane than one that spans three. The question to ask about every agent in your roster: what is the one reasoning style this agent embodies? If you can't answer that in a sentence, the scope is wrong.

Cross-cutting specialists — legal/IP across all ventures, engineering across all products — are high-leverage because they don't duplicate the reasoning skill per company. One legal specialist holding contracts, NDAs, and patent work for three ventures is more efficient than three venture-level legal specialists each with thin usage.

The three anti-patterns

Sprawl. Adding agents faster than you evaluate whether existing ones are working. The diagnostic: run a split-test after one month. What percentage of requests routes to each specialist? Below 5% is a specialist that's not earning its slot. Above 40% (for a non-chief) is scope that's too broad. Healthy is 10-25% per specialist.

Silos. Each specialist handles its lane correctly, but there's no synthesis. A business decision that requires engineering input and legal review produces three separate specialist outputs — and the operator has to integrate them manually. The chief-of-staff's job is synthesis, not just dispatch. A chief that routes and collects but doesn't integrate is a dispatcher, not an assistant.

Double-routing. Two specialists fire on the same trigger. The chief-of-staff doesn't have a precedence rule. The request lands in the wrong lane, produces off-target output, requires a redirect. Three redirects in a day and the operator starts routing everything manually. Fix: audit trigger lists for overlap before the roster goes live, add explicit precedence where two agents share a keyword.

The escalation protocol

This is the piece everyone skips. They write the routing table, they define the agents, they skip the escalation protocol. They discover the gap the first time a specialist hits something outside its lane.

Without a written escalation path, specialists either freeze (ask for approval on every micro-decision) or overreach (commit to things they shouldn't). Both failures are predictable. Both are preventable.

The protocol has three triggers: out of lane (the request belongs to a different specialist), above authority level (the decision exceeds the specialist's L3/L4 authority), and cross-domain synthesis needed (no single specialist owns the full answer). When any trigger fires, the specialist handles its in-scope portion, surfaces the escalation to the chief with three pieces of information — what the request was, what was handled, recommended forward path — and stops.

The bundle includes a worked example: an operator asks a comms specialist to draft a partnership announcement that includes a technical architecture summary. The comms specialist handles the narrative, escalates the technical section to the chief with a routing recommendation, the engineering specialist handles the technical section, and the chief integrates before the full draft goes to the operator for approval. Extra cost: two short messages. Benefit: accurate technical content in context and no operator stitching.

What's in the bundle

TEMPLATE-apex.md — the chief-of-staff skeleton with authority levels, routing table, and default-behavior rules.

TEMPLATE-specialist.md — the specialist skeleton, parameterized for any reasoning style. Fill in scope, authority level, triggers, domain rules, and escalation path.

routing-rules.md — the CLAUDE.md block, ready to drop in. Includes trigger design guidance and the three common roster shapes.

escalation-protocol.md — the three escalation triggers, what information must travel with an escalation, the chief-of-staff's decision tree for handling escalations, and the worked example.

essay.md — the long-form version of the reasoning above: why the routing tax exists, how to find the right seam, when to add a specialist, when to fold one back.

Three worked examples: solo founder (apex + 2 specialists), three-venture stack (apex + 3 venture-ops specialists + cross-cutting legal), 5-person team (apex + 5 role-specialists). Each includes the CLAUDE.md section, the agent definition files, and a notes section on the design decisions.

Drop the templates into .claude/agents/, fill in the routing table, run the split-test after a month.

The first week the routing pays off, you'll feel the difference. The system goes quiet in the right way — requests land where they should, work happens in the right lane, and the only routing decisions you make are the genuinely ambiguous ones.

— Michael, from the lab