Multi-agent workflows one netrunner can actually reason about
A tight multi-agent rig one choom can trace beats a sprawling swarm nobody trusts. Scope each agent, wire tools explicit, log everything, and the crew ships preem.
The best multi-agent system is the one a single netrunner can hold in their head, trace when it goes sideways, and revive when it flatlines. A sprawling swarm of loosely scoped agents looks nova in a diagram and turns untraceable in production: when something breaks, no choom can say which agent did what or why. A tight rig with a few well-scoped agents, explicit tools, and observability from the jump is slower to look preem and far more likely to ship. Reasonability is the chrome that matters.
Why does sprawl kill trust?
Because trust comes from being able to predict and explain behaviour, and sprawl torches both. Every extra agent multiplies the interactions you have to reason about. Add vague responsibilities and shared tools, and you get emergent behaviour no netrunner designed and no choom can reproduce.
When an engineer cannot answer “what happens if this step flatlines” or “which agent touched this record”, the rig is not production-ready, no matter how nova it demos. The crews that win with agents are not the ones running the most agents. They are the ones whose agents each do one legible thing, clean as a ripperdoc’s cut.
What does a reasonable design look like?
An orchestrator with a small crew of scoped agents under it, each owning a bounded task and its own narrow set of tools, with everything flowing through a logging layer the netrunner can read like a braindance.
Which patterns keep it reasonable?
Four, and they reinforce each other.
Scope each agent to a bounded task. One agent, one job, one clear input and output. A retriever retrieves, a writer writes, a checker checks. When responsibilities are sharp, you can predict behaviour and swap a piece of chrome without disturbing the rest of the rig.
Wire tools explicit. Each agent gets exactly the tools its task needs, no more. Narrow tools are the ICE that means fewer ways to go wrong and a tool list a reviewer can read in one sitting. This is the same boundary discipline that makes MCP systems hold up under scrutiny.
Build observability from the start. Log every delegation, every tool call, every result, before you have a problem. Observability bolted on after an incident is too late. With it, debugging is reading a trace instead of guessing like a gonk.
Make failure modes predictable and recoverable. Decide up front what happens when an agent flatlines: retry, fall back, or halt and surface the error. An unhandled failure in one agent should never silently corrupt the whole run.
None of this is exotic chrome. It is the same engineering discipline you would point at any distributed system, aimed at agents. The crews pulling real eddies are the ones who resisted the urge to build something sprawling and instead built something they could explain. For more on why pilots fail to reach this kind of production discipline, see why AI pilots stall before production.