I would put the unresolved credit at the top, before the investigation story: “$40 credit submitted under operation 8F2, provider outcome unknown. Do not submit another credit until reconciled.” The exact ID is illustrative. This is the fact that changes what the human may safely do. A transcript hides it in forty minutes of chat. A summary may say “applied” because the model predicted success. Neither one is a reliable operational handoff by itself.

The handoff is a current view of durable state, with a short narrative attached. It should include the customer's goal, authenticated account and scope, current ticket owner, work already verified, relevant evidence with source revision, decisions and approvals, pending or failed operations with stable IDs, next safe action, and the reason a human is needed. Mark each material claim as verified, inferred, disputed, or unknown. In this case, a card can show the charge ID and amount, the policy paragraph that might permit a credit, the approved credit amount if any, the outbound provider request reference, and the missing receipt. It should not reproduce private documents that this human is no longer permitted to see. The UI checks the new operator's current access before fetching source details.

The account service owns the charge, the workflow ledger owns operation state, the provider owns its receipt, and the source system owns the policy revision. The model can produce a useful explanation of why it investigated a particular path, but the handoff renderer resolves those IDs from their owners. A sentence that cannot be tied back to a record is labeled as the agent's hypothesis. OpenTelemetry's log specification describes how trace and log context can be correlated. Correlation helps the operator find the events. It does not make a model's conclusion authoritative.

Taking ownership is an operation too. The human claims the ticket at a version or lease boundary. The agent stops proposing new effects, while already submitted operations remain in reconciliation. If the agent is still reading or drafting, those tasks can be cancelled. If an external credit request has gone out, cancellation does not erase it. The new owner sees updates from the same operation ledger rather than opening a second independent workflow. A handoff acknowledgement records who took over and what state they saw. The customer gets a truthful status, not a second “your credit is done” message based on the old summary.

Now the provider receipt arrives after the human opened the case and says the credit succeeded. The view updates from unknown to confirmed, retaining the original request and receipt link. If the human has not acted yet, their next step changes from “reconcile” to “verify amount and tell the customer.” If the human already submitted a second credit, that is an incident to resolve, not something the UI should hide. Prevent this by giving the human a broker action that operates on the same credit identity and refuses a new credit while the old result is unknown. A stale browser tab must not be enough to override that gate.

Suppose the receipt instead says the credit was for the wrong account, while the agent's summary confidently names the right one. Show the discrepancy, quarantine any further automated effect, and trace the submitted arguments and authorization decision. A summary can help the operator read the case, but a confirmed receipt wins on what the provider did. The human may need to correct the customer and initiate a separate remedy. Never silently edit the earlier transcript to look as if the agent told the truth.

I would measure time to safe next action, duplicate effects after handoff, number of unresolved operations left without an owner, and how often operators must open the raw trace to understand a decision. Sample handoffs where the summary disagrees with structured state. If a handoff is short because it drops uncertainty, it is not efficient. It just moves investigation work and risk to the person who takes over.