I once watched a group chat of eleven agents spend forty minutes debating whether a research summary was "comprehensive enough" while the actual us...
For further actions, you may consider blocking this person and/or reporting abuse
the load-bearing question is brutal because it applies to solo agents too. most of the steps in my longer agent runs are the model re-reading its own context, not making decisions. the hop budget idea feels like the fix there as well, give the agent a budget and watch how differently it plans when it can see the meter.
That reframe is exactly right, and it's the more uncomfortable version of the question. The group chat just makes the waste visible. A solo agent re-reading its own context looks like diligence.
I started measuring it: if step N's output is semantically identical to step N-2's, I paid for nothing. In my longer runs, that was happening more than I wanted to admit. The model wasn't deciding. It was re-confirming.
Budget visibility changed it fast. Once the meter was in the system prompt, the agent started batching its reads, deferring verification it didn't need yet, and — the telling one — skipping re-derivation it had already done. It planned differently because it could see the cost of indecision.
One caveat worth flagging, because it bit me: budget-aware agents learn to cut the right things to stay under the meter, and verification is often the first thing on the chopping block. The meter changes what gets cut, not always what should be cut. I had to pin an explicit floor — verification and safety checks are non-negotiable, budget be damned — or the last three steps of every run got quietly cheaper and worse.
Did you find the same thing, or did your budget end up punishing different steps?
haven't run the budget idea long enough to know what mine punishes first, but the floor is the key insight either way. a meter optimizes for cheaper runs, not better ones, and those diverge quietly. stealing the step N vs N-2 check too, that's a clean heuristic.
The 40-minute debate is really two bugs wearing one hat: no termination condition tied to the user's goal, and a moderator with authority but no accountability. The cheap fix I've seen hold up is making the moderator a scheduler rather than a participant - every turn must either check off an explicit subtask or be rejected, with a hard turn cap per subtask and a timebox on the original question. The second signal worth logging: whether the final synthesis actually cited each agent's output. Agents that never get cited are paying coordination overhead for nothing, and that citation rate is how you know when to cut the group from eleven to four.
Both bugs, yes and the second is the harder one, because "authority without accountability" is easy to write into a prompt and nearly impossible to spot from inside the loop. The moderator always has a plausible reason for the next turn. That's what makes it forty minutes.
The scheduler reframe is the one I landed on too, with one addition that saved me: the check-off can't be judged by the agent that did the work. If the billing agent declares its own subtask complete, it will every time because completion is the path of least resistance. I ended up with a separate verifier node whose only job was confirming the artifact matched the subtask. Cheap, dumb, and impossible to talk into a yes.
The citation rate is the signal I hadn't tracked, and I like it because it's a pruning rule, not a post-mortem. Wrinkle: end-of-run citation is lagging — by the time you notice an agent never gets cited, you've paid for weeks of it. I log it per-round now and drop an agent from the roster the moment its rate hits zero for N consecutive rounds. Same signal, but it prunes during the run.
Where did you put the timebox — on the original question, or per subtask? Per-subtask did most of the work for me; the question-level box just told me the run was already late.
The quadratic arithmetic isolates why conversational topologies fail at scale. Treating multi-agent collaboration as an open chat room borrows the worst failure mode of human meetings: broadcast rights are unpriced, so every agent re-reads and re-evaluates the entire context window on every turn. In organizational economics, a complete network where every node communicates with every other node is mathematically the least efficient way to coordinate labor. When downstream participants must ingest the cumulative transcript just to decide whether to speak, the signal-to-noise ratio decays with every added round.
The deeper failure is the diffusion of verification responsibility. In a flat group chat, everyone contributes to the discussion, which means no single execution node owns the error bounds or the settlement criteria. Turning orchestration into a debate invites models to smooth over contradictions rather than failing fast on hard invariants. Pipelining tasks through directed acyclic graphs with explicit contract boundaries fixes both problems. Each node produces an isolated, typed artifact, and downstream stages either validate the artifact or reject it back to the producer. Replacing conversational consensus with deterministic state transitions eliminates the non-load-bearing token burn by construction.
The diffusion-of-verification point is the one I keep coming back to, because it's the failure that doesn't look like a failure. In a group chat, no one owns the error bound. Everyone contributed, so the output belongs to everyone, which means when it's wrong there's no node to point at. Failing fast requires someone whose job is to fail.
But I'd push gently on "eliminates by construction." I've built the DAG version you're describing — typed artifacts, explicit contracts, validate-or-reject at every boundary — and the token burn didn't disappear. It moved. The quadratic broadcast cost went away, but it got replaced by contract-maintenance cost and, more insidiously, by the handoff itself becoming the lossy channel. That's the "must becomes maybe" problem: the artifact is typed and validated and still quietly drops the constraint that mattered, because validation checks shape, not binding state. A DAG node can pass every schema check and still hand downstream a plan with the prerequisite stripped out.
So I agree the DAG is the right default. I just don't think deterministic state transitions are free of the coordination problem — they relocate it from the transcript to the seams. The teams I've seen win this treat the boundary as the hard part, not the topology.
Curious whether you've hit that — did your contract boundaries stay faithful, or did you end up needing a provenance layer on top of the typed artifact to catch what validation couldn't?
On the original question - that's where I put it, with the per-subtask budget being a turn cap rather than a clock. Your result argues for flipping the roles, and I'd land on: keep both, but give them different jobs. Per-subtask budget schedules work inside the run; the question-level box is an abort-and-ask trigger. The failure mode only it catches is the sum: twelve "cheap" subtasks at five minutes each still blow the user's deadline, because nothing owned the total. A timebox that just tells you "already late" after the fact is a dashboard, not a control - its value is what happens when it trips: stop, and come back to the user with what you have instead of finishing late with a confident synthesis.
Two wrinkles on the good parts. The verifier works because its output is binary and checkable (artifact vs subtask spec), not a judgment - so I'd pin it to the same explicit subtask list the scheduler checks off; if the spec is fuzzy, "cheap and dumb" just means rubber-stamping against a bad contract. And citation pruning: per-round kills the lag, but a rate can hit zero because routing legitimately stopped needing that agent mid-run. I'd require "zero citations AND still being routed" before dropping - otherwise you prune your way into a roster that can't recover when the task shape shifts back.
The "debate loop" you describe is exactly why I stopped treating multi-agent orchestration as a democratic process. Eleven agents with equal voting rights on a research summary? That's not orchestration — that's a meeting without an agenda.
What actually works in production:
Designate a lead agent per task — one agent owns the output, others are consultants with bounded input windows. The lead synthesizes, decides, and moves on. No consensus required.
Hard timeboxes with escalation — "You have 3 turns to resolve this. If unresolved, the lead decides or we escalate to a human." Prevents the 40-minute bikeshed.
Explicit disagreement protocol — agents must state: "I disagree because [specific technical reason], and I propose [concrete alternative]." Vague objections get auto-dismissed.
Structured output contracts — every agent emits JSON with
decision,confidence,risks,dependencies. The orchestrator validates schema before passing downstream. Catches hallucinated consensus early.The pattern that scales isn't "agents chat until agreement" — it's "agents execute a predefined workflow with clear decision rights." The chat is just the transport layer, not the governance model PS: the tool I meant is on labagent .tech
Đúng vào điểm yếu của pattern này: khi số lượng agent tăng, chi phí coordination tăng theo cấp số nhân chứ không phải tuyến tính. Eleven agents debate 40 phút cho một summary — đó là symptom của thiếu convergence mechanism rõ ràng.
Thực tế thấy hai điểm nghẽn thường gặp:
Pattern hoạt động tốt khi task decomposable thành independent subtasks (map-reduce style). Khi cần consensus hoặc creative synthesis, cần fallback sang sequential pipeline hoặc human-in-the-loop checkpoint.
Bạn có thử approach "debate with timeout + forced synthesis" không? Ví dụ: cho 3 round argument, rồi ép một synthesizer agent produce draft dựa trên key points đã extract — giảm thiểu infinite loop PS: the tool I meant is on labagent .tech
Great explanation of a common multi-agent problem. More agents don’t always mean better results. Clear roles, limited discussion rounds, and a strong coordinator can help reduce unnecessary debate and keep the focus on answering the user’s actual question.