What should an AI agent’s activity history show so people can check and undo its work?

Illustrative situation: a sales team opens its CRM on Tuesday morning. An AI agent worked overnight, and the only trace is a notification that says “Run complete.” One deal is marked closed-lost that should not be. A customer has received a follow-up email about a contract signed last week. Nobody can tell which agent action caused which problem, which of them can be reversed, or who should fix it. The scene is invented. It shows the moment this guide covers: after the agent has acted.

Humbleteam, a digital product design agency, publishes this guide. Approval before the agent acts is covered in a separate guide, linked at the end. This one covers the record left afterward: what an activity history shows, how reversal differs by action, and how a teammate or support person takes over from it. It includes a reversibility worksheet and an invented worked example. Vendor behavior is described as of November 3, 2026 and can change.

Why is a chat transcript not an activity history?

A transcript records what was said. A history records what changed. When the user watches the agent work, the difference is small. When the run happens while the user is away, a transcript is the wrong tool for checking it.

GitHub Copilot’s cloud agent shows both layers. Its session logs show Copilot’s reasoning and the tools it used. Commits are authored by Copilot with the person who started the task listed as co-author, and each commit message links to the session log, so a reviewer can trace why a change was made during code review or an audit.

Microsoft’s HAX guidelines point the same way: guideline 11 asks for an explanation of why the system behaved as it did, and guideline 9 asks you to make it easy to edit, refine, or recover when the AI is wrong. NN/g’s first heuristic, visibility of system status, says the design should always keep users informed about what is going on. For an unattended run, “always” includes the hours after it finishes.

Our suggestion is three layers. A run summary gives counts and exceptions. A step list shows each action, the object it touched, and its outcome. A detail view shows before and after values, the source the agent used, and the reasoning, one click away.

What should each entry record?

Each step needs enough information to answer four questions: what happened, to what, by whom, and can it be reversed. Our suggested fields:

1. A run ID and a step ID that stay stable, so a support ticket can quote them.
2. Start and finish times.
3. The initiator (a person, a schedule, or a trigger) and the actor (the agent, with the version of its instructions).
4. The person or team the agent acted for.
5. The system, the action in plain words, and the object.
6. Before and after values.
7. The outcome: done, failed, skipped, or unknown.
8. The source the agent relied on and a link to its reasoning.
9. A reversal state: restorable, compensable, or final.
10. A group ID linking steps that belong together.

The fourth field deserves care. RFC 8693 separates two ways to act for someone. Under impersonation, the acting party is indistinguishable from the person within the rights granted. Under delegation, the agent keeps its own identity, and actions are taken by it representing the person. Notion says its agent has the same permissions as the person using it. Our reading: if a downstream system only sees the person’s identity, its own log will blame the person, so your product needs to keep the actor and the person it acted for as separate fields.

How do you show what changed?

Lead with exceptions. A run that finished 50 of 52 steps should not say “Run complete.” Put failed, skipped, and unknown steps above the successes, with a count at the top.

Show values instead of verbs: “Updated deal” tells a reviewer nothing, while “Stage: Negotiation to Closed lost” does. Group steps by object as well as by time, so a person can open one deal and see everything the agent did to it.

Developer tools already tie history to restore points. In Claude Code, every prompt that starts a turn creates a checkpoint, and the rewind menu lists the prompts. Cursor lets you click a checkpoint in the chat timeline to preview your files at that point before restoring. A business app can do the same: select a step, see the object as it was before, then choose to restore.

Which actions can be undone, and how?

There are three kinds, and the history should label each one before anyone asks.

Restorable actions return a field or object to its earlier value. Compensable actions cannot be rolled back, but a new action offsets them: a split after a merge, a cancel after a booking. Final actions leave the system and cannot be recalled, such as an email already read.

Microsoft’s compensating transaction pattern explains why the middle category exists. You cannot always roll back data, because other users or processes may have changed it. The compensating step is application specific and does not necessarily return the system to its starting state.

Even tools built around undo state their limits. Claude Code’s rewind does not track files changed only by shell commands, most subagent edits, outside changes, or symlinked files, and its docs say checkpoints are not a replacement for version control. Cursor says restoring reverts files only, and its checkpoints are stored locally, separate from Git. Our reading: a restore point covers what the tool edited, not everything else the agent touched. Your history has to say which is which.

Time-boxed reversal is a fourth case. Gmail lets people cancel a sent message for 5, 10, 20, or 30 seconds, as set in settings. After that, the message is final. If you offer such a window, show when it closes.

The worksheet below turns this into a table you can fill in for each action your agent can take. The values are suggestions.

What happens when an undo fails or the record has changed?

Treat the undo as a new action with its own entry. The Azure pattern says compensating steps can fail, so the system should record progress and be able to resume. It recommends idempotent steps, so a retry cannot apply the same reversal twice, and end-to-end audit of both the original operation and its compensation.

For the screen, that gives three rules. Check the current state before restoring, and if someone edited the object since, show both changes and let a person choose. Report partial results step by step, and never show a green confirmation while one step failed. Keep the failed undo visible in the history.

Azure’s travel example adds a rule for high-impact cases: when three flights are booked and the hotel fails, the customer decides whether to cancel the flights, not the system. Where a reversal has side effects, put a person in the decision.

How does a teammate or support person take over from the history?

A takeover goes wrong when the receiving person has to reconstruct events. The history should hand over a packet: the original instruction, the steps done, the steps pending or failed, the evidence, and what has already been tried.

Vendors show the range. Microsoft Copilot Studio can share the full conversation history and relevant variables on handoff, plus an optional private message to the live agent. Salesforce describes the default escalation of its voice agent as firing immediately, with no chance to collect data first. Its dynamic escalation lets a team require pre-work, such as a case record or the caller’s email, before the human gets the call.

GitHub adds two details. Cloud agent sessions are shared by default with anyone who has access to the repository, so a teammate can open the same log. Stopping a session preserves commits already pushed, which means stopping the agent does not undo anything. Your history should say so next to the stop button.

Our suggestion: a “Take over” action that opens the history at the first failed or unknown step. Show who owns the run now, and check the receiver’s permissions before showing sensitive fields. Let them reverse only what their role allows, and record the takeover as an entry.

How long should the history and the undo window last?

They are two clocks, and users confuse them. Claude Code deletes a session’s file snapshots about 30 days after the last save by default, and warns that rewinding to a checkpoint whose snapshots are gone can fail. GitHub says cloud agent sessions can be archived but not deleted. Pick a retention period for the record and a separate undo window for each action type, then print both.

When a window has closed, say so: “Undo expired November 1. Contact support to request a manual fix.” A missing button looks like a bug. If your system falls under the EU AI Act’s high-risk category, Article 12 requires that it technically allow automatic recording of events over its lifetime. This is not legal advice; counsel decides whether it applies.

Illustrative worked example: the morning review

Everything here is invented. Tidewell is a fictional sales assistant. Its agent ran from 1:00 to 3:12 a.m. for an account team led by Joss Pellwick. Mara Oxenholm, head of sales operations, reviews the run at 8:05. Ines Darrowby leads support.

The summary reads: “Run 218. 52 actions for Joss Pellwick’s team. 36 can be restored, 2 can be offset, 14 cannot be undone. 3 need review.” The three sit above the list.

First, step 17 merged two duplicate contacts. The history shows both originals and the fields kept. Mara Oxenholm selects Split. The step fails: the kept contact has an open support ticket. The history logs the failed split as its own entry and offers “Hand to support.” Ines Darrowby receives the packet with the run ID, the step, both originals, and the error, and fixes the contact by hand.

Second, step 29 set a deal to Closed lost at 2:41. The restore panel shows that Joss Pellwick moved the deal back to Negotiation at 7:55, so there is nothing to restore and nothing to overwrite.

Third, step 41 emailed a contact whose address came from a stale import. The entry shows the recipient, the text, and the source field. It carries the label “Cannot be undone.” The offered action is “Draft a correction,” which still waits for a person to approve it.

Mara Oxenholm finishes the review by 8:20, with one item left in support’s queue.

Where do these defaults stop working?

The sources are product documentation, a design pattern, a standard, and a regulation. They show what products do, not what makes users trust a history, and no study of agent activity feeds was found for this guide. Several products named here are developer tools, where Git is a second safety net that business apps often lack. OpenAI’s ChatGPT agent help article could not be opened, so that product is not covered, and Salesforce’s page describes voice agents. Regulated settings, legal hold, and data residency need their own review.

What can you produce now?

Five things, before anyone draws a screen:

1. A step schema with the 10 fields above, filled in for your three riskiest actions.
2. The reversibility worksheet, one row per action the agent can take, with real owners.
3. A rule for how the summary orders exceptions and what it never calls complete.
4. A handoff packet spec that lists what a receiver sees and which roles can reverse what.
5. A retention statement with the undo window and the record period for each action type.

With those, you can test the morning review above on a real run. For the moment before the action, including proposals, approval, and the difference between cancel and undo, read our guide to approval, undo and human handoff for AI agents. If admins also need a compliance record of human activity, our guide to the customer-facing audit log covers it.