What should every AI coding agent run record include?

[Keesan12]

We’re designing MartinLoop around the idea that every AI coding agent run should leave a receipt.

Current fields we’re thinking about:

• task objective
• model / adapter
• budget policy
• commands run
• files changed
• verifier result
• failure class
• halt reason
• rollback evidence
• recommended next action

What else should be included before a team can trust an agent run in a real repo?

[armorer-labs]

The list is a good start. The fields I would add are the ones that make the record useful after the run is no longer fresh in anyone's head.

I would include:

• actor identity: human requester, agent identity, runtime/session id, and whether the agent was acting autonomously or under a live operator;
• authority record: what policy, approval, schedule, or delegated scope allowed this run to start;
• input provenance: prompt/source refs, relevant retrieved context ids, and any files or tickets the agent treated as instructions;
• tool boundary events: not just commands, but every externally consequential tool call with normalized args, result class, and redaction policy;
• decision log: places where the agent chose between plans, escalated, asked the user, retried, or abandoned a path;
• evidence refs: links or hashes for logs, test output, screenshots, diffs, deployments, and health checks instead of only a pass/fail verifier result;
• review state: whether the result was unreviewed, self-checked, human-reviewed, reverted, or superseded by a later run;
• reproducibility envelope: repo sha, dirty-worktree summary, dependency lockfile ids, environment/provider versions, and budget actually spent;
• privacy/redaction manifest: which fields were omitted or transformed before sharing the receipt.

The important split is claim versus evidence. A run record should say "the agent claims these files changed and these checks passed," then point to enough durable evidence for another system or reviewer to validate that claim later. If the receipt collapses those into one summary blob, it becomes hard to audit or compare runs.

For a real repo, I would also make failure boring and explicit: timeout, budget stop, missing credential, permission denied, verifier failed, user rejected, unsafe action blocked, and runtime crash should be separate halt reasons. Those distinctions matter when teams are deciding whether to retry, roll back, or trust the next run.

Disclosure: I work on Armorer Labs.