The hard part of running multiple autonomous agents isn't the models. It's the relationships between them.
A single agent is a tool. You point it at a task, it works, it reports back. But the moment you run a fleet — several agents that have to hand work to each other, defer to each other, and stay out of each other's way — you've stopped building software and started building an organization. And organizations have a failure mode that software doesn't: if you don't define who answers to whom, and what flows where, the whole thing collapses into noise. Agents step on each other, duplicate work, argue about ownership, and burn tokens re-explaining context they should have inherited.
The naive fix is to spell it all out. Declare every relationship explicitly: agent A reports to agent B, agent B sends its output to agent C, agent C is not allowed to talk to agent D. It works, in the way that a thousand-line config file works. It's brittle, it's tedious, and it doesn't scale. Add a sixth agent and you're editing relationships by hand again.
There's a better way, and it's been sitting in front of us for centuries.
The trap: explicit relationships don't scale
When you define every agent relationship by hand, you're doing the work the organization should be doing for you. You're the one enforcing the hierarchy, the routing, the division of labor — every time, for every pair of agents.
That's a trap for two reasons. First, it's fragile. The relationships are only as good as your last edit, and nothing about the agents themselves reminds you when the structure has drifted. Second, it's brittle under growth. A fleet of two agents is easy to wire by hand. A fleet of six is a spaghetti diagram. A fleet of a dozen is unmaintainable, and the failure mode isn't a crash — it's a slow, expensive erosion of discipline as agents start talking to the wrong people and duplicating each other's work.
The deeper problem is that explicit relationships encode structure but not behavior. Knowing that agent B reports to agent A tells you the routing. It doesn't tell agent B how to behave — when to escalate, when to stay quiet, when to push back, what it's allowed to decide on its own.
The fix: borrow an organization that already works
The insight is that you don't need to invent a command structure. You need to adopt one. History is full of organizations that solved exactly this problem — how to route information, divide labor, and enforce discipline among a group of people who can't all talk to each other at once. They spent centuries refining it, under conditions where getting it wrong meant death.
So instead of declaring each agent's relationship to every other agent, we assign each agent a role in a historical organization. The hierarchy and the data flow come along with the role, already encoded. You don't state that agent B reports to agent A — you give agent B a role whose entire job is to report to agent A, and the behavior follows.
A well-designed historical role is a bundle of three things at once: a position in the hierarchy, a defined lane of work, and a behavioral contract. That third piece — when to escalate, when to stay quiet, what to decide alone — is the one explicit relationships never give you. A role isn't just a routing table. It's a personality with boundaries.
The guardrail: discipline comes from the role, not the config
The reason this holds up where explicit wiring doesn't is that the structure is self-reinforcing. The agents don't need to be reminded who they report to — it's in the role, and the role shapes how they talk to each other. When a new agent joins, you don't rewire the fleet. You give it a role, and the existing roles already know how to treat it.
It also changes how the humans run the fleet. You stop thinking in terms of "which agent talks to which agent" and start thinking in terms of "who's the quartermaster, who's the radioman, who's the first mate." That's a much more natural way to reason about a team — because it's how we've reasoned about teams for as long as there have been teams.
The discipline isn't enforced by a config file. It's enforced by the roles the agents believe they're playing. And that's the part that surprised us: agents that are given a role don't just follow it — they inhabit it. They start behaving the way the role behaves, deferring and escalating and staying in their lane in ways that no explicit relationship list ever produced.
The takeaway
When you're orchestrating multiple autonomous agents, don't reach for the relationship config. Reach for the organizational chart. History already solved the problem of routing information and enforcing discipline among a group that can't all talk at once — and it solved it under conditions where getting it wrong was fatal. That's a design pattern worth stealing.
The agents that matter aren't the ones with the biggest models. They're the ones that know their place in the fleet.
And here's how we do it
If you've been reading this and wondering which historical organization we borrowed — it's pirates.
Not as a gimmick. As a working command structure. Our fleet runs on a pirate-ship hierarchy: a captain who sets intent and boundaries, a first mate who runs the day-to-day and keeps the crew honest, a quartermaster who handles the logistics and the memory, a radioman who owns the comms. Each agent has a role, and the role carries the hierarchy, the lane, and the behavior — no explicit relationship list anywhere.
It sounds like flavor, and it's not. The roles are load-bearing. When an agent is the first mate, it acts like a first mate — it defers to the captain, keeps the crew in line, and doesn't try to be the captain. When an agent is the radioman, it owns the comms and stays out of the cargo hold. The discipline we spent weeks trying to wire in by hand showed up on its own, because the roles already knew how to behave.
So if you're building a fleet and the relationship config is getting unmanageable, try giving your agents a job on a ship. Any ship. The hierarchy is already there — you just have to let them play their part.