Article
More Agents Means More Management
When one agent becomes many agents, the bottleneck moves from model capability to task, context, permission, state, and acceptance management.
One AI agent feels like a tool.
Five AI agents start to feel like a team.
That sounds exciting until you realize what teams create: management problems.
I do not mean management as corporate theater. I mean the basic operational questions:
- who is doing what;
- what context are they using;
- what can they touch;
- where are they in the task;
- how do we know the result is acceptable?
The next stage of agent products is not ten chat boxes. It is a control plane.
One agent is capability. Many agents are coordination.
When you use one agent, the main question is whether it is smart enough.
Can it write the code? Can it search the docs? Can it summarize the meeting? Can it use the tool correctly?
When several agents run at the same time, the question changes.
Which task belongs to which agent?
Did two agents make conflicting assumptions?
Did the research agent pass evidence or just a confident summary?
Did the coding agent run tests?
Did the review agent see the same requirement?
Did anyone own the final decision?
This is not a model benchmark problem. It is a workflow problem.
The five things to manage
I think useful agent products need to manage at least five things.
First: tasks.
An agent task needs an owner, status, input, output, and acceptance criteria. A vague task makes the model fill in missing pieces. Overlapping tasks make multiple agents produce incompatible results.
Second: context.
More context is not always better. Dirty context spreads bad assumptions. Long context dilutes attention. Fragmented context makes the model guess. Managing agents means managing context boundaries.
This is where sub-agents are useful. Not because a team chart is magical, but because some work is noisy. Reading ten files, running three tests, and inspecting logs should not always pollute the main thread. Let a sub-agent consume the noise and return evidence, risk, and a conclusion.
Third: permissions.
Once an agent can act, mistakes become real actions. Sending an email, changing a database field, merging a pull request, or exposing customer information are not the same as answering a question wrong.
Enterprise buyers do not only need a smarter bot. They need permissions, approvals, logs, and accountability.
Fourth: state.
Long-running work needs visible state. Pending, running, blocked, needs review, failed, done. If a page refresh loses the task, the product is not ready. If a sandbox dies and the work cannot recover, the product is not ready. If the agent has been stuck for twenty minutes and nobody can tell why, the product is not ready.
Fifth: acceptance.
An agent saying “done” is not enough.
Code needs tests. A report needs sources. A design needs fit against requirements. A user feedback analysis needs to preserve the minority signal, not only the average summary.
When multiple agents produce outputs, acceptance gets harder. One says A. One says B. One writes a compromise. The system needs a closing mechanism. Sometimes that is a human. Sometimes that is a primary agent. But the final decision cannot be an endless agent meeting.
The control plane is the product
This is why I care about agent control planes.
The valuable product surface is not only the agent chat. It is the task queue, permission model, run trace, approval flow, retry path, cost record, context history, and review state around the agent.
A customer support agent is not useful just because it can answer. It must know when to escalate, what customer data it can read, how to correct a wrong answer, and how the correction becomes part of the next workflow.
A coding agent is not useful just because it can modify files. It must bind to an issue, create a branch, explain the diff, run tests, preserve failure context, and make review easy.
An operations agent is not useful just because it can draft copy or query a dashboard. It must follow brand rules, respect approvals, trigger from data, and leave behind an audit trail.
That is the real product work.
The uncomfortable conclusion
More agents do not automatically mean more leverage.
Without management, more agents mean more context confusion, more permission risk, more invisible state, more conflicting outputs, and more acceptance work.
So when I look at an agent product now, I do not only ask:
Can it do the task?
I ask:
Can it be managed?
That is the difference between a demo and a production system.