When an agent says it updated a customer record, an operator needs a way to establish what actually happened. A conversation transcript may show the intention, but a useful action record should also connect the request to its outcome.

Anthropic’s guidance on designing effective tools for agents emphasizes clear tool boundaries and meaningful responses. For an operational system, those responses should also support investigation when a workflow fails.

Record the operation, not just the conversation

Our proposed starting record includes a task identifier, tool name, timestamp, acting identity, target reference, result status and a link to the system’s confirmation. Where approval is required, include the approval reference and the scope that was authorized.

The purpose is to answer a few concrete questions: which task caused this change, what operation ran, was it permitted, and what evidence establishes success?

A human-readable summary can help, but it should not replace identifiers that let an operator locate the actual record.

Distinguish success from uncertainty

Imagine a tool submits an update and the network connection closes before it receives the response. Reporting a simple failure could encourage a duplicate action. Reporting success would claim more than the caller knows.

For this illustrative case, record an uncertain outcome and reconcile it against the target system before retrying. Where the service supports an idempotency mechanism, use it to recognize repeated attempts at the same operation. The exact recovery method depends on the service.

Use a compact event structure

  • Task: The business request that started the work.
  • Actor: The account or service identity used.
  • Operation: The specific tool and target.
  • Authority: The relevant authorization or approval reference.
  • Outcome: Confirmed, rejected, pending or uncertain.
  • Recovery: The next owner or reconciliation action.

This structure is a design proposal, not a mandatory industry schema. Adapt it to the systems and audit requirements involved.

Avoid creating another sensitive-data store

Logging an entire prompt, access token and customer record may make an investigation easier while creating a separate exposure. Prefer references and carefully selected fields. Redact credentials, control access and define retention for the logs themselves.

A useful record should let the authorized investigator reach the evidence without giving every dashboard viewer the underlying customer data.

Test the investigation experience

Before rollout, give an operator a failed task and ask them to determine whether an external change happened. If the answer requires guessing from the agent’s wording, the record needs improvement.

The goal is not to collect the longest transcript. It is to make the next operational decision clear: accept the result, retry safely, reverse a change where possible or escalate to a person.