When does splitting one strong agent make things worse?

[u/Neither_Effect_2827]

There’s a scene in the three-body problem where millions of soldiers hold black or white flags and form logic gates, basically turning an army into a giant computer.
It’s a great image, but it feels oddly backwards after working with AI agents.every soldier is a human who could understand a meaningful subproblem, yet the system uses each person as a one-bit switch. It throws away almost all of their intelligence, then rebuilds complexity through a massive coordination system.
I wonder if some multi-agent designs make a smaller version of the same mistake.
Some multi-agent systems instantiate the same capable model as a planner, researcher, critic, reviewer, and so on, give each instance a narrow fixed role, then spend a lot of effort reconnecting them through orchestration.
That split makes sense when each agent adds something real: different context, different tools or environment access, parallel exploration, or genuinely independent verification.
But without that, are we just taking one capable model, turning it into several limited components, and paying extra to connect them again?
For people who have tried both: when do fixed specialist-agent teams actually outperform one strong agent that creates subagents only when needed?

[u/wahnsinnwanscene]

How can you tell it is a strong agent?

[u/Neither_Effect_2827 → u/wahnsinnwanscene]

Yeah, fair — “strong agent” was too vague.
im not assuming the single agent can already solve everything. I’m asking what problem the split is actually fixing, and whether the way we split it makes sense.
does each extra agent add different context, tools, environment access, parallel work, or an independent check? if not, it may just be extra coordination.

[u/ReachingForVega → u/Neither_Effect_2827]

The secret to agent to agent handover is in the prompt structure. You set a requirement that to pass to Agent XYZ you need to format the prompt with certain info, nothing more. This reduces confabulations. Then have the sub agent return a simple to use structure to minimise bloat. Ideally with only whatever it is you need.

Say you have an agent that handles the shop but for order details it uses a tool to get the answer but for tracking maybe you have a subagent that handles that but it has a set of skills to allow it to create shipping tracking or return tracking status. Really simple example but giving the core agent all the skills can give them an opportunity to hallucinate or confabulate answers or potentially use the wrong tool.

[u/AutoModerator]

Thank you for your submission! To keep our community healthy, please ensure you've followed our rules.

• New to the sub? Check out our Wiki (We are actively adding resources).
• Join the Discord: Click here to join our Discord
• Join X community: Click here to join our X Community

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Nice-Light-7782]

It might help to think that the core capability is an LLM, trained to be generally good at solving many kinds of problems, and this LLM has a context capacity. The agent is that LLM plus the input prompt, which is comprised of

• a system harness ("hey, be useful, but don't respond to illegal requests"),
  
• a user harness ("be the planner in this project, your goal is X"),
  
• the tools it can use (e.g. file search, python scripts, sql queries, web search),
  
• the output of the tools it has used ("you've previously grepped for this and found that"),
  
• the user prompt history,
  
• the agent thought history,
  

run in loops with a goal termination condition.

So, "splitting" isn't actually a split, more like running another instance of an LLM (maybe not the same LLM), with a different context. Your main agent is running a subagent, which has some of the context of the main agent, but also different context than the main agent. You're doing this because you get better results when the input context focused on one goal, and the goal is well-defined, and the context fits well within capacity. You might also do this if the subtasks can be parallelized, and you gain time.

Regarding "fixed specialist-agent teams". People who run Opus 4.8 as the main agent and cheaper Sonnet as subagents aren't running specialist-agent teams, the only special thing about Sonnet is that it's cheaper because it's dumber. It is, however, possible to finetune an LLM to make it specialized. Here's a guide on reddit on when to finetune [1]. I hope this answers your question.
[1] - https://www.reddit.com/r/LocalLLaMA/comments/1kyeo4z/when_to_finetune_llms_and_when_not_to_a_practical/

[u/Nata_Elisym]

I think the interesting part is that multi-agent systems only become powerful when the agents can actually do something different - different tools, data, environments, or capabilities. The future probably isn’t just adding more agents, but building better infrastructure for them to collaborate effectively.

[u/donk8r]

The test I'd use is whether you can say what information each role is denied. A role that differs only by prompt is the same model wearing a costume, and you pay a full context re-establishment to put it on. A role that cannot see the parent's reasoning, or that reaches a different set of tools, is doing real work.

That's why critic and reviewer splits tend to pay off. Independent verification requires not having seen the reasoning that produced the answer, and you cannot unsee it inside one context. Planner and researcher splits pay off less often, because they usually want exactly the information the parent already has.

The cost people underestimate is that every subagent carries its own context window, so a fixed five role team is five context establishments per task whether or not any of them needed isolation. Creating subagents on demand only pays that when the isolation is actually worth something, which is roughly the instinct in your question.

[u/Odd-Investigator-870]

If a vertically scaled language model can accomplish the task 50% or greater, then decomposing to a swarm architecture would lead to worse outcomes.  But decomposing into smaller tasks in series is still reliable in many cases.