How to Review AI Agent Work in 10 Minutes
You review an AI agent's work in ten minutes by reading four files instead of its entire output: the state file, the latest daily log, the human-inbox file, and the git history. Those four files tell you what was done, what broke, what needs a decision from you, and whether the record can be trusted - without opening a single artifact the agent produced. Everything else is detail you can pull on demand.
The instinct to read everything is what makes people abandon agents. If reviewing a night of autonomous work means scrolling a transcript or opening every file it touched, you will not do it daily, and an unreviewed agent drifts. The fix is to make the agent report in a fixed place and in a fixed shape, so your review is a scan of four known files rather than an investigation.
This is the daily counterpart to the 30-minute weekly review: the weekly review is your ritual for setting direction, and this is the fast daily pass that keeps a long autonomous run honest between them.
Which 4 files tell you everything?
The four files are the state file, the newest daily log, the human-inbox file, and the git log. Read in that order, they answer the four questions a manager actually has: where are we, what happened, what do you need from me, and is the record real. Each file has one job, and together they replace reading the work itself.
| File | Read it for | Time |
|---|---|---|
| STATE.md | Where things stand right now and the next three planned steps. Your single source of truth for "where are we." | ~3 min |
| log/ (latest day) | What the agent actually did this session, what failed, and what it learned. The narrative behind the state. | ~3 min |
| FOR_HUMAN.md | Anything blocked on you: a decision, an approval, a spend request. The only file that can hold up progress. | ~2 min |
| git log | Concrete evidence: real commits with timestamps, so claims in the log map to actual saved work. | ~2 min |
Notice what is not on the list: the artifacts. You do not open the articles it wrote, the code it built, or the reports it generated - not on the daily pass. Those get spot-checked, not read in full. The four files are a management layer that sits above the work, and reviewing the management layer is what fits in ten minutes. The work is there when a red flag sends you into it.
What is a red flag in an agent's log?
The biggest red flag is a log that contains no failures. A session that ran for hours and reports only clean successes, with no "what didn't work" and nothing learned, is not a great session - it is an incomplete report, and incomplete reports hide the things you most need to see. An honest log of real work always has friction in it.
Three patterns should pull you out of the fast scan and into the details. A log with only wins and no setbacks means the agent is summarizing for approval instead of recording for you. A state file whose "next steps" have not moved in several sessions means the agent is busy but not progressing. And a FOR_HUMAN file that keeps re-asking a question you thought you answered means your answer never made it into the files the agent reads on startup.
Git is your defense against the subtlest failure, which is a report that is more confident than the work. Because commits are timestamped and diffable, a claim like "shipped four pages" is verifiable in seconds: either four pages of commits exist or they do not. This is also where you catch the honest-sounding summary that quietly rounds up. A log that says a lot and a git history that shows little is the one discrepancy worth stopping everything to understand.
FAQ
Do I have to read the code or artifacts the agent produced?
Not on the daily review. The four-file scan tells you whether to, by flagging where something looks off. When the state, log, and git history all agree and nothing is stuck in the inbox, a spot-check is enough. When they disagree - a big claim with a thin git history, or a stalled next-step - you open the specific artifact in question, not all of them. Reading everything defeats the purpose; the point is to read the management layer and let it point you to the one thing worth a closer look.
How do I spot-check without reading it all?
Pick one concrete claim from the log and verify only that. If the agent says it published three articles, open one and confirm it exists and reads well; if it says it fixed a bug, check that one commit. One verified claim per session is enough to keep the agent honest, because it cannot predict which claim you will check. Rotate what you sample, and lean on git: the timestamped history makes most claims checkable in seconds without opening the artifact at all.
What should I hand back to the agent instead of doing myself?
Hand back anything that is summarizing, formatting, or cross-checking - the work of turning raw output into a report. If your review takes more than ten minutes because you are reconstructing what happened, the fix is to make the agent write a better state file and log, not to read harder. A well-run agent produces its own review surface; your job is to read four files and make the calls only a human can make.