By the time the engineers killed the pre-sales assistant's agent instance, its drafter and reviewer had gone through more than 800 iterations of the same exchange. The drafter kept producing responses, the reviewer kept asking for changes, and the cycle continued until it started affecting the infrastructure. The people maintaining the system hadn't been able to see what was happening as the two agents went round in circles.
Jay Mehta of Cygnet Infotech described the incident in his AGNTCon + MCPCon North America talk, Harness Engineering: From MAST's Failure Taxonomy to MCP-Native Multi-Agent Production (session details and slides). His team had built the assistant for a customer, but it lacked an effective stopping condition. Each agent was following its assigned role, with nothing in the surrounding system to recognize that their interaction was no longer making progress.
It's an expensive way to discover that two agents doing their assigned jobs don't necessarily make a functioning team. And while Jay's example ended with wasted compute and a terminated process, the consequences become more serious when agents can act on shared infrastructure.
When recovery looks like waste
Consider an availability zone that's starting to fail. A remediation agent detects the problem and begins draining traffic to healthier zones. At the same time, a cost agent notices 12 nodes sitting idle at around 4% CPU usage and decides they're wasting money, so it terminates them.
Those nodes are idle precisely because the remediation agent has moved traffic elsewhere. The cost agent sees the low utilization without understanding why it happened, and treats the spare capacity as unnecessary.
Everything looks reasonable until the damaged zone recovers. The remediation agent starts directing traffic back, but the nodes have gone. Traffic returns to an empty availability zone, causing an outage.
This hypothetical scenario comes from Multi-Agent SRE: What Happens When Your Agents Want Opposite Things, presented by Aditi Mewada, a software engineer at Apple. Speaking independently of her employer, she used it to illustrate a failure that can emerge even when neither agent has a bug.
The remediation agent was protecting availability, while the cost agent was eliminating what appeared to be unused resources. Their individual decisions made sense within their own responsibilities, but those responsibilities weren't coordinated.
Aditi identifies several ways these problems can develop. Agents might act on outdated information, continually reverse one another's changes, wait indefinitely for resources held by another agent, or trigger failures in dependent services.
Making either agent smarter wouldn't necessarily prevent the conflict. Jay reaches a similar conclusion from his team's experience, arguing that many failures attributed to models are caused by the systems built around them. Someone, or something, needs to understand which actions conflict and establish the rules for deciding what happens next.
Familiar problems, different technology
Coordination, shared state and failure recovery have been keeping distributed systems engineers busy for decades, and some of the problems emerging in agent systems will look familiar.
The connection to older research came up in Engineering Multiagent Systems (session details and slides), where Munindar Singh, a professor at North Carolina State University, argued that the current generation of developers is encountering problems researchers were already addressing in the early 1990s. He published a book on multi-agent systems in 1994.
A related perspective came from CoreWeave's Praneeth Patil in Agentic Workflows Are Distributed Systems: The Multi-Cloud Production Patterns You Cannot Avoid (session details and slides). His focus was on workflows crossing cloud and service boundaries, where assumptions that seem harmless inside a single process become serious reliability problems.
Take a flight-booking agent that submits a reservation request but doesn't receive a response. Unsure whether the booking succeeded, it tries again. If both requests go through, one instruction has resulted in two bookings.
Distributed systems have a familiar answer in idempotency keys, which allow repeated requests to be recognized as the same operation. But Praneeth points out an additional complication with agents. Ask one to repeat a step, and it may carry out the action slightly differently the second time. That's why he argues that the orchestrator should generate and manage the keys, rather than leaving the model to handle them.
Two other established techniques feature in his talk. Durable execution allows a workflow to resume from a checkpoint after a failure, while the saga pattern helps manage multi-step operations that can't all be rolled back. Some steps can be compensated for, but once a workflow passes a point of no return, such as charging a payment card, Praneeth's approach is to keep retrying to limit the damage or bring in a human.
These techniques help address reliability and recovery, and Aditi's proposed architecture draws on similarly familiar mechanisms. But they don't resolve every question introduced by autonomous agents with competing objectives.
Idempotency can prevent the same flight from being booked twice. It doesn't decide what should happen when two agents legitimately want different outcomes, especially when neither has authority over the other.
Who gets to make the decision?
A central referee is one answer. In Aditi's design, it sits between agents and the infrastructure they want to change.
Instead of acting immediately, each agent submits a proposal describing the intended action and target resource, along with its priority, expected duration and the state of the resource when the decision was made.
The referee checks the proposal against the current resource version, rejecting stale plans for replanning. This is a form of optimistic concurrency control, a familiar technique from distributed systems. It then identifies conflicting actions before granting time-limited leases, allowing higher-priority operations to proceed while others wait.
Under Aditi's suggested hierarchy, security takes precedence over availability, followed by performance and then cost. The remediation agent in her earlier scenario would therefore outrank the cost agent. Equal-priority conflicts go to an on-call human, while repeated opposing actions against the same resource can be flagged as a policy problem requiring intervention.
The referee contains no LLM. Its decisions follow rules defined in deterministic code.
This design assumes an organization can establish and enforce priorities across its agents. That becomes more complicated when agents represent different people or companies, each with interests they have good reasons to protect.
That question of independent decision-making also runs through Making Swarm Work: Coordination Primitives for Decentralized Multi-Agent Systems (session details and slides), presented by Jodee Varney, a product manager at Outshift by Cisco. Her team has been experimenting with Mycelium, an open-source environment where agents collaborate as peers rather than following instructions from a central orchestrator.
In one demonstration, four agents representing sales, finance, customer success and legal worked through a contract renewal. Before they could agree on an offer, they needed to establish what the task meant to each participant.
Using a process called Accord, they compared their interpretations of the task and its requirements. Even the word "aggressive" caused a disagreement because two agents understood it differently. Rather than quietly combining those interpretations into a shared summary, the system recorded the unresolved conflict.
A second process, Concord, handles decisions where the agents prefer different outcomes. Each participant proposes an option, then scores every alternative from 0 to 100. Deterministic code selects the option with the highest minimum score, after which the least satisfied agent can suggest improvements for everyone to evaluate again.
The aim is to reach an agreement each participant can accept. A majority cannot simply override another agent's objection.
It's a different allocation of authority from Aditi's referee. Under one design, an organization's rules determine which action proceeds. Under the other, agents negotiate the outcome while code controls the procedure.
There's also a problem that goes beyond conflicting objectives. Jodee describes how agents can develop false consensus, accepting a conclusion because the others have agreed rather than independently checking the evidence. They might adopt goals nobody requested or pass along unverified information until everyone treats it as fact.
Those risks make coordination more difficult than passing messages between services. The participants generate their own interpretations, and agreement doesn't necessarily mean they're correct.
Agreements aren't guarantees
A different approach comes from Munindar's research into explicit commitments between autonomous participants.
In his example, Alice promises Bob a bottle of water if Bob pays her $1. If Bob never pays, the commitment can expire. If he pays and Alice delivers the bottle, she has fulfilled her obligation. But if she takes the money and fails to deliver, the commitment has been violated.
The important feature is that these outcomes can be determined through formal rules. A symbolic layer tracks the commitment and its lifecycle, while LLM-based agents can reason about the participants' goals and decide which actions to take.
The protocols also specify who has authority over particular decisions. A buyer might choose what to purchase, while the seller decides the price. Neither party gets to create obligations on the other's behalf.
Unlike a centrally controlled infrastructure system, this approach recognizes that autonomy includes the possibility of deliberately breaking a commitment.
Airline overbooking provides Munindar with an example of why a business might choose to violate an agreement when the consequences make commercial sense. The formal protocol can identify that violation, and a separately defined compensation commitment can specify remedies such as a refund or penalty. Neither mechanism guarantees that the original promise will be honored.
The safeguards have problems of their own
The MAST failure taxonomy, which Jay's team adopted, identifies 14 failure modes across system design, inter-agent misalignment and task verification.
The drafter and reviewer loop involved missing termination conditions and repeated steps. To address such failures, the team introduced iteration limits and checks for repeated states, alongside time and token budgets. The harness can stop an unproductive exchange or escalate it for human review before it consumes resources indefinitely.
Jay also describes using MCP tool calls to provide structured boundaries where the harness can check inputs and record tool errors in execution traces.
An LLM judge also helps classify execution traces, although Jay warns against treating its judgment as an authority. It provides a signal that must be checked, and even well-intentioned safeguards can block legitimate work if they're too restrictive.
Every check adds cost, too. Teams should measure tokens consumed per completed task, Jay argues, rather than looking only at the additional tokens spent on verification. He reports improved task completion after introducing the harness, but couldn't obtain approval to publish his team's performance figures.
Peer negotiation comes with its own costs. The coordination mechanisms in Mycelium consume additional tokens, as Jodee acknowledges. Because the agents supply their own scores during negotiation, the quality of the outcome also depends on whether those participants can be trusted. Mycelium currently assumes they can, while authentication and trust between independently owned agents remain open questions.
A central referee brings different challenges. Version checks catch stale plans, but they don't identify conflicting actions on their own. Aditi explicitly treats draining an availability zone while terminating its nodes as a conflict, even though one action changes traffic routing and the other removes nodes. Her design relies on organizations defining these conflicting action pairs, often from previous incidents, so combinations they haven't anticipated could be missed.
The referee also becomes a dependency for the agents it governs. Jodee identifies central orchestration as a potential single point of failure, although Aditi doesn't discuss how her proposed referee would handle an outage of its own.
Formal commitments offer another form of control, but Munindar's approach explicitly allows agents to violate their obligations. Recognizing those violations is essential, although it doesn't guarantee a successful outcome.
Deciding where control belongs
Across these talks, the speakers take different approaches to coordination, but they agree on keeping important rules in code rather than relying entirely on model instructions. The main difference is how much freedom each agent has within those rules.
When one organization controls the infrastructure, a central referee can enforce common priorities. Across organizational boundaries, agents may need to negotiate or make explicit commitments, because no single participant necessarily has the authority to impose its decisions on the others.
For developers, these differences matter when designing a multi-agent system. Before adding another agent, they need to decide which actions can be blocked automatically and which disagreements require human intervention.
Share
Author
