COMMUNICATION AND PROTOCOLS BETWEEN AGENTS

TERMINATION AND DEADLOCK AVOIDANCE Multi-agent systems introduce failure modes that single agents do not have. One is the runaway conversation, where agents keep passing a task around forever and never finish. Another is deadlock. A deadlock is a situation in which two or more parties are each waiting for the other to do something, so none of them can ever proceed. Imagine two polite people at a narrow doorway, each saying, "After you," and each waiting for the other to go first, forever. In agents, Agent A may be waiting for a result from Agent B, while Agent B is at the same time waiting for a result from Agent A. Neither will ever make progress. Because agents are patient, they may wait silently for a very long time, burning no tokens but also doing no work, which can make this failure invisible. A related problem is a livelock, where agents are busy but make no progress, such as bouncing a request back and forth again and again, each time slightly rephrasing it. The good news is that there are simple, reliable defenses. First, define clear termination conditions. Every multi-agent run should have a definition of done, such as "the reviewer approves the draft" or "the final report is written," and a hard stop if it is not reached. You learned about ending a run in Chapter 26. Second, set limits. Cap the number of handoffs, the number of rounds between two agents, the total time, and the total budget, as you learned in Chapter 25. If a run exceeds a limit, stop it. Third, use timeouts. Every wait for another agent should have a maximum duration. If the time passes without a reply, the waiting agent should stop waiting and take a defined fallback action instead of waiting endlessly. Fourth, detect cycles. The harness can track the sequence of who handed work to whom and notice a repeating pattern, such as A to B to A to B, and break it when it repeats more than a few times. Fifth, break deadlocks by escalation. When a deadlock or cycle is detected, the best fallback is often to stop the agents and escalate to a human or to a higher-level supervisor with a clear report of what happened, rather than guessing. Sixth, design to avoid circular waiting in the first place. If the graph of who waits on whom has no cycles, deadlock cannot occur. A simple way is to make dependencies flow in one direction, as in a pipeline, and to avoid designs where two agents each need the other's answer first. Choosing the timeout value is a judgment call. Too short, and you kill healthy work that is just slow. Too long, and you waste time and money on stuck work. A sensible approach is to look at how long the task normally takes, using your observability data from Part Seven, and set the timeout at a comfortable multiple of the usual time, such as two to three times the typical maximum. You can then tune it with experience.