Your background agent worked while you slept, and the only thing waiting for you this morning was a status line like “Updated docs, 2m ago”. That line answers nothing. The real answer lives in three records: the run ledger, the action diff, and the outbound log. Read them in that order and a full AI agent audit takes minutes, because each record answers one question the status line can’t.
TL;DR: To find out what an AI agent did while you were away, check three records. The run ledger tells you whether each scheduled run started and finished. The action diff shows what the agent changed. The outbound log shows what left your machine. Check for missing runs first, read diffs instead of transcripts, and treat anything irreversible as the part that deserves your attention.
Why the status line is the wrong record
Last week a team going by Flamerix AI published measurements that got 584 points on Hacker News in three days: Claude Code sends each background agent’s full transcript to the model roughly every 30 seconds (the interval is server-controlled between 30 and 240 seconds), with a prompt asking the model to describe the agent’s most recent action in 3 to 5 words. The output powers the spinner text in the agents panel. According to the gist, the behavior ships on by default since version 2.1.232, and an open GitHub feature request asking for a supported off switch reports it at 22.7% of API requests and about 18% of weighted tokens in a subagent-heavy session. The gist’s own OpenTelemetry measurement landed at 16.4% of spend.
Sit with the asymmetry for a second. The industry built a pipeline that ships your entire transcript out every half minute to render five words on a screen. The record that answers “what did my agent actually touch” got no equivalent investment. Products in the agent-safety wave, like NVIDIA OpenShell, trace actions inside their runtime, which helps if you run inside it. Everyone running agents through a plain CLI on their own machine gets the spinner.
The three records that survive the night
After years of running scheduled agents ourselves, we structure every overnight audit around the same three records. Each answers a different question, and the order matters.
| Record | Question it answers | Where it lives | Red flag |
|---|---|---|---|
| Run ledger | Did each scheduled run start, and did it finish? | Scheduler history: start time, stop time, terminal state | A scheduled run with no ledger row at all |
| Action diff | What did the agent change? | git status / git diff for repo work, file snapshots otherwise | Edits outside the paths you expect |
| Outbound log | What left your machine? | Approval queue, send receipts, API call logs | Anything sent with no queued approval |
The run ledger comes first because the worst failure is silence. A run that crashed mid-way at least leaves a partial record; a cron entry that never fired leaves nothing, and nothing is easy to mistake for calm. Scheduled agents fail quietly more often than they fail loudly.
The diff beats the transcript
The action diff is where most founders waste time. The instinct after an incident is to read the transcript, and transcripts are unreadable at scale: thousands of lines of tool calls to reconstruct ten file edits. Skip it. If your agent works in git, the diff is the audit. Ten file edits review in seconds; the transcript describing those edits runs to thousands of lines. For agents outside git, the same idea applies at a smaller scale: have them list every file they touched before they finish, then read that list against the files themselves.
The outbound log matters for a different reason: it’s the only record category where a wrong action can’t be undone. That’s also the line where agent consent design gets tested in practice. An edit to a file can be reverted by morning. An email that went out at 2am cannot.
What this audit looks like on our own machine
We run nine scheduled tasks on our machine. Between Oct 25 and Oct 31 they executed 48 sessions. One of them is writing this post.
Here’s the part that keeps us honest about the ledger: 24 of those 48 sessions were flagged by our run tracker because the machine stopped reporting a clean stop before the session wrapped. The flag means the final state had to be reconstructed instead of observed live. All 24 were caught by the ledger and surfaced in the daily digest. Nobody read a transcript to find them. The founder reads a summary email; the records do the rest.
This is the loop we’d recommend to anyone: a ledger that flags anomalies for you, diffs for review, and a queue for anything that ships outward. It’s also why approval fatigue is worth taking seriously as a design signal, because a queue that pages you ten times a day gets disabled by week two, and a disabled queue produces no outbound log at all.
Which record matters most when something breaks
All three records matter, but they don’t matter equally, and the weighting follows reversibility.
Internal work is reversible. A bad file edit, a wrong config change, a mangled document: the diff shows it, and reverting it costs minutes. This is the tier where you can afford to audit lightly, weekly even.
Outbound actions are not reversible. A posted reply, a sent invoice, a deleted record on someone else’s server: the damage is done the moment it leaves. This is the tier that deserves a human gate before the fact and a receipt after it. Agent permissions decide what the agent may touch before a run starts. The audit trail shows what it did touch after the run ends. You want both, and at 7am with coffee in hand, the second one is what you actually reach for.
Set up your audit trail today
- Put the schedule itself on a ledger. Every start, every stop, every terminal state, recorded somewhere you can list by morning. Check for missing runs before checking for bad ones.
- Do file work in git, even for agents. The diff is your action log, and reviewing a diff takes seconds where reading a transcript takes an hour.
- Route outbound actions through a queue with receipts. If your agent can send email or post publicly with no record, you have no audit trail for the only actions that matter most.
- Keep the records on your machine. The transcript story shows session data flowing to the vendor regardless of what you intended. Your audit trail should not depend on a vendor’s dashboard, a vendor’s retention policy, or a vendor’s definition of “activity”.
- Read the records; the transcripts can stay unread. A morning audit is a list of runs, a set of diffs, and a queue of receipts, and it takes minutes. If your audit needs the transcript, your records are missing something.
Three records, five minutes
An agent you can’t reconstruct is an agent you can’t trust, and right now the default tooling renders five words while shipping the full story elsewhere. Flip that around on your own machine: three records, five minutes, and the question “what did it do last night” stops being a guess.
This is the loop we run our own agents in every day. CrossMind records every scheduled task run and queues your agents’ outbound actions for approval, so the morning audit is a few minutes of diffs. The output is a readable record of what ran, what changed, and what left, kept on your machine. Start at crossmind.io.