Capture the agent's consequential decisions

Token-by-token logs are expensive to retain and still do not identify the source, policy result or tool event that authorised an action. Capture explicit decision artefacts at the points where the workflow branches or authority changes.

Useful events include a plan accepted for execution, a tool selected, a policy check, a proposal created, an approval requested, an action attempted and a task outcome. Each event should include the relevant structured payload or a reference to it, not a model-authored story about what happened.

For a tool selection, record the tool name and version, validated arguments after secret removal, requesting run, policy result and reason code. If the gateway alters or fills an argument, retain both the requested and executed forms. A model may ask for one date range while policy narrows it to another.

For model calls, record the provider and model identifier, request time, response classification, token or cost data when available, and links to the context artefacts. Full chain-of-thought is not required for an operational audit trail. It may not be available, and generated reasoning text is not a substitute for the actual source, policy and tool events.

Where the workflow produces a rationale for a proposal, store it as model output and label it accordingly. The evidence remains the cited records and the deterministic checks that passed. A plausible rationale can be useful to a reviewer while still being wrong.

Denied actions belong in the trail. They show that enforcement worked and can reveal repeated attempts to reach the wrong tool, object or scope. Use stable denial codes such as scope_mismatch, restricted_field, approval_missing, stale_version and limit_reached so patterns can be queried.

Retries should link to the original call and state why another attempt was allowed. Otherwise several nearly identical action events can look like duplicate writes or hide that the first outcome was uncertain.