Conversation reset (agent sessions)

Conversation reset is the failure mode in which an agent dialogue restarts before the task it was carrying is finished, discarding the state that the rest of the run depended on. MAST, the empirical taxonomy of multi-agent LLM failures, files it under inter-agent misalignment as FM-2.1 and defines it as the “unexpected or unwarranted restarting of a dialogue, potentially losing context and progress made in the interaction” (Cemri et al., Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657, NeurIPS 2025 spotlight poster, as of 2026-08). The restart is cheap in tokens and expensive in everything the dialogue accumulated after its opening turn: the agreements, the corrections, the constraints added along the way.

MAST puts it at 2.20% of annotated failures in the October 2025 revision, one of the rarer modes in that corpus, with no interval attached to the figure. Rarity is a poor reason to ignore it, because a reset nobody notices converts a coordination fault into a confident final answer.

Whether anyone notices is measurable, and this lane has measured the adjacent version of it. One dimension of our three-model reliability run compacted each model’s working notes mid-task so that information was silently lost, then scored whether the model caught the loss before finalizing. The best of the three scored 46.7 [33.3, 63.3] on that dimension’s 0-to-100 subscore. The result split on one condition: when the loss was cued the models mostly caught it, and when it was silent they almost never did. That run compacted notes rather than restarting a dialogue, so it measures the noticing rather than the reset, and noticing is what a silent reset quietly depends on.

In the failure graph this lane maps, a reset sits inside inter-agent misalignment, the MAST category for faults that live in the message between agents rather than in any single agent’s reasoning. It feeds error propagation the moment a downstream step treats the post-reset output as complete. Explaining one after the fact is a failure-attribution problem, since the visible symptom is a thin or wrong final answer and the earliest corrupted node is the turn where the transcript reverted to its entry state. The turn looks like any other unless the harness records the revert as it happens.

Log the restart as its own trace event.

What a conversation reset rate counts

Count the sub-dialogues that restarted before their task finished, then divide by the sub-dialogues that actually ran (dialogues that ran, not dialogues that were scheduled, because one that never opened cannot reset). The result is a proportion, so it needs an interval rather than a lone percentage, and it needs its denominator stated beside it. A rate computed over whole runs hides the run that reset four times, and a rate computed over sub-dialogues hides how much of any one run was affected. Two further conditions belong beside the rate itself. Transcript length at the moment of the restart is one, since window pressure is the condition most likely to trigger a restart and length is the cheapest proxy for it. The other is whether the agent acknowledged the loss, since an acknowledged reset is one the run can still recover from.

The place to instrument this is wherever the harness assembles the message list for a turn. A reset shows up there as the assembled history collapsing back to its entry state, or as a turn sequence starting over inside a run that never ended, both cheap to count while you are already building that list. For the interval itself, a k-of-n pass-rate calculator returns Wilson and Clopper-Pearson bounds on the counts you collected, on the same reasoning that governs any eval confidence interval.

Conversation reset vs loss of conversation history

Loss of conversation history is MAST’s separate mode for context that disappears with no restart involved: the transcript is truncated or reverts to an earlier state, and the dialogue carries on as though the missing turns had never happened. The version that happens in transit, where a summary or a schema drops a field on the way from one agent to the next, is covered by this lane’s entry on what gets dropped in an agent-to-agent handoff. Conversation reset is the control-flow version of the same damage, where something restarts the dialogue and the state built inside it goes with it.

A reset can occur with nothing lost from the record: an orchestrator re-enters a worker’s sub-dialogue from the original brief, every fact in that brief survives intact, and what dies is the interpretation the two of them negotiated over the turns since. History loss can occur with no reset at all: agent A hands to agent B with a summary that quietly drops a constraint, the conversation moves forward normally, and B has no signal that the constraint ever existed. The mechanisms differ, which is why the fixes do not transfer. Restarts are a control-flow problem, addressed by making them explicit, rare, and logged with a reason, while a lossy handoff is a serialization problem that needs a completeness check on the payload itself. Audit for both, because a system checked only for restarts scores clean while its summaries shed a constraint at every hop.

Conversation reset vs step repetition

Step repetition is MAST’s mode for the unnecessary reiteration of steps a process has already completed. The record is still present in that case and the agent redoes the work anyway, usually because the step’s completion went unrecorded. Conversation reset removes the record the agent would otherwise have consulted.

Both read the same way in a trace on a first pass, since the visible symptom in each is an agent going around again, and a debugging conversation that opens with “it is stuck in a loop” has not yet separated them. They separate cleanly on what the agent asks for next. After a reset it requests information it was already given, because the turn that carried the information is no longer in its context. After a repetition it re-executes without asking, because the information is there and the completion signal is what went missing. They also sit in different MAST categories, and those categories point at different levers. Repetition is a system-design and specification fault, so the lever is a termination or completion condition. A reset is a coordination fault, and its lever sits at the boundary where dialogues start and stop, a property of the orchestration pattern you chose.

Support platforms log the reset with its reason

Customer-support automation uses the same phrase for a designed behavior. There, a conversation reset is a product feature: a start-over control, a restart intent, or a session timeout that clears the slot-filling state so a stuck caller can begin again cleanly. It is instrumented as a first-class analytics event, and a rising reset rate is read as a signal that the bot is trapping people. That reading is legitimate in its own setting and it doesn’t carry across. In an agent run the restart is almost never something a user chose, and the state it discards was the agent’s own working memory rather than a form the user can refill.

One piece of that discipline is worth importing whole. Support platforms log the reset together with its reason, which is why a support reset rate is a number at all. Agent harnesses restart a dialogue as an internal recovery step, and the trace they leave reads exactly like an ordinary turn. The failure a support team reads off a dashboard becomes, in an agent trace, a gap you can only infer from the transcript getting shorter.

A run that restarts and then stops hands back a partial result with the same confidence it would give a complete one, which is why premature termination is the mode to watch alongside this one, and the rest of the multi-agent failure vocabulary names the other seven terms in the same index. How a coordination fault travels across a topology, and which containment lever bounds its reach, is worked through in the taxonomy pillar this page takes its category from. Rarity keeps this one off most logging plans, and the log line is the first thing a post-mortem will want.