Agent Logs API.
Connect intent, tool execution, and outcome.

Make the execution structure visible

An agent run can include model calls, several tools, parallel branches, and waiting periods. Give the run a stable identity and preserve the relationship between its logical steps. A tool call should have a distinct identifier, while each execution attempt should show whether it is an initial attempt, a retry, or later reconciliation work.

Use stable names for operations and safe resource references. Keep customer text and full arguments out of span names. Record which observable decision selected a branch or ended a step, using bounded reason codes and relevant configuration versions where they explain the application’s behavior.

Capture the boundaries around a tool

Describe argument validation, authorization, execution, and result validation separately when their outcomes can differ. A requested action does not establish that it was permitted, and a successful transport response does not establish that the requested change occurred. Preserve the evidence the application used to make that determination.

For human review, connect the decision to the exact action version that was reviewed. Record declines and expiration as meaningful outcomes. After an uncertain remote result, use a reconciliation operation to establish what happened before treating a repeated change as safe.

End with a verified application outcome

Define terminal states for completed, partial, declined, cancelled, and unresolved runs. Record outstanding operation references when work continues or its outcome remains unknown. Parallel steps can overlap, so keep total run duration separate from the sum of individual operation durations.

Read the complete agent tool-tracing guide for retries, queues, permissions, and final run records. The suggested fields below help reconstruct a run; adapt them to the application’s actual execution and approval boundaries rather than treating them as a framework-independent specification.