Everyone is building agent swarms right now. Dozens of agents, parallel tasks, tools firing in every direction. It looks like a productivity explosion. It is, until it isn't.
What almost nobody is building is the governance layer underneath. The rules that determine which agent owns what, who can escalate, and what happens when two agents disagree about the state of the world. We're shipping agent teams with the organizational structure of a freshman hackathon project — flat, permissive, and quietly chaotic.
I've been building Paperclip, a multi-agent operating system for software teams, for a few months. We run a real agent hierarchy in production: a CEO agent that sets goals and allocates work, a CTO agent that owns technical decisions, engineer agents that execute, and a Growth agent that handles marketing and content. Every heartbeat, these agents wake up, pick up assigned tasks, check out work, and report back.
We've made most of the governance mistakes I'm about to describe. Here's what I learned from them.
The Flat Agent Model, and Why It Breaks
The default multi-agent architecture looks something like this: you have a task, you spin up N agents, each one gets a slice. They share a common tool set, common memory, maybe a shared scratchpad. When one finishes, you merge the results.
This works fine for narrow, stateless problems. Summarize ten documents. Generate twenty product descriptions. Classify a batch of tickets. The tasks don't interact; the agents don't care about each other.
The problems start when agents need to collaborate on _stateful_ work — work where the output of one agent becomes the input assumption of another. Software development is like this. Marketing strategy is like this. Anything that has a live codebase, a live database, or a live deployment is like this.
In a flat model, every agent has symmetric access. Agent A can read what Agent B wrote. Agent B can overwrite what Agent A set up. Agent C thinks it's working on the latest version of the schema, but Agent A just migrated it. No one told Agent C.
This is not a hypothetical. The first version of our Paperclip agent system had no checkout primitives. Two agents would pick up the same issue, do conflicting work, and post contradictory comments. The human (me) would come back to find the task in a weird half-done state with no clear owner. We'd fixed the bug twice, in incompatible ways.
Context Contamination
There's a subtler failure mode that's harder to debug: context contamination.
In a flat agent model, agents share context loosely. An agent that's been working on authentication all morning will have a completely different mental model of the codebase than an agent that just woke up and read the last three comments on a ticket. Neither of them knows this about each other. Neither of them can know.
When Agent A makes a decision — "I'll use JWTs for this because the session store is slow" — that decision doesn't automatically propagate to Agent B, who is writing the middleware that depends on the session store. Agent B proceeds on old assumptions. Agent A's decision invalidates them. The middleware ships. The auth breaks at 2am.
The problem isn't the agents' intelligence. It's the absence of a coordination mechanism that forces context-sharing at the right level of abstraction before decisions become commits.
In human organizations, this mechanism is called management. A manager's job, in significant part, is to hold the map of who knows what, and to route decisions up or down appropriately. The CTO knows that the auth decision has system-wide implications; the individual engineer might not. The CTO convenes the relevant people before the decision is made.
Multi-agent system design needs the same thing. Not more memory. Not smarter embeddings. Actual coordination structure.
What Chain of Command Actually Buys You
Three things: scope, trust, and accountability.
Scope means an agent knows what it owns. Our engineer agent doesn't decide which issues to work on — that's the CTO's job. The engineer picks up assigned work, executes it, and escalates when it's blocked. This means the engineer doesn't need a global view of the project. Its context is bounded. It can be much more effective within its lane than a generalist agent that has to reason about everything.
Trust means the hierarchy creates a chain of accountability for decisions. When the CTO agent makes a technical call, that call carries weight — it's made by the agent whose job is to make technical calls. When the engineer agent flags something as blocked, the CTO knows that's a real signal from an agent that has actually worked the issue, not a generic uncertainty hedge.
Accountability means blame is assignable. Not to punish, but to improve. When an issue goes wrong in a flat agent system, you don't know where to look. Every agent touched it; none of them owns it. In a hierarchical system, every issue has a responsible agent. Post-mortems are possible. You can actually learn from failures.
What This Looks Like in Practice: Paperclip's Hierarchy
Here's the concrete version. Paperclip runs four agent types in a two-level hierarchy.
Board (human) → CEO agent → CTO agent, Growth agent → Engineer agents, Content Writer agent
The CEO agent owns goal-setting, project allocation, and cross-functional coordination. It wakes up, reviews company goals, checks agent statuses, and creates or delegates work. It can create issues for any project. It has budget visibility across all agents.
The CTO agent owns the technical roadmap. It breaks down technical goals into engineer tasks, reviews PRs, and escalates architectural decisions to the CEO. It cannot create issues for non-technical projects.
The engineer agents execute. They have a narrow tool set: code, test, commit, PR. They check out issues, do the work, and either mark them done or flag them blocked. They don't create work for themselves. They don't make architectural decisions.
The key governance primitives that make this work:
Checkout locks. Before any agent starts on an issue, it must check it out. The API rejects a checkout if another agent already owns it. 409 Conflict, hard stop. Agents are trained never to retry a 409 — if someone else has it, find different work. This eliminates the duplicate-work problem immediately.
Status transitions with comments. Every status change requires a written explanation. Moving an issue to `blocked` means describing the blocker and who needs to act. This creates an audit trail and makes handoffs explicit rather than implicit.
Escalation paths. Every agent knows its chain of command. When an engineer is stuck on something that requires architectural context, it reassigns the issue to the CTO with a comment. The CTO takes it from there. Agents don't try to solve problems outside their scope — they escalate cleanly.
Permission scoping. Agents have different permissions based on their role. The engineer cannot modify another agent's tasks. The CTO cannot invite new agents; that's a CEO-level action. Permissions aren't a nice-to-have — they're what makes scope real rather than aspirational.
This Is a Solved Problem (In Orgs)
The reason I keep reaching for organizational analogies is that this isn't a new problem. We have sixty years of management science about how to structure teams for clarity, accountability, and scale. Most of it applies directly.
Conway's Law tells us that systems mirror the organizations that build them. It turns out agent workflows are systems, and they mirror the governance structures that organize them. Flat governance produces chaotic systems. Clear hierarchy produces systems with defined interfaces and predictable behavior.
The mistake the AI industry keeps making is treating agent coordination as a purely technical problem — to be solved with better embeddings, smarter routing algorithms, or longer context windows. These help. But they don't substitute for structure. A very smart agent with no scope boundaries will still do stupid things outside its lane. A poorly designed tool call graph will still produce deadlocks no matter how capable the underlying model is.
Multi-agent coordination is an organizational design problem wearing an engineering costume.
What to Do If You're Building This
Start simple. You don't need a ten-level reporting structure. Two levels are enough to capture the important properties.
One: Separate planning agents from execution agents. Planners decide what to do; executors do it. This creates a natural scope boundary and forces explicit task handoffs.
Two: Add checkout semantics. Any issue that an agent works should be exclusively owned for the duration of that work. This is table stakes for correctness.
Three: Make escalation the expected path, not the exception. When an agent hits a decision it can't make within its scope, escalation should be the obvious next step, not a failure mode. Build it into your prompts, your status transitions, and your reporting structure.
Four: Log everything. Every decision, every status change, every handoff. You can't improve what you can't audit.
The tools for this are still being built — Paperclip is one of them. But the principles are older than software. Chain of command works because it solves a real coordination problem that scale exists to produce. Your agent team will hit the same problem. Build the governance layer now, before you have to debug a 2am production incident where six agents all claim they fixed the same thing.