Everyone building multi-agent systems knows the starting pattern by now: a router reads the request, works out what's actually being asked, and dispatches to specialized agents — one to set up the problem, one to execute, one to explain, one to narrow scope. Orchestration graph, specialized nodes. Fine. Everyone builds this. It's table stakes.
The part nobody teaches — the part that actually decides whether your system survives a year — is quieter:
Choosing the right level of abstraction.
Not the number of agents. Not the cleverness of the orchestration. The level. And there are two symmetric ways to get it wrong.
Trap 1: too coarse — the graph inside the graph
An agent grows up. It now has five branches, three tools, a loop, sub-decisions. The obvious move — the one every framework nudges you toward — is to give it its own internal graph. Then, later, a graph inside that.
It feels natural. It's also how a multi-agent system quietly becomes a monolith. Everything shares the parent's state. A change deep in a sub-graph has a blast radius you can't see. You can't test the inner piece in isolation, because it only exists inside its parent. You can't scale it, hand it off, or reason about it separately — there's no seam. It becomes one tightly-coupled organism only its author understands, and only for a few more weeks. (I've watched this exact shape before, in embedded systems, when "just one more special case" ran for two years.)
Trap 2: too fine — a hundred agents in a trench coat
The opposite mistake is louder right now, because AI made spinning up an agent nearly free. So people spawn dozens — hundreds — of tiny agents and wire them together, mistaking more agents for more intelligence.
It isn't. It's more ways to disagree. More hand-offs to misfire. More latency stacked end to end. More "which of these forty agents was wrong, on which step?" You've traded a monolith for a distributed system you didn't design and can't observe. The cost of an agent was never the code to create it — it's the coordination it drags in behind it. When agents are cheap to make, that cost is exactly the thing you stop noticing.
The actual skill: draw the boundary where it earns its keep
Both traps are the same failure — dodging the judgment call. The skill is sitting in the middle and deciding, deliberately, where a boundary belongs.
My rule: keep it a node while it's simple; promote it to a standalone agent behind a protocol (A2A) the day you catch yourself giving it its own graph — and not a day before. That moment isn't a coding decision; it's the design telling you the piece has outgrown living inside its parent.
When you promote it to a protocol-served agent, everything the nested version fought you on gets easy: it has a contract, you can test it in isolation, you can scale and version it independently, someone else can own it, and — because it speaks a protocol — anyone can call it, including the customer's own agents. A nested sub-graph can only ever be talked to by its parent.
The restraint clause (this is the whole skill)
Don't read this as "decompose everything into agents." That's just the nested-graph mistake wearing a different costume — premature boundaries you have to maintain before they earn their keep.
The judgment is in the timing. Keep it a simple node while it's simple. The signal to promote is specific: the day you catch yourself giving a node its own graph. Extract it then — not before, not five branches too late. The right level of abstraction means as few boundaries as possible, and no fewer.
And none of it tells you when it'll break
One caveat before anyone ships this: the right abstraction makes a system maintainable, not correct. A beautifully-factored multi-agent system can still be confidently wrong. The only thing that tells you when it will fail is deliberate planning and testing at the seams — not vibes. That's a whole discipline of its own; a post is coming. For now: if you're not testing the boundaries, you're guessing.
The takeaway
The multi-agent conversation is obsessed with orchestration and agent count. The engineers whose systems last are obsessed with something less glamorous: the level of abstraction. Too coarse and you get a monolith. Too fine and you get a swarm. The whole job is knowing where the boundary belongs — and having the restraint to draw no more than that.
The agents are the easy part. The abstraction level is the engineering.
If you build multi-agent systems: what's your signal for "make it its own agent" vs. "keep it a node"? I want to hear how others draw the line.
Originally published on my blog.
Top comments (0)