Why "One Super Agent Is All You Need" Sounded Dangerous to Me

Mass-producing thousands of task-specific agents is one danger. Handing every job to a single all-powerful AI is another. I think we should be wary of both. The heart of enterprise AX isn't how many agents you have—it's whether the work is managed in operable units.

I recently watched a video that made me think for longer than usual.

Its core argument went roughly like this: once companies start building "automation agents" for one task at a time, they eventually accumulate hundreds, even thousands of agents, and that becomes a maintenance nightmare. So we should break away from the SI-style habit of endlessly building per-task agents, and instead enable the whole organization to make good use of a general-purpose super agent like Claude Code or Codex.

I understand the concern itself

It's true that, in the AI era, building a "meeting-minutes agent," a "card-news agent," a "risk-assessment agent," and a "financial-forecast agent" each as its own silo—exactly the old SI way—can be dangerous. Build it that way and functionality overlaps, prompts scatter, permissions scatter, data scatters, and the company ends up with piles of automation fragments no one knows who maintains.

In that sense, the message "beware the sprawl of task-specific agents" is correct.

But the "4,000 agents" premise gave me pause

What gave me pause was what came next. To make the risk vivid, the argument seemed to rest on a premise: that "large enterprises will end up building 300, 400, even 4,000 agents."

I couldn't accept that premise so easily.

The large enterprises I've experienced don't operate that way. Sure, there's inefficiency, there's departmental turf-guarding, there's old SI grammar. But that doesn't make a large enterprise an organization that commissions and runs thousands of task-specific agents with no controls at all.

Large enterprises have things like:

• Formal approval (ringi / pumui)
• Budget review
• Security review
• Architecture review
• Privacy review
• Operational hand-off criteria
• Incident accountability
• Maintenance contracts
• Audit logs and access management

I'm not saying these mechanisms are perfect. But at the very least, the moment something enters a formal production system, a structure where each department's request multiplies without limit into its own standalone system is not easily allowed.

Large enterprises typically gather the requests coming up from the field, remove duplication, extract common functionality, unify the permission model, assign an operating owner, and then bundle it all into a system or platform.

4,000 requirements ≠ 4,000 independent agents

So to me, the phrase "4,000 agents will appear" is a little crude.

More precisely, a large enterprise may hold 4,000 business requirements. It may have 4,000 business scenarios, 4,000 workflows, 4,000 combinations of rule, role, skill, and permission.

But that does not mean "4,000 independent agents."

This distinction matters.

If 4,000 independent agents each behave in their own way, that is clearly dangerous. But if 4,000 workflows or skills are managed on top of one common platform, the story changes completely.

The former is sprawl. The latter is governance.

The more dangerous part is the backlash

What worries me is that people who misread this video will take away: "task-specific automation is the old way; from now on, one super agent should handle everything."

That's another dangerous oversimplification.

Large enterprises don't want an all-powerful AI free to do anything. They want a work structure that produces the same quality even when the person changes. Whoever makes the request, it must be judged by the same standard, follow the same procedure, and yield the same level of result.

That's why enterprise work needs a harness. It needs test cases, approval flows, permission separation, audit logs, version control, exception handling, and rollback.

None of this disappears just because the AI is smart. If anything, the more work AI can take on, the more important these controls become.

A better question than "it can do 100 million things"

"One super agent can do 100 million jobs" sounds impressive. But from an enterprise's standpoint, the important questions are different:

• Of those 100 million jobs, which ones does this user have permission to do right now?
• Can this task run automatically, or does it need an approver?
• Against what criteria is this result verified?
• If it fails, who is accountable?
• How far can it access the data?
• At audit time, which logs can it present?
• When a policy changes, which workflows are affected?

A super agent that can't answer these questions will struggle to become an enterprise's operating system for work.

So is a super agent unnecessary?

Of course not.

As a higher-level orchestrator that takes a user's request and routes it to the right business workflow, it's valuable. As an interface that connects many tools and systems, it's valuable. A structure where employees request work in natural language, and behind the scenes it runs through proper permission checks and policy validation, is genuinely needed.

But even then, the super agent should be less an all-powerful worker that judges and executes everything itself, and more an entry point for work that operates within company-wide governance.

The realistic structure I have in mind

The direction I see for enterprise AX isn't a binary. Not 4,000 task-specific agents, and not one super agent that handles everything.

A more realistic structure looks like this:

• There is a common Agent Platform,
• on top of it sit task-specific workflows and skills,
• each workflow carries a role, rule, permission, and data boundary,
• execution results are verified by an evaluation harness,
• every step is preserved as an audit log,
• and important tasks go through human approval.

With this structure, you can manage 400 tasks, 4,000, or 40,000. Without it, even 10 agents are dangerous.

So the crux isn't the number of agents. The crux is whether they're managed in operable units.

In closing

I agree with the video's concern. Stamping out AI agents one at a time, the old SI way, really is dangerous. Go down that road and a maintenance hell awaits.

But if the underlying premise is "large enterprises will soon irresponsibly build thousands of agents," I find that hard to agree with. That can happen in some PoCs, field-led experiments, or the shadow-AI space. But assuming it as the formal AX operating model of a large enterprise is a stretch.

And the more dangerous part is the reaction it provokes: "so one super agent is all you need."

Enterprise AX can't be achieved with slogans. "Use more AI" isn't enough. "Use Claude Code company-wide" isn't enough. "Spend more tokens" isn't the essence either.

The real questions should be these:

• To make our company's work performable by AI, what data structure is needed?
• What permission model is needed?
• What workflow registry is needed?
• Which tasks should be automated, and which should keep an approval step?
• What counts as a correct result?
• Who operates it, and who is accountable?

Talk only about super agents without these questions, and AI becomes just another buzzword.

I don't believe the heart of AX lies in "how many agents to build." Nor in "whether to adopt one super agent."

The heart of AX is redesigning a company's work into a form AI can handle. That process includes general-purpose agents, task-specific workflows, common governance, and an evaluation system—all of them. No single one of them solves it.

So here's how I'd sum it up.

A sprawl of task-specific agents is dangerous. But reading the alternative as one all-powerful super agent is dangerous too.

The answer for enterprise AX is not "do it all with one," but closer to "operate it on a common platform, split into controllable units."

The concern the video raised is important. But if its message is misread, companies may swing to the opposite extreme. We used to build a system for every task. Now the call is the reverse—hand every task to a single AI.

The way I see it, we should be careful of both.

What a company needs is not one trendy tool, but the structure that lets that tool work safely. And designing that structure may well be the most important job in the AX to come.