One general-purpose agent is an org design — a bad one
Graph Engineering pattern 12 of 15: the Intelligent Router Graph. A triage node in front of specialist fleets — specialization, per-fleet governance, and institutional memory.
One huge general-purpose agent for all incoming work is an org design. A bad one — the org design equivalent of a company with a single employee who is sometimes support, sometimes engineering, sometimes billing, and deep at none of them.
Context for new readers: pattern 12 of 15 in the Graph Engineering series. The previous patterns each assume the organization knows what kind of work it is holding. Real organizations receive a stream: support questions, defects, billing disputes, security reports — interleaved and unlabeled. The router is the pattern for the stream.
The problem
Push everything through one generalist and every item pays the context cost of every capability, and no capability is deep. Worse, every item runs under the same governance — the security report and the how-do-I question get the same policy, which means the policy is wrong for at least one of them.
The topology
Support fleet
/
Request-> Triage --> Engineering fleet
\
Billing fleet
\
Security fleet
misrouted? -> back to Triage
Incoming requests hit a triage router whose sole job is classification and dispatch. Each destination fleet is itself an organizational graph — engineering work may run an Investigator–Fixer loop, support a knowledge-grounded responder — so the router composes with every other pattern in this series. A misroute edge returns misclassified items for reclassification, and misroute frequency is the router's own quality signal. Resolutions flow to a common terminal so outcomes are recorded in one place regardless of path.
Three reasons routing deserves its own node
Specialization. Each fleet carries only its own context, tools and policies — so each can be deep.
Governance. The security fleet can run under tighter policy than the support fleet, and the router is the single place where that sorting decision is made, logged, and auditable.
Persistence. The pattern becomes powerful when fleets are standing organizations rather than per-item spawns. A billing fleet that has seen ten thousand disputes carries institutional memory a fresh generalist cannot.
Where it breaks
- Router scope creep. A triage node that starts answering the easy questions itself becomes an unaccountable generalist with a routing hobby. Classification and resolution are different jobs on different nodes.
- Silent defaults. Every taxonomy meets an item that fits nowhere. The router needs an explicit unclassifiable destination with human attention — never a quiet default to the busiest fleet.
- Static taxonomy. Incoming work drifts. A rising misroute rate in one category means the taxonomy needs revision, not that the router needs a better prompt.
The dimension answers
| Dimension | Answer |
|---|---|
| Nodes | Triage router, N specialist fleets (each its own graph) |
| Edges | Classification dispatch; misroute return; common resolution sink |
| Cycles | Reclassification loop only |
| Humans | Own the taxonomy; handle the unclassifiable queue |
| Exit rule | Per item: resolution recorded by the destination fleet |
The router is also where this series's compositional claim becomes concrete: a real company runs several topologies at once — and the router is the node that decides which organization each piece of work deserves.
Next: pattern 13, the Evidence & Compliance Graph — separation of duties as topology.
Building this with design partners → rysh.ai/design-partner