An agent changes twelve tasks. The user closes the conversation. Later, a teammate asks why three dates didn’t move.
A transcript can explain what the user wanted. A transcript can’t establish which writes reached their destination. The product needs a record that survives the conversation and lets someone work out what happened without trusting the agent’s summary.
Start with the question a second person will ask
A second person needs to connect the result to the approved list and the actual objects. Which twelve tasks? Which versions? Who approved them? Were the exceptions untouched, or just unverified? Access to the run shouldn’t automatically expose every source conversation or private destination.
A useful history view answers those questions before offering another action. Otherwise a Retry button asks the person to decide with the same uncertainty that caused the problem.
A receipt is not another assistant message
I would separate three records. The conversation keeps the request and the clarifications. The run record connects proposals, authority, attempts, outcomes, and recovery. Object history shows the changes to one task or document and links back to the run responsible.
The three views can share IDs without showing everyone the same content. A teammate investigating one date shouldn’t have to read an unrelated private discussion.
A receipt should come from the system that attempted or checked the operation. The receipt keeps the operation ID, the target, the approved version, the before and after versions, the outcome, and a pointer to the evidence. A plain-language explanation can summarize the receipt. The explanation must not quietly replace the receipt.
“Attempted,” “accepted by the service,” and “verified in the destination” may be different states. A receipt should name the evidence the receipt actually has. An HTTP acknowledgment, a lookup of the operation’s result, and a later read of the changed field support different conclusions.
Follow the failure past the pleasant summary
Consider two people on the same job. Mara approves a fixed set of date changes. A worker updates two tasks, then updates a third but loses the reply. Luis opens the project on another device and sees only two confirmed changes. Luis asks the agent to finish the remaining work. Meanwhile, Mara cancels the original job.
When the system treats “not confirmed” as “not done,” Luis’s request can make a change twice. When the system treats cancellation as rollback, Mara can believe the first changes disappeared. When the two views use different operation IDs, support may see two legitimate-looking jobs instead of one unresolved operation and a follow-up request.
The history should keep that uncertainty. A new attempt belongs under the original operation when the attempt is a retry. When a person instead authorizes a different operation, record the difference and link the two. Never write a success entry just to make the timeline look finished.
Cancellation needs its own acknowledgment
“Cancel requested” means someone expressed intent. “Dispatch stopped” means no more work will be sent. “In-flight work settled” means outstanding effects have landed or been withdrawn. None of the three means earlier changes were reversed.
Keep those distinctions visible, even in simpler words. A job can say “Stopped sending work; one result still being checked.” That ending is more useful than a green Cancelled label next to an unexplained changed object.
Recovery creates new history
A reversal is another operation with its own authority and result. Link the recovery receipt to the original execution. Don’t erase the original event or rewrite history as though the change never happened.
Recovery should restore only eligible writes, checking the written version as well as the value. The hard case from Be honest about what undo can undo moves a date away from Friday and back again: the value matches, but a newer version shows someone worked on the record in between. A recovery that checks only the date misses the teammate’s work.
The person should see why an object was left out of recovery and what’s still possible: inspect the newer edit, prepare a revised change, or leave the record alone. Retrying the same recovery shouldn’t quietly treat old conflicts as new permission. A retry like that turns into a bigger operation than anyone approved.
Effects outside the product need their own words. Correcting a published message differs from recalling the message; restoring a document differs from deleting copies already shared. The receipt should describe the effect actually reversed, not promise a universal undo.
Keep the trail when details are hidden
A run across several projects can contain material some viewers mustn’t see. Controlling access to the changed object alone isn’t enough when the linked run exposes private source excerpts or approval details.
Separate the minimal operational evidence from the sensitive content. An event can keep an opaque object reference and an outcome while the content follows its own access and retention rules. A restricted viewer may see that a source is withheld without seeing the source’s title. And “content removed under retention policy” is different from “nothing was recorded”: don’t pretend a redacted history is complete.
Don’t solve the problem by storing the model’s hidden reasoning, either. The product needs the decision the person saw, the authority actually used, the operation’s inputs, and the verified results. The model’s internal deliberation is neither necessary nor a substitute for evidence.
Test history without the original conversation
Give a second reviewer a run reference after the original user closes the chat. Ask the reviewer to identify the approved targets, confirmed effects, unresolved attempts, cancellation state, and available recovery. Have the reviewer open one changed object and return to the object’s receipt. Repeat with a restricted viewer and with a hidden source.
Measure wrong conclusions as well as time to answer. A fast reviewer who assumes every attempted write succeeded is evidence of a misleading interface. A record that needs an engineer to reconstruct worker logs isn’t yet useful product history.
History is doing its job when the record supports a decision: continue, reconcile, recover, or leave the newer work alone. The value isn’t remembering everything the agent said. The value is keeping what another person needs to understand the work and change the work responsibly.