- VentureBeat's October 10 article argues that AI agents can each be correct yet fail together, because errors arise in handoffs, shared state, loops and shared blind spots.
- It matters because checking only each agent or the final answer misses where multi-agent failures start and spread.
- Ask teams for workflow traces, schema-checked handoffs, protected state fields and a test of whether reviewer agents fail on the same cases.
A relay team can have four fast runners and still lose the race. The baton gets dropped between them. Nobody checks the runners one at a time and finds a fault.
Multi-agent AI has the same shape. In a guide published October 10, VentureBeat makes a point that matters to anyone funding these systems. A group of agents can produce a wrong result even when no single agent is at fault. Testing each agent, or only the final answer, misses where the failures live.
The risk is in the gaps between agents
In a multi-agent system, one agent's output becomes the next agent's context. The article names several ways this goes wrong. A handoff can drop or distort facts. The shared record of the case can drift away from the truth. A workflow can freeze or spin without ever finishing. Agents built on the same model can repeat each other's mistakes instead of catching them.
This fits WebPulse's view that AI multiplies risk. The article makes the mechanism explicit: language models are nondeterministic, so a wrong output from one agent is passed along and grows through the rest of the workflow. One small error becomes the next agent's trusted input.
How the checks work
The article borrows from a familiar method. Teams that build retrieval-augmented generation (RAG) systems, where a model answers from documents it looks up, test the lookup and the answer separately. That shows which stage caused a bad result. The article applies the same split to each handoff between agents.
First, tracing. The workflow must record which agents ran and in what order, plus retries, loops, termination decisions, and the latency, token use and cost of each step. Without that record, a team knows the result failed but not where.
Second, the handoff itself. Was the relevant information passed on? Did the next agent keep its meaning, or add things the handoff never contained? The article also wants agents to exchange structured data, such as a JSON schema or Pydantic model, instead of free text. A schema can be checked by plain code before the next agent runs.
Stuck workflows and drifting memory
Two failure types are easy to picture. In a deadlock, an orchestrator waits for a worker's result while the worker waits for instructions from the orchestrator. Neither moves. In a livelock, agents keep talking but make no progress. The article's example is one agent asking another for clarification, and being sent the same request back because the same detail is still missing.
The article treats these as properties of the whole workflow, not of any one agent. It suggests tracking completion rate, deadlock rate, infinite loop rate, average handoffs and abandoned workflows.
Shared state is the workflow's working memory. The article's example is a support case holding a customer ID, plan, issue, identity check and refund eligibility. A "state manager" compares the state before and after each agent acts.
It runs two types of checks. Rule-based checks catch a changed customer ID, a missing field, a stale value or a conflict with a business rule. A second AI evaluator looks for lost facts, distorted summaries and unsupported additions.
When every reviewer thinks alike
The most useful warning for buyers concerns model monoculture. If a planner and a reviewer run on the same underlying model, the reviewer may share the planner's blind spots. The result is a system that looks well checked and is systematically wrong.
The article's test is failure correlation: do the agents fail on the same cases? Different wording or different documents does not prove different blind spots. If agents repeatedly fail together, their apparent diversity adds little protection.
The lesson: let the model think, but not decide the plumbing
The article's goal is not to make language models deterministic. It is to make their unpredictable behavior visible, measurable, bounded and recoverable. Its principle is that collaboration should not rely entirely on model decisions. Schemas, iteration limits and state rules should sit in code that does not improvise.
The lesson here is plain. Agents are a new kind of employee, and employees are not trusted without process. The control layer is that process. It must be dull and strict so the reasoning can stay flexible. The article names LangGraph, which represents workflows as stateful graphs, as one way to build it.
One limit applies. The article is a method, not a measured study. It reports no failure rates from real deployments, so it cannot tell you how often these failures happen.
Questions to put to your team
Can we see a full trace of every agent run, including retries and cost? What happens when a handoff fails its schema check: reject, retry or reroute? Which fields can no agent change, such as a customer ID? What stops a loop from running indefinitely? And do our reviewer agents run on the same model as the agents they review, and have we measured whether they fail on the same cases?
The gap between agents is where a team's AI quietly goes wrong. Put your strictest rules there.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: VentureBeat.
