Audit trail

Everything the fleet does lands in the audit trail: which agent proposed what, when, who approved it, and what executed. The trail is the record that makes delegation to agents accountable rather than hopeful.

What is recorded

For every consequential action, the trail holds the full arc:

• The proposal. The question as asked, the context that accompanied it, the ask type and time estimate, and the agent that filed it.
• The decision. What you answered, when, and which option you chose if options were offered. Expired and declined proposals are recorded too: a no is part of the history.
• The execution. What actually ran after approval, when it ran, and its outcome.

Autonomous actions, the ones an agent has graduated to through the autonomy ladder, appear in the same trail with the same attribution. Autonomy changes who authorizes an action; it never changes whether the action is recorded.

Attribution

Every entry traces to exactly one agent and, for gated actions, exactly one approval. There is no anonymous fleet activity. When you look at a sent email, a filed invoice, or an updated CRM record, you can answer three questions from the trail alone: which agent did this, on what authority, and when.

What the trail is for

In practice the trail serves three purposes. It lets you audit: reconstruct any past action without relying on an agent's memory or your own. It lets you correct: when an outcome was wrong, the trail shows whether the proposal was misframed, the approval was misjudged, or the execution drifted, which tells you what to fix. And it feeds the autonomy ladder: an agent's record of clean, well-attributed runs is the evidence on which wider autonomy is granted or revoked.

The trail is not an optional log level. It is part of the execution path, written as actions happen.

Continue with the FAQ, or revisit The approval queue for the contract that feeds the trail.