Your Agent Fleet Doesn't Need a Better Model — It Needs an Org Chart

The bottleneck in agentic systems is not the model. It is the org chart.

Everyone is racing to add agents. Almost all of the public effort goes into tooling: frameworks, context windows, orchestration plumbing. Almost none of it goes into the questions that actually decide whether a group of capable individuals produces results or noise — who has authority, who makes which decision, and how much independence each agent gets.

We have run this experiment before. Not with agents — with people. Every engineering leader who has managed a team knows what happens when decision rights are unclear, when scope is bloated, when everyone escalates everything upward. The team is full of talent and produces very little. A technically flawless fleet of agents with a broken authority structure will underperform a modest fleet with a clear one, for exactly the same reasons.

The tell is in the field itself: very few people have a demonstrably operating, full-scale system of agents. The claims vastly outnumber the examples. That gap is the evidence. The industry is solving the engineering problem and quietly skipping the management problem.

The Management Principles Are Older Than the Models

The most useful thing you can do for your agent architecture may be to stop reading about agent architecture and re-read a leadership book. Two of them, specifically.

The first is Extreme Ownership by Jocko Willink and Leif Babin, and its Four Laws of Combat. They map almost one-to-one onto the failure modes of an agent fleet.

Cover and Move. The whole team is one team; units support each other or the mission fails. The agentic failure it prevents is siloing — agents duplicating work, holding no shared context, sub-fleets pulling at cross purposes.

Simple. Plans and orders have to be simple enough that the people executing them can't misread them. The failure it prevents is bloated, ambiguous agent scope. Complexity compounds under failure; an overloaded instruction set manufactures its own fog of war.

Prioritize and Execute. Under pressure, name the single highest-priority target, execute it, then move to the next. A frontier model, trained to be helpful, will always find another task to do. The discipline is picking the one that matters and declaring the rest not-now.

Decentralized Command. People closest to the work make the decisions, guided by the leader's intent rather than the leader's approval. The failure it prevents is every judgment call escalating to a head agent. Agents have to decide, not fetch — which means each one has to know the goal and its boundaries.

Notice that none of these are technical properties of a model. They are properties of how you organized the work.

Your Agents Are Yes-Men, and That Is a Design Problem

Here is the second book. Frontier models are trained to be agreeable. Assemble a group of them and you have, by default, a support network: a room full of colleagues who agree with you and with each other.

Adam Grant spent a career explaining why that is the shape of an organization that fails. In Think Again, he argues for the opposite — a challenge network of thoughtful critics, "disagreeable givers" whose job is to surface the blind spots you can't see yourself. He pairs it with what he calls confident humility: "being secure enough in your knowledge to recognize your ignorance, and secure enough in your strengths to acknowledge your weaknesses."

Human organizations already fail at this, because agreeing is socially cheaper than disagreeing. In an agent fleet the cost of agreement is even lower — there is no social friction at all — so the failure is even more likely. A support network is what you get for free. A challenge network is something you have to build in on purpose: route an agent's decisions to other agents whose explicit role is to evaluate them and push back.

When we started building agent fleets at Pando, the early systems just worked to do work. Because the models are built to be agreeable and to keep looking for the next thing to do, stitching them together produced a great deal of activity and not much judgment. The change that made a qualitative difference — in both output and cost — was directing agents to make high-quality decisions rather than hunt for tasks, and then routing those decisions to other agents to critique. A manufactured challenge network, in Grant's language.

I'll be honest about the evidence here, because the topic invites exaggeration: we don't have a clean benchmark for that change, and for the cost half we can't yet produce one we'd stand behind. So take it as an architectural claim, not a measured one.

What we can show is design intent. The events an agent in our suite is allowed to emit are enumerated: a worker requesting another worker, a worker requesting the head, a worker sending or receiving an event, the head sending a decision, the head requesting a worker. Six event types. There is no "found work" event. The architecture structurally cannot express an agent wandering off to look for something to do — every action originates in a request or a decision. That is not a number, but it is checkable, and it makes the point more forcefully than a benchmark would.

Autonomy Without a Scoreboard Is Just Drift

Decentralized command has a precondition that is easy to skip: a visible scoreboard. This is the core of a third body of work, The 4 Disciplines of Execution by Chris McChesney, Sean Covey, and Jim Huling — a wildly important goal, lead measures, a compelling scoreboard, and a cadence of accountability. Push decisions down to autonomous units and give them no way to see the score, and autonomy becomes drift. Everyone is busy; nobody knows if the fleet is winning.

This is the question that eventually breaks every decentralized system: how would you even know? For agent fleets, that scoreboard is telemetry — efficiency and cost visibility across the fleet. It is the reason Pando builds Trenchcoat, a scoreboard for Claude Code agent fleets. It arrives here as the answer to the question, not as the point of the piece.

Org Design Is Maintained, Not Configured

The last principle is the one people most want to be false, because it means the work never ends. Organizational design is not a one-time setup. It decays when it stops being maintained.

I once led an engineering team run on exactly these principles: teams operating autonomously, decisions pushed down to the people closest to the work instead of information pulled up to leadership. The team shipped full-scale applications in weeks instead of years. Then the leadership that installed the framework moved on, and the structure stopped being maintained. It was not self-sustaining. Teams began to fail and come apart. Velocity fell. Quality fell. Delivery slipped across the board. Nothing about the talent had changed — only whether anyone was still tending the org design.

Agent fleets rot the same way, and faster, because nothing in the system complains when the structure erodes. The agents will keep producing output. It will just quietly stop being good.

The Actual Work

So the crux of agentic system design is not the mechanics of building agents. It is authority, decision-making, and independence — the same things that decide whether a human team works. Scope each agent narrowly enough to keep it simple. Give it commander's intent so it can decide instead of escalate. Build the disagreement in on purpose, because a fleet of agreeable models is a support network and you need a challenge network. Stand up a scoreboard, because autonomy without one is drift. And keep maintaining all of it, because the day you stop is the day it starts to rot.

The better model helps. But it is not the thing standing between you and a fleet that works. The org chart is.

We write about how we build at pando.codes.