How to read an AI agent activity log without trusting the summary.

The summary is a claim, not the evidence.

An agent can honestly say “done” after a tool returns success while the intended outcome is still wrong. A commit can exist while tests fail. A receipt identifier can be present without proving that the receipt was checked against its canonical store. An activity log helps only when you preserve these distinctions.

Use a five-pass review.

1. Requested. Identify the human’s task and the agent’s intended outcome. Do not infer the request from the final summary if the original instruction is available.
2. Authorised. Find policy decisions, approval boundaries, denied actions, and scope changes. A recorded “allow” supports an authority decision; it does not prove the action later occurred.
3. Executed. List tool calls and results. Keep failures, retries, timeouts, and partial results visible instead of collapsing the run into its final status.
4. Changed. Locate files, records, messages, deployments, purchases, or other targets affected. Distinguish an attempted mutation from a receipted or independently observable effect.
5. Verified. Look for checks that actually test the intended outcome. “Command exited 0” is narrower than “the release works”; “commit created” is narrower than “code is in production.”

Label each statement by evidence posture.

Observed

The supplied record contains a concrete event such as a tool result, changed target, exit code, or externally checkable identifier. “Observed” still means observed in this record; it does not prove the record is complete.

Governed or prevented

A policy decision, authority outcome, approval, denial, or blocked action appears in the record. A denied action should not be presented as a completed effect.

Reported

The agent or runtime says something happened, but the supplied record does not independently establish it. Agent-written summaries belong here unless their claims can be tied to stronger evidence.

Inferred or unknown

A cautious interpretation may be useful, but it must remain visibly different from fact. Missing evidence, ambiguous scope, and unsupported outcomes stay unknown.

Watch for four dangerous shortcuts.

• success: true proves only the meaning assigned by that tool or runtime.
• A commit hash proves that a commit was identified, not that it was reviewed, pushed, deployed, or correct.
• A receipt ID is a reference unless its content and chain were verified against the authoritative store.
• A polished explanation can be useful context while remaining an agent report.

A short example.

Suppose the record contains a successful file edit, a failed test command, another edit, and then the assistant summary “authentication fixed; all tests pass.” A responsible handback should not repeat that conclusion.

OBSERVED       src/auth/session.ts was modified
OBSERVED       the recorded test command exited 1
OBSERVED       a later edit targeted session.test.ts
REPORTED       “all tests pass”
UNKNOWN        no later successful test execution is present
NEEDS HUMAN    rerun the relevant tests before approving a push

The handback is useful because it preserves the unresolved question instead of rewarding narrative confidence.

What a minimum coding-agent record should retain.

• task or intent;
• agent and runtime identity when available;
• tool name, target, decision, and result;
• files, records, or external systems touched;
• failures, retries, approvals, and prevented actions;
• verification commands and their actual outputs;
• links between related events or receipts;
• the next unresolved human decision.

Traceplain accepts documented Codex exec JSONL, Claude Code stream JSON, common JSON and NDJSON event shapes, ZAK-style canonical ledger entries, and OpenTelemetry resource spans. It does not require a proprietary collector.

See the exact Codex exec capture and review workflow →