Blog9 min read
One Agent for Execution, Multiple Agents for Thinking
When should you use one AI agent or several? Keep execution with a persistent agent and bring in independent perspectives when a hard question benefits from debate and evidence.
By Ntense

Multi-agent AI systems sound powerful. One agent becomes the product manager, another the software architect, another writes the code, another tests it, and another deploys it. It looks like an AI company: idea → PRD → plan → development → testing → deployment.
For many tasks, that design can be less effective than one capable AI agent. The problem is not the number of agents. It is what happens every time work moves from one agent to the next.
Why an AI assembly line loses context
A product manager understands why a requirement exists, but the developer receives only the product requirements document (PRD). The developer makes implementation decisions, but the testing agent sees only the resulting code. Each handoff compresses the reasoning into an artefact, and the reasoning is often the part the next step needed.
A single long-running agent can hold the whole journey: idea → PRD → plan → build → test → improve. So if one agent can already execute a long workflow, where do multiple agents actually earn their cost?
One agent for execution. Multiple agents for thinking.
Don't build an AI assembly line. Build an AI roundtable.
The real strength of multiple agents is not passing work down a line. It is looking at the same problem from different perspectives.
Suppose you are deciding whether to add a product feature. Instead of asking one AI, “Should we add this feature?”, you convene a temporary roundtable:
- Product manager — looks at user value.
- UX designer — looks at friction.
- Engineer — looks at technical feasibility.
- Growth expert — looks at adoption and retention.
- Customer advocate — looks at the problem from the user's side.
- Skeptic — has one job: challenge everyone else's assumptions.
They are not completing six stages of a workflow. They are all discussing the same question. That distinction is what changes the value of a multi-agent system.
Example: a roundtable redesigns a feature question
Here is an illustrative scenario. An AI-native accelerator is considering automatically scheduling daily check-ins with its users. A single assistant would probably list advantages and disadvantages and recommend one. A roundtable behaves differently:
- Product manager: Daily check-ins could help users keep momentum. Many people do not fail because they cannot do the work; they fail because they stop.
- User advocate: Mandatory daily meetings could quickly become annoying. Users need control over how often the system contacts them.
- Behavioural expert: Frequency may need to change over time. Daily contact can help at the start of a project; established users may need fewer interventions.
- Engineer: Adaptive scheduling means tracking engagement, progress, and missed check-ins. This is a user-state problem, not a calendar feature.
- Skeptic: We are assuming users want meetings at all. What evidence shows a meeting beats an asynchronous message?
- Growth expert: The metric that matters may not be attendance. It may be whether the intervention keeps users progressing toward their goal.
The agents are not just generating more text. They are changing each other's thinking. The skeptic exposes an assumption, the engineer reveals an implementation consequence, the user advocate identifies friction, and the product and growth perspectives redefine success.
The discussion converges on a better question:
Not “Should we schedule daily meetings?” but “When and how should the AI intervene to keep a user progressing?”
That reframing is where multiple agents can outperform a single linear workflow.
How do you stop AI agents agreeing with each other?
Multi-agent discussions have their own failure mode: AI groupthink. If agent B immediately sees agent A's reasoning, it may follow the same direction. Agent C can then build on agent B. Five agents can converge on one opinion rather than test different hypotheses.
The fix is to let each agent investigate independently first, form its own hypothesis, and only then enter the shared discussion.
PROBLEM
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Product agent Engineer agent User agent
↓ ↓ ↓
Independent Independent Independent
analysis analysis analysis
│ │ │
└──────────────┼──────────────┘
↓
SHARED ROOM
compare assumptions → challenge →
investigate → debate
↓
Shared conclusionGive the agents tools, not just personalities
Five AI characters that each express an opinion add little. The roundtable becomes useful when every expert can investigate:
- a research agent can use the browser;
- an engineer can inspect a repository and run shell commands;
- an infrastructure expert can read logs and check services;
- a data analyst can query data;
- a network specialist can test endpoints;
- a QA agent can reproduce the problem.
The conversation then moves from “I think this might be the problem” to “I tested that hypothesis, and here is what I found.”
Example: a slow API after a deployment
Another illustrative scenario: an API suddenly becomes slow, and several specialists enter the room.
- Infrastructure agent: CPU, memory, and network utilisation show no saturation.
- Database agent: One query averages 4.8 seconds. Running EXPLAIN now.
- Application engineer: Today's deployment changed the recommendation query. Comparing it with the previous version.
- Database agent: The query is doing a sequential scan over 3.2 million rows.
- Skeptic: That explains a slow query. Does it explain the timing of the whole API regression? Compare request traces before and after the deployment.
The agents investigate again. The swarm is no longer role-playing a technical team. It is functioning like one.
Why the skeptic may be the most valuable agent
The most valuable agent is not necessarily the smartest specialist. It may simply be the one willing to ask:
- Why?
- What evidence supports that?
- What assumption are we making?
- What would prove this wrong?
- Did we consider the opposite explanation?
Models tuned to be helpful and agreeable can converge too quickly. A deliberately adversarial role prevents premature consensus. For a startup idea, one agent argues why it should exist while another tries to kill it. For an architecture decision, one architect optimises for scale while another optimises for simplicity and cost. For a PRD, the product manager pushes for capability while the user advocate removes everything unnecessary.
The goal is not conflict for its own sake. It is to expose assumptions before they become decisions.
Where an AI roundtable works best
A roundtable helps most when there is no obvious answer:
- Product design — product, UX, engineering, customer, and growth perspectives examine the same PRD.
- Architecture — security, reliability, cost, performance, and development specialists challenge the same design.
- Debugging — application, database, infrastructure, and network agents independently investigate the same failure.
- Startup strategy — founder, customer, competitor, growth, and finance perspectives test the same opportunity.
- Research — several researchers investigate independently before a fact-checking and synthesis stage.
- Code review — security, performance, maintainability, and testing specialists inspect the same change.
- Creative work — writer, director, designer, and audience perspectives challenge the same concept.
Use a roundtable when the problem benefits from diversity of thought more than division of labour.
Keep one agent persistent
None of this means everything should become a committee. Most work should continue through one persistent AI partner that understands your goals, previous decisions, project history, and current context. When it meets a question where multiple perspectives would help, it convenes a temporary roundtable.
USER
│
↓
Persistent AI partner
│
┌────────┴────────┐
│ │
Normal work Complex question
│ │
↓ ↓
Single agent Spawn roundtable
│
┌────────────┼────────────┐
↓ ↓ ↓
Expert Expert Expert
└────── Discussion ───────┘
│
↓
Shared conclusion
│
↓
Persistent AI partner
│
↓
ExecuteThe experts do not need to stay. They appear when their perspective is useful, investigate with tools, challenge one another, and disappear. The persistent agent keeps the result and continues executing. You keep the context without giving up multiple perspectives.
The human still owns the decision. A roundtable can surface evidence, disagreement, and a sharper question; it cannot take responsibility for the outcome. Its conclusion is an input to your judgment, not a replacement for it.
From agent swarm to expert panel
“Agent swarm” may be the wrong mental model. A swarm suggests many autonomous workers doing tasks at once. For knowledge work, a better analogy is an expert panel. Imagine being able to ask:
- “Bring five experts into the room and challenge this business idea.”
- “Have a security engineer, cloud architect, DevOps engineer, and cost specialist debate this architecture.”
- “Something is wrong with our application. Assemble the right experts and find out why.”
The AI partner decides which perspectives are needed. You do not configure agents, prompts, or workflows. You bring a problem into the room.
The next AI interface may look like a meeting room
Today's dominant interface is one human ↔ one AI. Many multi-agent systems try to turn that into one human → many AI workers. A more useful model may be one human ↔ a room of AI perspectives.
You bring the problem. Each AI examines it differently. They research, disagree, test hypotheses with tools, and respond to each other's evidence. You reach a clearer understanding and a stronger decision. Then one persistent AI partner takes the result and gets back to work.
Sources
- Don't Build Multi-Agents — Cognition Accessed Sat Sep 26 2026 00:00:00 GMT+0000 (Coordinated Universal Time). Recommends sharing full context and agent traces rather than individual messages, states that actions carry implicit decisions and conflicting decisions carry bad results, and recommends a single-threaded linear agent as the simplest approach.
- How we built our multi-agent research system — Anthropic Accessed Sat Sep 26 2026 00:00:00 GMT+0000 (Coordinated Universal Time). States multi-agent systems excel at breadth-first queries pursuing independent directions with subagents in parallel context windows; domains needing shared context or many inter-agent dependencies, including most coding tasks, are a poor fit; agents use about 4x and multi-agent systems about 15x the tokens of chat.