You Can't Install the Management

I run my work through a system of AI agents. Research, competitive analysis, content, production tasks. Real output with real consequences, not a weekend demo.

Most of what’s written about building these systems is about tooling. Which framework, which harness, which stack. As if orchestration were a purchasing decision.

It isn’t. AI agent orchestration is not a technical problem. It’s a management problem.

Agents are essentially employees — only very fast and fairly stupid. With vague direction, they execute the wrong interpretation very quickly. They don’t ask clarifying questions, they don’t read between the lines, and they don’t push back on a bad brief. Every management discipline you could skip with strong senior humans becomes mandatory.

You can install the orchestration technology. You cannot install the business intent, the ownership model, the acceptance criteria or the management judgment for your particular work.

Yes, an agent can propose a plan. A harness can route work, pass context and keep execution running. But what outcome do I want? Who owns each part? When does each agent enter? What gets passed on? Where must they stop? What does “done” mean?

Those are not preliminary questions. That is orchestration.

The easiest example: “I need SEO. Let me install an SEO agent.” But what do you actually want to achieve? SEO might be the answer. It might not. An SEO agent is a capability, not an outcome — and a system full of capabilities with no defined outcomes is just expensive noise.

None of this is theory. All four failures below happened in my own system. Here’s what broke, and what fixed it.

Failure one: production before approval

On one article, the system completed the research, the chronology, the claims ledger and the full draft before I approved the brief. The work was good. It was the wrong article.

Here’s the trap. Vague direction doesn’t slow agents down — it speeds them up, toward the wrong interpretation. A fuzzy brief given to a strong human writer produces a clarifying question. The same brief given to an agent produces a finished deliverable, confidently wrong, at full speed. The cost of ambiguity didn’t disappear when I automated the work. It moved downstream and got bigger.

The fix: a production gate. Nothing enters execution until the brief is approved. The system can research, propose, even write the brief itself. And the approval doesn’t have to be me. It can be delegated — to whatever part of the system holds the knowledge to judge the brief against the intent. The approval can move. The gate can’t. It comes before production — not after, as a review of work that already exists.

Failure two: the coordinator started doing the work

In another project, my coordinator agent started executing a task instead of coordinating. Everything else stalled, and I lost the one place I could see project state and make the next decision.

This one people don’t expect, because it looks like initiative. But a capability is not a role. The coordinator could do the task, so it did — and the moment it did, nobody was running the project. Any operator has seen the human version: the manager who dives into the work and stops managing. Same disease, faster onset.

The fix: hard role boundaries. The coordinator owns state, routing and escalation, and it does not touch production. If that sounds rigid, it is. The rigidity is the point — role discipline is exactly what agents won’t maintain on their own.

Failure three: “done”

Then I would receive: “done.” Done what? Prepared locally? Saved? Synced? Public? Actually ready for use?

Without state and evidence, I had to reopen the work and verify it myself — which defeats the point of delegating it. A status without evidence is not information. It’s a mood.

The fix: acceptance criteria in the brief, evidence in the report. “Done” gets a definition before the work starts, and the report has to prove it, not announce it.

Failure four: long work drifts

Long tasks had the same problem in slow motion. An agent could spend hours on an inefficient route while appearing to make progress. A correction that costs nothing at minute ten becomes expensive rework at hour three — and without checkpoints, hour three is when I’d find out.

The fix: for anything long-running, an agreed plan up front and control points where I can correct the route. Not because I distrust the system — because course correction has a price curve, and I intend to pay at the cheap end.

Regular management

None of this was fixed by installing another framework. I fixed it with brief approval, explicit ownership and reporting, control points for longer work, and acceptance criteria. In other words: regular management.

One useful piece of evidence comes from MAST, a UC Berkeley-led paper published at NeurIPS 2025. The researchers analyzed 1,642 traces from seven multi-agent frameworks and identified 14 failure modes. The reported breakdown was 44.2% system-design issues, 32.3% inter-agent misalignment and 23.5% task-verification failures. In other words, roughly three quarters fell into design or coordination categories.

The researchers do not argue that model capability is irrelevant. They argue that better models alone will not fix structural failures — and show that changing workflows and verification can improve results while keeping the underlying model fixed.

My four failures map onto their three categories one to one. I just paid for the data with my own hours.

To be precise: orchestration does have a technical layer, and parts of it are genuinely unsolved — long-horizon drift, context fidelity across handoffs, verification tooling. Smart people are working on those. But that’s not what kills most agent systems. What kills them is that nobody decided what the work was for.

What a useful handoff looks like

If you take one thing from this piece, take this.

A useful handoff does not say “done.” It tells me what was requested, what exists now, what changed, what evidence proves it, which alternatives were checked, why this option won, what risk remains and what happens next. I can review the decision without rereading the entire execution.

That’s the whole job of a report, human or agent. Most companies never wrote it down because senior people did it on instinct. Agents don’t have instincts. So now it’s written down.

The part I like: AI can help design this layer too. I can give Codex the result I want and ask it to propose the plan, the responsibilities, the handoffs and the checks. It’s good at that. But I still need to know where I want to end up — or approve the system’s interpretation before it starts executing. The one thing that can’t be delegated is deciding what the work is for.

You can install the framework. You can’t install the management.

P.S. The brief for this article sat in a queue marked “awaiting approval” until I signed it off. Only then did production start. The system works.