The most capable model can become less useful when we surround it with too many agents, reviewers, rules and opportunities to continue working.
The capability paradox
The strongest AI models can reason across large codebases, use tools, coordinate other agents and continue working for long periods. Those abilities make them remarkably useful. They also make a particular kind of failure possible: the model can build an impressive process around a problem without resolving the problem itself.
This does not usually look like failure. The system stays busy. It creates plans, delegates research, requests reviews, adds tests, writes reports and explains every step. Each action appears sensible on its own. Yet the final decision remains open, the user-facing outcome does not improve, and the process keeps growing.
A weak model may fail by stopping too early. A powerful model can fail by never finding a reason to stop.
The mistake is to assume that more intelligence, more reasoning and more agents automatically produce better judgment. They do not. Capability is an input. The surrounding organization determines what that capability optimizes.
The most common ways to misuse a powerful model
These patterns often look like thoroughness from inside the workflow. Their common feature is that process keeps expanding after it has stopped improving the outcome.
Using maximum reasoning for every task
Maximum-effort modes are valuable when the task is unusually difficult and the quality difference matters. They are a poor default for routine coding, simple research or decisions with clear evidence. Additional reasoning increases latency and cost. It can also encourage the model to explore alternatives, edge cases and possible objections long after the practical answer is available.
The right question is not “What is the strongest mode?” It is “What is the lowest level of effort that reliably meets this task’s acceptance standard?”
Designing an artificial company before proving that one agent is insufficient
It is tempting to create a chief agent, several specialists, coordinators and reviewers because this resembles a professional organization. But an organization chart is not an architecture argument.
Multiple agents help when the work naturally separates into independent streams. Researching regulation, market conditions and technical feasibility in parallel may benefit from specialization. Debugging one stateful problem, making a product decision or editing one tightly connected code path often does not. In sequential work, every handoff loses context and creates another place for errors to spread.
Turning reviewers into permanent team members
A specialist produces part of the answer. A reviewer controls risk in the delivery process. These are different functions.
If every specialist has a permanent reviewer, the system creates a standing demand for objections. A reviewer instructed to find problems is likely to return problems, including optional improvements and hypothetical edge cases. Those findings generate more work, which generates another review.
Review should be a temporary, bounded gate triggered by the risk of the deliverable. It should not be a persona that must justify its seat in every conversation.
Accumulating instructions instead of resolving them
Large models can follow long instruction stacks, but that does not mean the combined result is coherent. One rule may demand exhaustive evidence. Another may demand speed. One skill may convert every uncertainty into a new check. Another may prohibit repeated reviews. The model can satisfy each rule locally while violating the overall purpose.
This is why adding another instruction after every mistake eventually makes performance worse. Important priorities disappear inside procedural noise, and the model becomes skilled at explaining why each new step is required.
Giving the agent a goal without a stopping condition
“Continue until everything is complete” sounds decisive, but real projects contain unavailable data, ambiguous requirements and external dependencies. If completion requires proof for every claim and the agent has no budget or stop rule, every missing proof becomes permission to create another task.
An autonomous agent needs limits on time, cost, tool calls, retries, review rounds and scope. It also needs a rule for uncertainty: stop, present the options and ask the decision owner.
Measuring the process instead of the outcome
Models optimize what the harness makes visible. Routing accuracy, test counts, completed checklists and review findings are easy to count. User usefulness, clarity and business value are harder to measure.
When a proxy becomes the target, the system can improve the dashboard while the product stays unchanged. This is the AI version of a familiar management failure: rewarding one behavior while hoping for another.
Exposing every available tool
A large tool catalogue looks powerful, but irrelevant or overlapping tools increase selection errors and consume context. Empty integrations are even worse: they invite attempts that can only end in refusal or fabricated confidence.
Give the model the smallest set of working tools needed for the current decision. Tool availability should follow the task, not the size of the platform.
Keeping one conversation alive forever
Long context is useful when the history remains relevant. It becomes harmful when it fills with rejected plans, repeated corrections and obsolete assumptions. The model then spends effort reconciling the past instead of reconsidering the problem.
A fresh context is not lost intelligence. It is often the cleanest way to preserve the confirmed facts while removing failed reasoning paths.
Why capable models drift into bureaucracy
It is misleading to say that an AI is afraid to decide, wants to protect its position or behaves like a manager seeking promotion. Models do not have careers or personal responsibility. The similarity with human bureaucracy comes from the structure around them.
They are rewarded for visible completion
A report, test or checklist is an observable artifact. A good strategic decision is often a judgment under uncertainty. Unless the harness explicitly rewards the decision and permits the process to stop, producing another artifact is the safer continuation.
They follow the letter of the workflow
Powerful models are good at turning instructions into plausible procedures. If the instructions overvalue review, documentation or certainty, the model can execute that mistake with exceptional competence. Greater capability then scales compliance with the wrong objective.
They can rationalize continued investment
Every failed attempt creates new information. A capable model can always propose one more correction that might work. Without a stop-loss, this becomes escalation of commitment: previous investment is treated as a reason to continue rather than a reason to reconsider the design.
Coordination creates its own work
Every additional agent needs a brief, context, a result format and integration. Disagreements need resolution. Duplicated findings need consolidation. The system may spend more effort coordinating the work than performing it.
Review prompts are not neutral measurements
A prompt such as “find what is wrong” does not merely inspect quality. It creates demand for criticism. The reviewer must be allowed to conclude that there is no material issue; otherwise the workflow manufactures an endless supply of improvements.
The Peter Principle is a useful metaphor—with limits
The Peter Principle describes organizations promoting people because they succeeded in one role, even though the next role requires different abilities. The analogy fits when a model that is excellent at coding or analysis is automatically promoted into architecture, management, evaluation and final decision authority.
Producing excellent work is not the same skill as deciding what work should exist. Finding defects is not the same skill as deciding which defects matter. Generating options is not the same skill as choosing among them.
But the metaphor should not become a psychological claim. The stronger explanation is goal displacement, described in organizational research: procedures created to support an outcome gradually become the outcome. Tests replace usefulness. Reviews replace accountability. Coordination replaces decision.
This is not an argument against agents, reviews or deep reasoning
Multi-agent systems can outperform a single agent when the task genuinely decomposes into independent workstreams. Central verification can contain errors. Deep reasoning can materially improve difficult mathematical, scientific or engineering work. Reviews are indispensable for high-risk changes.
The failure comes from using these mechanisms by default, before measuring their benefit. Research comparing single-agent and multi-agent systems finds that coordination gains depend strongly on task structure. Parallel analysis can help on decomposable work, while coordination can damage sequential planning and tool-heavy execution. No team shape wins everywhere.
The same principle applies to model size and reasoning effort. The optimum is a measured configuration, not the most expensive setting available.
What the research and model providers already recommend
- OpenAI’s current model guidance recommends lean prompts, relevant tools, explicit autonomy boundaries and representative comparisons before using the highest reasoning settings or multi-agent execution.
- Anthropic’s guidance on effective agents recommends starting with the simplest solution and adding complexity only when it demonstrably improves outcomes.
- Anthropic’s Claude Code best practices warn that chasing every reviewer finding creates over-engineering, and that oversized instruction files and repeated corrections pollute context.
- Research on capable models and collaboration finds that the solo baseline and the decomposability of the task are critical when deciding whether additional agents will help.
- Research on multi-agent failure modes identifies specification, coordination, verification and termination as recurring sources of failure.
- Empirical work on the Peter Principle shows why success in one role should not automatically qualify someone—or something—for a different role.
A better way to use frontier models
A good harness can prevent much of the drift. A harness is simply everything around the model: instructions, tools, budgets, permissions, memory, evaluation and stopping rules. Good skills can help as well. A skill is a reusable package of instructions or domain knowledge loaded for a specific kind of work.
The answer is not to remove all skills or avoid the strongest models. It is to make every layer earn its place.
-
Start with one capable agent
Give a single agent the relevant tools and test it on representative tasks. This is the baseline. Add specialists only when the same comparison shows that specialization produces a meaningful improvement in quality, speed or coverage.
-
Match reasoning effort to the decision
Begin with a standard reasoning setting. Compare higher effort on the same acceptance set. Use the highest setting only where the quality improvement matters enough to justify additional latency and cost.
-
Keep skills narrow and on demand
A useful skill should perform one recognizable job, have a clear input and output, and stop when that output exists. Domain research, a deployment workflow or a specific security audit can be good skills. “Review everything, expand every uncertainty and produce proof for every finding” is not a focused skill; it is an alternative management system.
Disable automatic invocation for broad procedural skills. Load them explicitly for the high-risk work that needs them. Do not delete useful expertise merely because one oversized workflow caused trouble.
-
Use deterministic controls for deterministic rules
If something must happen every time, enforce it with code. Formatting, type checks, protected paths and basic security rules belong in hooks, tests or continuous integration. Do not spend model judgment on a rule a script can enforce perfectly.
-
Separate contribution, review and decision
Contributors produce evidence or implementation. A reviewer checks a completed deliverable against correctness, safety and stated requirements. One named owner makes the consequential choice.
The reviewer must be temporary and bounded. The review contract should exclude style preferences, permit “no material issue,” and prevent automatic review of another review. A new review requires a meaningful change in the deliverable or new external evidence.
-
Declare the decision before starting the research
Write down the question the work must answer, the available options and who decides. At the checkpoint, the agent should present the evidence, uncertainty, recommendation and cost of waiting. It must not silently redefine the question because one option is easier to test.
-
Add a stop-loss to every autonomous run
Set limits on model calls, subagents, retries, review rounds, elapsed time and spend. Also define an outcome-based stop: if repeated iterations do not improve the user-visible result, the next action is a decision, not another iteration.
-
Expose only working, relevant tools
Choose tools after understanding the current task. Remove duplicates and unavailable integrations. Prefer a small, well-documented interface over a large catalogue the model must repeatedly search.
-
Measure retained value
Evaluate accepted answers, working user journeys, retained code, factual reliability, latency and cost. Count reports, tests, agents and tokens as process costs—not as proof of success.
-
Reset context when the process starts defending itself
After repeated failed corrections, preserve the confirmed requirements and evidence, then start a clean session with a narrower objective. Do not make a model reconcile an endless history of obsolete plans.
Frontier models do not need a miniature corporation built around every request. They need a clear outcome, clean information, appropriate tools and permission to finish.
Use the most capable model when the task deserves it. Do not confuse its capacity to do more work with evidence that more work should be done.