Failure halfway through a run
The published failure guidance is about a wrong answer, not an abandoned multi-step run with three side effects already committed — the difference decides what your UI owes the user.
Two things go wrong in your agent on the same afternoon.
In the first, the model reads a supplier invoice and returns the wrong total. Nobody has spent anything. A human looks at it, sees it is wrong, fixes the number, moves on. Annoying, cheap, fixable in the cell where it happened.
In the second, the agent creates the purchase order, emails the supplier, and then fails when it tries to write to the ledger. Nothing is wrong. Two things are true. The purchase order exists and the supplier has read the email, and the run is over.
Both land in the bug tracker as “agent failed.” They are not the same event and they do not have the same interface. The published failure guidance addresses the first one. This lesson shows you where to look, so you can say that as a demonstration rather than as an opinion.
Taxonomy one: Google sorts errors into three kinds
The current edition of the People + AI Guidebook devotes a chapter to Errors + Graceful Failures. Its chapter worksheet prints the taxonomy in full. Three types, verbatim:
- System limitation — “Your system can’t provide the right answer, or any answer at all, due to inherent limitations to the system.”
- Context — “The system is ‘working as intended,’ but the user perceives an error because the actions of the system aren’t well-explained, break the user’s mental model, or were based on poor assumptions.”
- Background — “Situations in which the system isn’t working correctly, but neither the user nor the system register an error.”
Now try to file the purchase order into one of those. It is not a system limitation: the system did exactly what it can do, twice, and then hit a write failure. It is not a context error: nobody is misperceiving anything, the email really was sent. It is not a background error: the failure is loud and the user knows about it. The taxonomy is complete and correct for the kind of system it describes, and your case has no row.
The nearest thing the worksheet has is a single checkbox under its Failure state section: “Is your feature unusable as the result of multiple errors?” That is a question about the feature degrading, not about unwinding effects the feature already committed elsewhere.
Taxonomy two: Microsoft sorts by phase, and stops at the answer
The five HAX guidelines under When wrong — G7–G11, invocation, dismissal, correction, scoping and explaining — were walked in detail in the suggest-versus-act lesson. The summary that matters here: every verb in them acts on an offer that has not produced an external effect, and G9’s own worked examples in Table 1 are an editable reminder and an autocomplete suggestion.
The stronger test is Microsoft’s newest, agent-labelled guidance, because it was written in 2026 with agents explicitly in scope. The Human-centered design for agents page has a section called When the system is wrong. In full, on the point:
Agent outputs are occasionally incomplete, inaccurate, or misaligned with intent… Provide clear and efficient correction pathways. Users should be able to regenerate responses, revise prompts, or manually edit outputs without friction.
Regenerate, revise, edit. Those are three things you do to a paragraph. Seven years after CHI 2019, on a page whose subject is agents, failure is still a bad output. There is no sentence here about an email that went out, a record that was written, or a payment that cleared. Microsoft sells the agent platform this page documents, and the page carries ai-usage: ai-generated in its own metadata — both worth saying when you cite it, and neither one changes the reading.
Where the case would go, and the shape of the hole
Put the three taxonomies side by side with one failure and the absence stops being a claim and becomes a table:
| Taxonomy | Closest slot for “two steps committed, third failed” | Why it does not fit |
|---|---|---|
| Google PAIR, three error types | Background error | Background is about failure nobody registers. This one is visible and loud. |
| HAX G7–G11 | G9, support efficient correction | Its worked examples are pre-execution edits. There is nothing to edit; there is something to unwind. |
| Microsoft agents, When the system is wrong | Regenerate the response | Regenerating produces a second output. The first one already sent an email. |
Three publishers, three vocabularies, one shared assumption: the unit of failure is a piece of output. When the unit of failure is a set of committed effects, all three vocabularies describe the wrong object.
The searches, so the absence is checkable
You are about to stand in a room and say something is not there. Have the search ready:
- The PAIR errors worksheet, read in full. A hit would have been a fourth error type, or any language about effects committed outside the product. The taxonomy is three, and the only compounding language is the feature-unusable checkbox.
- HAX Table 1, guideline text and example-application column. A hit would have been one G7–G11 example involving an action already taken. None.
- Microsoft’s agent design page, full text. A hit would have been any undo, rollback or compensation language. None anywhere on the page.
- Nielsen Norman Group, searched for agent failure, partial completion, rollback and undo across multi-step runs. A hit would have been any NN/g piece on action-level failure in agent UX. Nothing came back.
The claim that is false, and the one next to it that is true
Do not say nobody has written about undoing partial agent actions. Engineering has, at length and currently: compensating transactions and saga-style rollback are an active 2026 discussion, and the material that surfaced in the search above was engineering-blog content on exactly that. It is real, and it is not design guidance, and it is not from any publisher in this canon.
The true claim is the narrow one: the published UX design canon has no equivalent. Distinguishing those two sentences is the whole skill. The first gets you corrected by the nearest backend engineer. The second is something you can defend, and it points at the useful question, which is what the interface owes a user once the engineering has done what it can.
What the interface owes, which is this course’s position
Nothing above tells you what to build. The demonstration establishes an absence; it does not fill it. What follows is this course’s own argument, and it should be offered as one.
A run that stops partway owes the user an accounting before it owes them an apology. Three specific things, in this order:
- What committed. Named, in the user’s vocabulary, not the tool’s. “The purchase order was created and the supplier was emailed” — not “2 of 3 steps completed.”
- What did not. The step that failed, and every step after it that never ran. This is the half people skip, and it is the half that decides what the user has to go do by hand.
- What is reversible and by whom. The purchase order can be voided in the app. The email cannot be unsent by anyone. That distinction is a property of the world, not of your agent, and the interface is where the user finds out.
No published source recommends this. It is an inference from the shape of the hole, and the strongest form of it in a room is: the frameworks stop at the output, so we had to decide this ourselves, and here is what we decided and why. That sentence is credible precisely because it does not claim a citation it does not have.
Retrieval check
Your agent fails on step three of four. Which of the three published taxonomies would you cite while describing the failure, and what would you say about it?
Check your answer
Cite Google’s, because it is the most complete and the mismatch is cleanest: PAIR sorts errors into system limitation, context and background. Ours is none of them — the system worked, the user is not misperceiving anything, and the failure is loud. The taxonomy is good and it was built for a system that produces answers. Ours produces effects, so we needed a fourth category and we wrote it ourselves.
The move is to praise the taxonomy for what it does before saying what it does not do, and then to own the extension rather than implying Google endorsed it. Citing a framework accurately and then departing from it deliberately reads as expertise. Citing it vaguely and departing from it accidentally reads as not having read it.
Check the distinction
Answer from memory — no scrolling back.
Hands on
File your worst failure into all three taxonomies
Done when: A short note in POSITIONS.md under the Google row that names one concrete multi-step failure, shows where it would go in each of the three taxonomies, says why each slot is wrong, and states in one sentence what you think the interface owes the user.
- Write down one concrete failure in under forty words. Real if you have one, plausible and specific if you do not. Name the steps that committed and the step that failed, in product vocabulary.
- Attempt the filing three times: Google’s three error types, HAX G7–G11, and the Microsoft agent page’s When the system is wrong section. For each, write the nearest slot and one sentence on why it does not hold.
- Write the accounting the interface would show. What committed, what did not, what is reversible and by whom. Three lines, in the words a user would use.
- Add the falsification line to the Google row’s What would change my mind cell. Make it specific enough to be checked: a named publisher adding a failure category for committed effects would do it. “More guidance” would not.
- Bring the three-line accounting into the chat. The test it has to pass is whether a person reading it knows what they now have to do by hand — if it leaves that ambiguous, it is a status message rather than an accounting.
What this does not cover
This lesson is about the failure that has already happened. It says nothing about how much certainty to project before one does, which is the over-hedging lesson: G10 says to scope services when in doubt, and that lesson argues it in both directions with the trust research on each side. It also takes the three publishers at their word about what kind of document each is publishing, and that assumption is what the platform-and-consultancy lesson pulls apart. The suggest-versus-act lesson before this one is where the reversibility argument was established, and it is worth re-reading if the phrase the offer stays inert did not land the first time.
Read this next — primary source
Errors + Graceful Failure — chapter worksheetPeople + AI Research (PAIR), Google — fetched 2026-09-05. Google publishing design guidance about the category of product it sells; PAIR sits in Google Research rather than a product org, which earns a little credit and not a pass. Free PDF, current third edition.
This is the only fetchable artifact of the current edition’s error chapter, and it is the sharpest form of that chapter’s content: a workshop sheet that asks a team to enumerate the ways their feature can fail. Read it as a checklist and then try to file your own worst agent failure into one of its three error types. Doing that yourself is the whole lesson — the argument here is an absence, and an absence you have personally failed to fill is worth more than one you were told about. It is an exercise sheet rather than the chapter’s full prose, so treat it as one window onto the chapter, not the chapter.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.