Lessons 31.1 through 31.3 gave the agent a path, a surface, and a permission boundary. This lesson answers the question you will ask at 11 p.m. when something looks wrong: *what exactly did the agent do, with what, and when?*

An agent that cannot answer that is not operable. It may be clever, but you cannot trust it, fix it, or hand its work to anyone else. Evidence is what turns a clever run into a maintainable system.

The minimal audit trail

Every tool call should record seven fields. Memorize them:

• Inputs: exactly what was sent — parameters, query, filters, document IDs. Not "researched the company" but ticker=AAPL, period=2026-Q2, fields=revenue,eps.
• Timestamp: when the call ran (started_at, finished_at) and the source's own time (reported_at or period_ending). Lesson 31.1's freshness rule lives here.
• Result: what came back — raw response or a pointer to it, plus the parsed values the agent actually used.
• Source: which tool, endpoint, or document the result came from, including version or credential scope when relevant.
• Changed record: what the run created or modified — file path, database row, ticket ID, draft location. "No change" is a valid entry.
• Error: what failed, with the provider's error code and the agent's handling (retried, skipped, escalated). Silence about errors is itself a failure.
• Owner: the human responsible for this agent and this run. Logs without an owner are orphans nobody reads.

If any one field is missing, debugging becomes guessing. Missing inputs: you cannot reproduce. Missing timestamp: you cannot judge freshness. Missing error: you cannot tell a clean stop from a silent failure. Missing owner: you cannot escalate.

Where evidence lives

Evidence should live in places you already know from earlier parts of the course:

• Logs: the append-only narrative — each tool call, decision, and gate outcome in order. Structured (JSON lines) beats prose for searching. Connects to Class 26's worker logs.
• Database state: the operational facts — run ID, status, retrieved values, ticket or record IDs. Queryable, unlike a chat transcript.
• Git commits and PRs: proposed changes as reviewable diffs. An agent that writes code, content, or config should propose through a branch and PR, never silent overwrite. The PR *is* the approval gate made visible.
• Handoff Markdown: the human-readable packet — what ran, what was found, what needs review, where the raw evidence sits. Think RUN-2026-09-12-001.md next to the machine logs.

A healthy run touches at least two of these: machine-searchable logs plus a human-readable handoff. One without the other fails half its audience.

What good looks like

Imagine a support-triage agent run. The evidence reads:

run_id: triage-2026-09-12-041
owner: D. Oliver
input: message_id=8841, inbox=support@, received_at=09:14 UTC
tool calls:
  1. classify → intent=billing, urgency=high, confidence=0.81 (model vX, 09:14:22Z)
  2. crm_lookup → account_id=5521, plan=pro, open_ticket=none (api, 09:14:25Z)
  3. kb_search → article=billing-refunds-03, score=0.77 (index 2026-09-10)
changed: ticket T-2091 created (status=pending_review), draft reply saved to ticket
error: none
gate: outbound send REQUIRES human approval — queued, not sent

In thirty seconds a reviewer knows: what arrived, what the agent decided, which account and article grounded the draft, what changed, and what still needs a human. Contrast that with "the agent handled the inbox this morning" — a sentence with zero debuggability.

Handoffs between runs matter too. When a run ends — approved, queued, or failed — its record must let the *next* run or the next human resume without re-running blindly: run ID, completed steps, pending review items, output locations. State, from Class 28, is evidence extended across time.

That is also why errors deserve the same care as successes. Record the provider's message verbatim, the retry count, and the decision that followed: retried once then escalated, skipped the enrichment step and marked the record partial, stopped the loop and paged the owner. A future debugger should be able to tell whether the agent behaved sensibly under failure without re-running the failure. And when the agent proposes through Git — a content draft, a config change, a code fix — the pull request becomes the most readable evidence of all: a diff the approver can read, a test log attached, a merge that records who approved and when. Logs tell you what happened; the PR tells you what was allowed to happen.

Check your understanding

1. Name the seven fields of a minimal tool-call audit trail. 2. Why are both fetched_at and reported_at needed? 3. What is the difference between logs, database state, Git PRs, and handoff Markdown as evidence? 4. Why is "no change" a meaningful entry rather than an omission?

Exercise: design an agent-run record

Create RUN-RECORD.md — a reusable template plus one filled example for an agent you care about.

# RUN-RECORD.md — [agent name]

## Template (copy per run)
- run_id:
- owner:
- trigger (what started this run + event/time):
- inputs (exact parameters):
- tool calls:
  - [time] tool/endpoint → inputs → result pointer → source/version:
- changed records (paths, row IDs, ticket IDs, or "none"):
- errors (code + handling, or "none"):
- gate outcome (approved / queued / rejected + approver):
- handoff location (log path, DB row, PR URL, Markdown file):

## Filled example
[Complete one realistic run, including one error or one queued-for-approval item.
Do not write a perfect run — practice recording the awkward case.]

## Where it lives
- Logs:
- Database:
- Git / PR:
- Handoff file:

Finish line: one RUN-RECORD.md with a blank template and one realistic filled example showing inputs, timestamps, results, sources, changes, an error or gate decision, and an owner.

Verification: give only the filled example to someone unfamiliar with the run and ask them to answer: what started it, what tools ran, what changed, what failed, and who owns it? If they cannot answer all five without asking you, add the missing field. Confirm the handoff location actually exists.

Next, Lesson 31.5 places the agent inside its real habitat — Make and n8n workflows connected by webhooks, APIs, email, and file drops — and teaches you to read every arrow before you automate it.