Multi-Agent System Design

Some technical screens include a question that sounds purely technical but is not. You are told that a system is running in production, that it is misbehaving, and that a customer is unhappy. You are then asked to walk through how you would diagnose the problem and how you would explain the fix. The question is testing more than debugging skill. It is testing whether you understand that production failures have two halves, and that both belong to the job.

This article follows one scenario from start to finish. The system is a multi-agent system that is intermittently dropping state between two agent handoffs. The customer deployed it recently, and the failure is not constant. It shows up only sometimes, which makes it harder to reproduce and harder to explain. We will trace where the state goes, learn how to structure the diagnosis, and then look at how to explain the fix to the customer.

A multi-agent system is made of several agents that pass work to one another. In the source scenario, state is passed from one agent to another at a handoff, and state is sometimes lost in that transfer. The diagram below shows the general shape of the flow that the diagnosis has to follow. Read it as a sequence of messages: the first agent sends state, the handoff carries it, and the second agent receives it. The failure is reported to occur somewhere along that path.

The diagram is a simplified picture, and the source does not describe the internals of the customer's system. What matters for the diagnosis is the comparison it implies: for any given run, you can ask what Agent A sent and what Agent B received. If those two differ, the loss happened in transit or at the receiving boundary. If they match, the state was lost somewhere else, and the investigation moves elsewhere.

The diagnosis begins with the handoff, because that is where the failure is reported to occur. Because the state loss is intermittent, the first task is to establish what differs between the runs that succeed and the runs that fail. A strong answer names this as a deliberate step rather than jumping straight to a guess about the cause. The guess can come later, once the evidence has been collected and compared.

The flowchart below lays out the order of checks. Each result decides which check comes next. It is a structure for thinking, not a fixed script, but it captures the sequence a strong answer would describe.

A useful way to reason about state loss is to follow the state object itself as it moves. Imagine a state record that carries several fields. Each agent reads some fields, may add or change others, and passes the record on. A field can disappear at any transition where it is not carried forward. The worked example below uses an invented, simplified record to show the method. The field names are illustrative and are not taken from the customer's system.

The second half of the answer is the conversation with the customer. The source treats this as part of the job, not as a courtesy added after the engineering work is finished. Explaining a fix in the customer's terms is part of resolving the failure. A useful explanation tells the customer what was happening in terms they can follow, what was changed to stop it, and what they should expect from the system now.

A customer-facing explanation of this scenario might say that the system sometimes dropped part of the shared information as it moved from one step to the next, that a change has been made at that transfer point, and that the team is monitoring subsequent runs to confirm the change holds. It does not need the names of internal fields, and it does not promise that the problem can never happen again unless the evidence supports that claim.

The most common way candidates answer this kind of question incorrectly is to treat the failure as a purely engineering problem. The candidate focuses on finding the bug, fixing it, and verifying the fix, and the customer is treated as someone who will eventually be informed by somebody else.