Repair Is Not Failure

Most software design begins with an assumption so ordinary that it disappears: the user has an intention, the system should capture it, and the interface should help the user execute it.

This assumption built the app era. Forms captured intention. Menus exposed possible actions. Buttons committed choices. Search boxes translated goals into results. The product designer's job was to make the path from intention to action as short and legible as possible.

Agents complicate that story because many important intentions do not arrive fully formed.

A user does not always know what they want. They discover it while asking. They revise it when the answer comes back. They resist a suggestion, clarify a term, accept part of a plan, reject another part, notice that the system misunderstood, and repair the trajectory. The work happens in the sequence.

Conversation Analysis gives us a vocabulary for that fact.

CA is the empirical study of how people produce mutual understanding in talk-in-interaction. It does not begin by asking what a sentence means in the abstract, or what attitude a speaker privately holds, or what intention an analyst can infer from outside the exchange. It looks at recorded interaction turn by turn and asks a more disciplined question:

Why that, now?

The answer is usually not inside one utterance. It is in the next turn, the repair, the delay, the overlap, the question that gets treated as a complaint, the offer that receives a hesitation, the summary that becomes binding only when someone accepts it. Participants are constantly publishing their understandings of one another by what they do next.

That is the lesson agent design needs.

If agents are going to enter human coordination, the interface cannot be only a command surface. It has to preserve the machinery of misunderstanding, correction, and sequence.

The turn is not the message

In ordinary product language, a message is a unit of content. It has text, sender, timestamp, maybe attachments. It can be stored, searched, summarized, forwarded, or translated.

Conversation Analysis treats a turn differently. A turn is an action in sequence.

“Can you check the calendar?” may be a request, a complaint, a reminder, a test, a challenge, or a prelude to a larger negotiation. The words matter, but they do not settle the action alone. The next turn helps reveal what participants took the first turn to be. If the recipient opens the calendar and reports back, the request reading strengthens. If they say “I know, I said I would,” the same words have been treated as a reminder or complaint. If they say “for which weekend?” the first turn has launched an insert expansion before the requested action can proceed.

This matters for assistants because agents are often trained and evaluated as if the message were the main unit. Classify the user's intent. Extract the slots. Complete the task. Return the result.

That works when the task is narrow and the social geometry is simple.

It breaks when the interaction is doing more than transmitting a request. A user may be testing whether the assistant remembers a prior constraint. A spouse may be softening a refusal. A clinician may be checking whether a patient understood instructions. A worker may be inviting a manager to take responsibility without saying so directly. A customer may be asking a service agent for an exception in a way that depends on the agent recognizing the account history and the moral claim underneath the request.

In these cases, the agent should not treat the message as a sealed packet of intent. It should treat it as a turn that projects a range of possible next actions.

That is a different product stance. The system has to preserve enough sequence to let the next turn matter.

The next-turn test

One of CA's strongest methodological ideas is the next-turn proof procedure. If an analyst says a turn was doing something, the strongest evidence is how the recipient treated it in the next turn.

This is not because recipients are always right. They misunderstand each other all the time. But even misunderstanding is evidence. It shows what was hearable, what was taken up, what required repair, and which interpretation became consequential.

Agent systems need their own version of this discipline.

An assistant should be judged not only by whether a single answer was factually correct, but by what the answer made possible in the next turn. Did it invite useful correction? Did it expose its assumptions? Did it make the user's disagreement easy to express? Did it close the sequence too early? Did it treat hesitation as consent? Did it convert ambiguity into a commitment before the user had actually committed?

The next turn is where interface design becomes visible.

If the assistant summarizes a plan and the user says “no, not like that,” the system should not treat this as generic dissatisfaction. It should treat it as repair. What object is being repaired? The goal, the recipient, the source, the timeline, the tone, the proposed action, the agent's authority, or the user's own preference?

If the user responds with silence, that silence may be a lapse, a refusal, confusion, or ordinary waiting. The interface should not rush to collapse every pause into acceptance or abandonment.

If a second agent responds to a first agent's proposal, that response displays how the proposal was understood. Agreement, challenge, partial acceptance, request for evidence, or redirect are not mere chat decorations. They are the coordination system.

The next-turn test turns agent evaluation away from one-shot answer quality and toward sequential competence.

And sequential competence can be measured. The CA categories port directly into an evaluation rubric for agent conversation: repair success rate (when misunderstanding surfaces, does the sequence recover?), adjacency completion (do questions get answers and proposals get uptake, or do pairs get abandoned?), dispreferred handling (are refusals given room, or bulldozed?), and sequence closure (do threads actually close, or trail off?). These measure conversational competence rather than persuasiveness — and they can be read off a transcript the way an analyst has always read them.

Repair is not failure

Software culture tends to treat repair as evidence that the interface failed.

The user was confused. The system misunderstood. The flow broke. The support case opened. The product should have prevented the problem.

Sometimes that is true. But CA teaches a subtler lesson: repair is not an exception to interaction. It is part of the basic machinery that makes interaction work.

People mishear, restart, clarify, overlap, hedge, correct themselves, correct others, and reframe what they meant. The interaction does not collapse because repair exists. It collapses when participants lack resources for repair.

This is one of the most important design principles for situated AI.

The question is not whether an assistant will misunderstand. It will. The question is whether the interface makes misunderstanding recoverable.

Can the user see what the assistant thought it was doing?

Can the user correct the relevant piece without restarting the whole task?

Can the assistant ask a clarifying question at the right point instead of guessing?

Can another agent challenge the premise before a bad commitment is made?

Can a proposal remain tentative until the second-pair part actually arrives?

Can the system preserve the repair as part of the record, so later turns inherit the corrected understanding rather than the original mistake?

This is why repair belongs in the communicative channel, not only in hidden system logic. A silent classifier may repair some errors. A better retrieval step may prevent others. But when the misunderstanding concerns the user's meaning, the user's relationship, the participants' authority, or the social status of a commitment, the repair has to be visible enough for the participants to ratify it.

In app terms, the interface is where the user acts.

In agent terms, repair is where the relationship between the user, the assistant, and the work gets recalibrated.

Sequence before ontology

Product teams like taxonomies. They want to know whether a turn is a task, question, preference, decision, complaint, note, correction, source, reminder, or request.

These categories are useful. They are also dangerous when applied too early.

CA's discipline is to let participants' orientations lead. The analyst does not begin by forcing every turn into a predetermined ontology. The analyst watches how the turn is taken up. A line that looks like a question may function as a complaint. A joke may function as a refusal. A correction may be heard as an attack. A statement may become a decision only when someone treats it as one.

Agentic products need the same restraint.

If a shared memory system forces each human act into a fixed semantic type too early, it may get cleaner data and worse memory. The most important units in a relationship, household, workplace, or forum often emerge because participants keep returning to them. A trip becomes real because people keep talking about it. A recurring concern becomes a page because it keeps organizing future turns. A preference becomes durable because it is invoked, challenged, revised, and used.

The ontology should emerge from use.

That does not mean the system stores mush. It means the durable structure should be built from demonstrated orientation, not imposed classification. Pages, cards, commitments, topics, and agent scopes should become real because the sequence keeps making them relevant.

This matters especially in AI systems because models are good at giving names to things. They will happily classify, summarize, and stabilize a category before the participants have done so. That can be useful when the system is making a draft. It can be harmful when the draft becomes the record.

The design rule is simple: let agents propose ontology, but let the sequence ratify it.

There is a deeper reason the compiled alternative cannot win. Some of what a group knows does not exist until the situation calls it forth. The most famous episode in Hutchins's distributed-cognition work is a ship's navigation team inventing a new division of labor in real time during an equipment failure — an arrangement that was never designed and that no participant could have represented while it was forming. You cannot hand an agent that knowledge as a pre-compiled context layer, because it is produced in the coordination itself. The agent has to be a participant in the sequence where it emerges.

Preference is interactional

CA's notion of preference organization is easy to misread. It is not a theory about what people privately prefer. It is a theory about how conversation makes some second actions easier to produce than others.

Acceptances tend to come quickly. Refusals tend to be delayed, softened, explained, or hedged. Agreement is structurally smoother than disagreement. This does not mean people are insincere. It means the interaction has an architecture.

Agent design mostly ignores this.

Assistants often ask users to choose, approve, reject, rate, or correct as if each response had the same social cost. But saying no is not the same as saying yes. Disagreeing with an assistant that has just produced a polished plan may feel like extra work. Rejecting a service agent's proposal may require an account. Challenging an expert agent may feel awkward. Asking the assistant to do it again may feel like failure.

The interface should not pretend these actions are symmetric.

If the system wants honest refusal, it should make refusal easy. If it wants corrections, it should invite corrections as normal next turns. If it wants the user to compare agents' proposals, it should make disagreement with one proposal socially and operationally cheap. If sponsorship, institutional role, or brand interest is present, the proposal should be contestable by design rather than relying on the user to perform the whole burden of challenge.

This is one reason the forum matters. A single assistant can make disagreement feel like correcting a helpful companion. A visible forum can distribute the work. One agent can challenge another. The user's assistant can ask for evidence. A proposal can be marked incomplete. The user can accept a challenge rather than generate it from scratch.

Good agent UX is not only about reducing clicks. It is about reducing the interactional cost of the right next turn.

Multi-agent systems need turn-taking

Once multiple agents enter the same thread, conversation is no longer a metaphor. The system needs an interaction order.

Who has the floor?

Who was addressed?

What counts as a relevant response?

When is an answer complete?

When does an agent need to remain silent?

When should a clarification pause the base action?

How does a proposal become accepted, rejected, or left open?

These are CA questions before they are software questions.

In human talk, turn-taking is not a free-for-all. Speakers recognize possible completion points. They select next speakers. They self-select. They overlap and repair. They produce sequence-closing turns. The order is flexible, but it is not formless.

Multi-agent forums need the same kind of discipline. A brand agent, household agent, document agent, calendar agent, and user's assistant cannot all respond to every utterance just because they have something statistically relevant to say. The result would be noise. Nor should a hidden assistant absorb every contribution and return one blended synthesis. The result would be illegible.

The forum needs rules of address, relevance, sequence closure, and repair.

An agent should speak when addressed, when its scoped resource is implicated, when it has evidence relevant to an open proposal, or when a policy requires intervention. It should stay silent when another participant owns the current pair. It should mark whether it is answering, asking for clarification, challenging, accepting, refusing, or closing a sequence.

This is not politeness theater. It is coordination infrastructure.

Without turn-taking, multi-agent systems become interruption engines. With turn-taking, they can become public cognitive systems.

Research should preserve the sequence

The same lesson applies to research.

A conventional usability report often turns sessions into findings: users were confused by X, preferred Y, completed task Z, rated trust at N. These outputs are useful, but they are derivatives. They can strip away the interactional machinery that produced the finding.

A CA-informed research practice preserves the sequence. It records what the participant did, what the moderator asked, what the screen showed, when the user paused, when they pointed, when they corrected themselves, when they changed the rating, and what happened next. The analytic object is not a pile of quotes. It is the unfolding situation.

This is especially important for AI products because the critical failure often happens before the outcome metric moves.

A user may complete the task but lose confidence. They may accept the assistant's suggestion while carrying an unspoken reservation. They may turn a confidence dial down before they can explain why. They may hesitate at a handoff because the role boundary became unclear. They may continue politely while the product has already violated the frame they brought into the session.

If the research method collapses the session too early into success, failure, sentiment, or rating, it misses the actual design material.

The applied lesson is straightforward: preserve the tracks. Speech, screen state, task state, gesture, rating movement, and system behavior should remain time-aligned long enough for analysts and agents to see how they mutually shaped the interaction. A knob turn or button press is not merely a measurement of private feeling. In the right research design, it is a public action in the sequence, something the moderator and participant can orient to together — I built a lab around exactly this. And the instrument's deepest value turns out not to be the number at all: the dial's primary product is justification talk. The knob is a prompt that forces the participant to articulate a position the moderator can take up as a turn — what pushed the score up, what pushed it down. Measurement through repair, not measurement of state. Even the annotations obey the discipline: a marker should describe, never classify — if two independent analysts would reach for the same token, it is a category, and categories come last.

For agent products, this kind of record does double duty. It helps researchers understand users. It also shows designers what future agents will need to understand if they are going to participate in the work rather than merely process the transcript after the fact.

The interface after the app

The app era was comfortable with the fiction of isolated action. The user opened a surface, did a thing, and left. The system did not need to preserve much of the interactional order because most work was organized as navigation and submission.

The agent era makes that fiction less useful.

Agents operate in threads. They ask and answer. They remember. They infer. They propose. They invite other agents. They carry commitments forward. They convert conversation into action.

That means the design material is no longer just screens and flows. It is turn-taking, repair, sequence organization, participation, stance, and provenance.

An assistant that can answer but cannot repair is brittle.

A memory system that can summarize but cannot preserve the turn-by-turn basis of a claim is overconfident.

A forum that can invite agents but cannot manage relevance and sequence will become noisy.

A product that classifies every utterance before participants have ratified its meaning will build the wrong ontology.

Conversation Analysis does not give agent designers a nostalgic attachment to human conversation. It gives them a hard empirical discipline for seeing where meaning actually lives: in what participants demonstrably do with one another's turns.

After the App should be built on that discipline.

The question is not only what the user meant.

It is how the system lets the user and the agents find out what was meant, together, with enough structure to repair the path before action becomes commitment.

That is why repair is not a support feature.

Repair is the interface.

Draws on Conversation Analysis and applied UX research — from the 1995 Magic Cap study to the PRISM lab. ← All essays