Your agent broke something. Now what?

At some point, an agent on your team is going to do something you'll need to undo. Send the wrong renewal quote. Update the wrong account. Escalate a ticket that wasn't urgent. Reassign an opportunity to the wrong owner.

And, when that happens, the first question isn't "which model was that." It's "how did it get there."

A lot of teams aren't set up to answer that yet. Kore.ai's 2026 Agent Productivity Index, cited in its Autoloop launch, found that 79% of enterprises have already reversed an agent action, and 70% have hit a failure they couldn't trace. Those numbers aren't surprising. They're what you get when agents ship into production with the same observability we'd accept for a batch job, and none of the reconstructability we'd expect from a person.

This is a practical guide for the people who have to run that review: RevOps and CS leaders who own the outcome, and the people building the agents.

Capture the moment first

The single most useful thing you can do after an agent incident is also the easiest to skip. Before anyone "fixes" the record, freeze what the systems said when the agent acted.

By the time you sit down for the review, someone has usually corrected the price, reassigned the owner, or closed the ticket. The data now looks fine. The agent looks careless. It wasn't. It was right about a world that no longer exists.

So, before anything else:

• Screenshot or export the source records the agent read.
• Save the agent's run: prompt, tool calls, retrievals, and final output.
• Note the timestamp. You'll need it to compare what was true then vs what's true now.
• Write down, in one sentence, what the agent did that you had to undo.

If you don't have that frozen moment, the rest of this becomes archaeology. You'll guess. And, guessing is how reviews end with "the model was wrong."

A worked example: the wrong renewal quote

Here's a hypothetical, but very familiar, version of how this review goes when you have the evidence.

What happened. An agent sent a renewal quote to a customer at the old list price. The customer replied that they'd signed an amendment since. CS had to reverse the quote, apologize, and reissue.

What the run showed. The agent read the opportunity, pulled the amount field, drafted a quote, and sent it. Every tool call succeeded. The output matched the input.

What was true at the time. Opportunity amount: the original contract price, not updated since the deal closed. Contract amendment: a lower price, living in a separate contract system, never written back to the opportunity. Renewal owner: the AE who'd closed the original deal, who no longer works the account.

What a useful write-up looks like.

• Action: Sent renewal quote at the original price.
• Facts relied on: Opportunity.Amount (original price); Opportunity.Owner = the original AE; no open cases flagged as P1.
• Sources: Salesforce Opportunity, with the time it was read. Contract system: not queried. Billing: not queried.
• Belief at the time: Price on the opportunity is current. Decision-maker is still the original AE.
• What's true now: The amendment lowered the price. Current commercial owner is the CS lead.
• Owners of the systems involved: RevOps (Salesforce), Legal/Deal Desk (contracts), CS (account relationship).
• Root cause: The agent treated the opportunity as authoritative for renewal price. The amendment lived in a system it wasn't connected to, and nothing wrote the new price back. Not a model failure. A gap between systems.
• Fix: Connect contract amendments into the agent's renewal context, or require a price confirmation against the contract system before any quote goes out. Update the opportunity amount as part of the amendment process, so humans and agents see the same number.

Notice what that write-up does. It doesn't ask who to blame. It names the facts, the sources, the then-vs-now gap, and the people who own each system. That's enough to run Five Whys without ending in silence, and enough to run a blameless review without inventing a villain.

If all you had was the trace, you'd see a clean success: read, draft, send. Nothing in a normal log knows the gap exists.

False roots vs real ones

The hardest part of these reviews is usually steering away from the wrong conclusion.

"The model was wrong." Rarely the useful answer. The model did what models do: it used the context it was given. If the context said the old price, a correct model will quote the old price. Blaming the model is how you buy a bigger one and keep the same incident.

"The prompt was bad." Sometimes. A better prompt can ask the agent to check a second system. But, a prompt can't invent a connection that doesn't exist, and it can't tell the agent that an amendment lives somewhere it can't reach. If the fix is "remind the agent to look harder," you probably haven't found the cause.

"The person who deployed it should have tested more." Testing catches some of this. It doesn't catch the amendment that landed after the pilot, in a system nobody wired up. Process ownership belongs in the room. Personal blame doesn't.

Real roots look more like this. The agent never saw the system that held the truth. The record it trusted was stale and nobody owned keeping it current. Two systems disagreed, and the agent had no way to know which claim won. A permission or connector hid a field the agent needed. The agent remembered something that used to be true and treated it as still true.

Same shape every time: missing provenance, stale context, or unresolved identity across systems. We've written before about why governance falls apart when agents don't share your view of reality. This is that problem, after the fact.

How Five Whys and blameless reviews still help

I'm not precious about methodology. Use what your team already trusts.

Five Whys is still the fastest way from symptom to cause. With agents, it almost always stalls at the same place: the why that needs you to know what the agent knew. If you captured the facts, sources, and then-vs-now gap above, you can keep going. If you didn't, you'll stop one why short and call it "model error."

Blameless postmortems translate better than people expect. Find the failure, not the person. If anything, that matters more with agents, because it's easy to point at whoever deployed it, or the vendor, or the model. The blameless question is the same as always: what information was available, and what made this the reasonable choice at the time? A person can tell you. An agent can only tell you if you recorded it.

Both assume you can reconstruct the decision. With people, that's mostly true. With agents, it's only true if you built for it.

What to capture before the next agent goes live

This is the part that saves you later. A postmortem is only as good as the evidence the agent left behind, and most of that evidence has to be designed in before production.

For each agent you're about to put in front of a customer or a revenue process:

• Declare the facts it is allowed to act on. Price, owner, status, entitlement...list them. If a fact isn't on the list, the agent shouldn't use it silently.
• Require a source on every fact. System, record, field. No anonymous context.
• Record a belief snapshot with every consequential action. What did the agent think was true when it sent the email, updated the field, or created the quote?
• Keep then separate from now. Don't overwrite the snapshot when someone fixes the record. You'll need both.
• Name the system owners in the agent's runbook. So, when something breaks, you know who to invite without inventing a war room.
• Decide what "undo" means before you need it. Who can reverse the action, how, and what gets written down when they do.

If that sounds like more process than you wanted, fair. But, it's cheaper than a review where half the room is guessing. It's also the difference between context engineering and context management: one is what you stuff into the prompt, the other is the infrastructure that lets you explain an action later.

Same lesson as when an agent took two and a half minutes to count to a number: the failure is rarely in one step. It's in the harness around the steps.

Checklist for the next review

When the next undo lands:

1. Freeze the moment before anyone edits the source records.
2. Write one sentence describing the action you reversed.
3. List the facts the action relied on...not the whole prompt, the few claims that drove the decision.
4. Trace each fact to its source, including when it was last updated.
5. Compare then vs now. Where they differ is usually the story.
6. Invite the owners of every system the agent touched or should have touched.
7. Run Five Whys or a blameless review with that evidence in the room. Stop when you reach a gap between systems or a missing piece of context, not when someone says "the model got it wrong."
8. Fix the context, not just the output. If the agent couldn't see the amendment, make sure the next one can.
9. Write the lesson where the next agent can use it. A doc teaches people. Updated context teaches the system.

What we're building at SixDegree

A big part of what we build is the layer that makes step 4 and step 5 ordinary. Identities, relationships, observations, history, and provenance across the systems you already run, without syncing data into another box. So, when an agent acts, the facts it used still point back to where they came from and when they were true. And, when something goes wrong, the next why has somewhere to go.

Frequently Asked Questions

Do I need a special process for agent incidents?

No. Use Five Whys, a blameless postmortem, or whatever your team already runs. The difference is the evidence: you need the facts the agent acted on, their sources, and what was believed at the time.

Are logs and traces enough?

They're necessary, not sufficient. Traces show the sequence. They don't show whether the facts were current, complete, or from the right system.

Who should be in the room?

Whoever owns the agent, plus whoever owns each system it read or should have read. For most revenue incidents that's RevOps, CS, and whoever owns contracts or billing.

What's the first thing to fix after an undo?

The context the next agent will see. Reversing the action protects the customer. Updating what agents can know protects the next customer.

Book a working session

If you've already had to undo something an agent did and the review never quite landed, bring the run and we'll walk through it. Book a working session.