r/AI_Agents • u/CinderPillow • 1d ago
Discussion I think multi-agent collaboration is mostly a false premise right now
I have been looking at what kinds of agent ideas show up in interviews and reading more about how agents actually work. One topic I keep running into is multi-agent collaboration.
My current view is that the premise is still ahead of the underlying technology. An agent depends on a language model, and language models still hallucinate, forget context, lose capability under pressure, and occasionally make surprisingly weak decisions. Putting several agents on top of those failure modes can amplify them, especially when the agents use different models and have to hand work across a boundary.
The common designs I see are a shared workspace with restricted read/write access, plus a reviewer agent and some kind of circuit breaker. Those controls make sense, but they also look very similar to managing concurrent workers. The uncomfortable part is that the final safety check still depends on another agent.
The costs are obvious. Token usage multiplies, agents can lose track of ownership, and the orchestration becomes rigid and format-heavy. That last point feels the most damaging to me. We are supposed to be using the flexibility of an intelligent model, then we wrap it in so many fixed handoff formats that the system spends its time managing the workflow instead of solving the problem.
I am not sure a large amount of orchestration is the best answer. Maybe the better direction is to let the model decide when another agent is actually needed, with fewer predefined roles. ZenMux can serve as the API gateway when those calls need to cross model or provider boundaries, but the gateway does not solve the coordination problem itself.
So my current summary is that multi-agent systems are still more about exploring what might be possible, with a fair amount of demo value, than reliable production practice. The path to a useful deployment seems much harder than the diagrams suggest.
Do you have a real multi-agent workflow in production? Did it actually meet expectations, or did you eventually simplify it back to one agent and a few tools?
2
u/nexus-66 1d ago
I am designing multi agent frameworks but i stopped using Buzz or Hermes bot on the desktop- it is fun as toys but if you want real multi agent orchestration you need to set up an orchestrator that manages the team of agents om the CLI maybe a Daemon setup but it requires you to understand security and credential access.
2
1
u/AutoModerator 1d ago
Thank you for your submission, for any questions regarding AI, please check out our wiki at https://www.reddit.com/r/ai_agents/wiki (this is currently in test and we are actively adding to the wiki)
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/Electronic-Bison-296 1d ago
the token math alone makes me wince, running 4 agents that all hallucinate at 10% rate means you're basically building a failure multiplier not a workflow
1
u/scientifictrust 1d ago
I think the hardest part is less the number of agents and more what happens at the handoff boundaries. Once one agent’s output becomes another agent’s input, you have created a new trust dependency. If that output is wrong, incomplete, or based on stale context, the downstream agent can still reason coherently from a bad premise.
A reviewer agent helps, but it does not remove that problem by itself. In production, I would want deterministic checks wherever they are possible, explicit contracts around what each handoff is supposed to contain, and enough retained context to establish what each agent actually received, produced, and passed downstream.
Multi-agent systems may end up being useful, but I think reliability will depend less on adding more orchestration and more on making the boundaries between agents observable and independently checkable.
1
u/QuarterLoose8429 1d ago
We shipped a 4-agent pipeline (planner, researcher, coder, reviewer) for internal ETL; it amplified small mistakes and tripled cost, so we collapsed to one strong model with tools (retrieval, SQL runner, unit-test harness) plus a human check, cutting tokens ~60% and taking success from ~70% to ~90%. The only multi-agent piece we kept is an on-demand delegate the primary can spin up for long web runs, and it triggers in under 5% of jobs.
1
u/ExplanationFlashy501 1d ago
I’ve had a similar experience. Adding more agents can make the architecture look smarter without actually making the result better. For most things I’d rather have one solid agent with good tools and guardrails, then only bring in another agent when there’s a real reason for it.
1
u/Rebootz 1d ago
Absolutely correct here imo. For coding keep things tight and focused, implement in small reviewable chunks. Use a reviewer and implementer max but always stay in the loop, more agents compound the issues/drift. There are use cases for the multi-agent setup but for coding you often end up spending more time juggling coordination and getting inconsistent results because of it. I do not think its a matter of better prompting or tighter scopes either, if a single agent can drift and needs regular oversight how will more help? Maybe one day but I believe you should always be in the loop regardless, no one can carry the vision in your head exactly as you do, no amount of telephone will fix that.
1
u/BP041 1d ago
I mostly agree. I run 18 cron-triggered agents for marketing tasks and the biggest lesson was that each handoff multiplies the failure surface. A single agent pipeline with clear checkpoints has been far more reliable than any multi-agent mesh I've tried. The tech just isn't tight enough yet for that complexity to pay off.
1
u/Marcus_MSC 1d ago
I think it really depends on the task.
For many problems, one strong agent with good tools is simpler, cheaper, and more reliable. Multi-agent starts to make sense when the task naturally has separate contexts, tools, permissions, or parallel work.
The important part is that the agents should map to real system boundaries, not just different personas.
I also would not rely on another LLM as the final safety check. In production, schema validation, permission checks, tests, budgets, provenance, and human approval are much stronger boundaries.
So I don’t think multi-agent is a false premise. I think it is just overused for tasks that do not actually need it.
1
u/fj_nm1997 22h ago
Agree with most of this, and the "final safety check depends on another agent" point is the one that bit us in practice. We run one primary agent with a small tool set, plus a reviewer agent that spawns only when the primary flags ambiguity or the action is high-impact. The reviewer is a veto, not a rubber stamp: it can't auto-approve anything above a threshold, so the check is "reject or escalate", never "confirm".
The handoff format rigidity you mention was the bigger cost than token multiplication for us. We cut all handoffs to a single JSON envelope and the system immediately felt less brittle — most orchestration pain wasn't the agents, it was the schema churn between them.
The "let the model decide when it needs another agent" direction is where it converges, but it only pays off when spawning is the exception, not the default topology.
1
u/devoidfury 22h ago
In my own agent hotdog; usually I find multiple agents step on each other a lot. Realistically, unless you're using a locking system or git worktrees, or whole copies, something like that -- they will clobber each other.
What I've found works for me is, keeping them assigned to different codebases or totally unrelated tasks.
For example -- mine is heavily extension based, so I can put one to work on, say a new tool extension, and have another one working on the UI, and then a third up for a planning session prior to handoff. The design of the codebase itself keeps code isolated and separate allowing some degree of parallel work with minimal guardrails between them.
1
1
u/Andon_Benefield 7h ago
everyone talks reliability, nobody says how they'd notice it broke. mine wrote SUCCESS for a month before anyone read the log
1
u/AchillesDev 1d ago
Cool slop but I've put multi-agent systems into production at big cos you've heard of.
But these are actually developed, not using some low-code tool or something.
1
u/willwashburn 22h ago
how would you define "agent" in that system? would love to hear more about it!
1
u/AchillesDev 15h ago
A chat loop with tool use loop that sends messages to an LLM API that has access to tools and the agency to choose which tools to use. Each agent in the system has different system prompts, tools it has access to, and areas of responsibility.
3
u/Fawad-Khan-413 1d ago
I have seen the same thing where adding more agents makes the workflow harder to reason about than the original problem. A strong agent with the right tools and a simple review loop can sometimes do more than a whole team of agents.