How to verify what an AI agent actually did

Search for this topic and most of what comes back is about something else. One half is cloud-agent identity: cryptographic agent IDs, delegation receipts, policy engines that allow or deny an action at an API boundary before it reaches a system. The other half is pre-production evaluation: trajectory evaluators, test suites, scoring an agent on a benchmark before you ship it. Both are real disciplines. Neither is the problem you have at 6pm on a Tuesday.

Your problem is smaller and more concrete. An agent already ran, on your own laptop, in your own logged-in session. There was no policy engine in front of it and no benchmark involved. It did things, and now it has handed you a paragraph: "I updated the config, migrated the schema, and the tests pass." The paragraph reads as a report. It is not one. It is generated text. The model wrote "the tests pass" because that is the plausible continuation of the conversation, not because it re-ran the tests and read the exit code a second time.

When the summary and reality diverge, you get what people have started calling a ghost action: the agent sounded confident, but the write never landed, the migration silently no-op'd, the click hit the wrong element. The whole job of verification is catching ghost actions. And you cannot catch them by reading the summary, because the summary is exactly where the ghost lives. You catch them by reading the record of what the agent actually did, call by call.

A raw terminal gives you a record, technically. Every tool call scrolls past as text. But it is one undifferentiated stream: intent, output, model chatter, and progress spinners all blur together, and pairing "the agent asked to edit this file" with "here is what the edit returned" means scanning by eye. That is a record you can read in principle and will not read in practice.

Fazm wraps the same Claude Code agent loop through ACP, but it splits each tool call into two events that share one identity. The translation lives in acp-bridge/src/acp-translate.ts, lines 63 to 118. When the agent invokes a tool, the bridge emits a tool_use event carrying the call id, the tool name, and the raw input arguments the agent chose. When the result comes back, the bridge emits a tool_result_display event carrying the same id, the name, and the actual output (truncated at 2000 characters so a giant blob cannot bury the rest). One action, two records, joined by toolUseId: the intent and the outcome.

A good record is not enough if it does not survive to the moment you read it. Two ordinary features of agent clients quietly shred it.

The first is auto-compacting. When a long session nears the context limit, many clients compact: they replace a stretch of real messages, tool calls and their results included, with a model-written summary, then keep going. The session continues fine. But the actual tool_result for an edit you care about, 40 turns back, no longer exists in the window. It was summarized into a sentence. You now cannot verify that action against anything, because the evidence was compressed into the same kind of generated text you were trying not to trust. Fazm does not auto-compact. The full history, every paired event, stays live in the window for its entire lifetime, so a three-hour session still has a complete record at the end.

The second is the scrolling terminal. Even when the bytes are technically all there, a flat stream is not a readable record. If you run Claude Code in a bare terminal it does keep a session transcript on disk as JSONL under ~/.claude/projects/, which is a genuine, complete record. But verifying from it means reading raw JSON line by line, or writing a script to do it. Structured cards in a window are the same information arranged so a human can actually scan it: collapse the calls that obviously succeeded, stop on the one that looks wrong, read its input and its output side by side.

Even a perfect, uncompacted, perfectly paired record has a ceiling. It tells you what the agent asked for and what each tool returned. It does not tell you the end state is correct. A tool_result_display that says "file written" is the tool reporting its own success. It is not proof the file holds what you wanted, or that the agent did not also touch four other files you never mentioned.

So the last move of verification always leaves the record and looks at reality. For code that means git diff HEAD to see every file actually touched, then opening the ones the agent claims it changed. For a browser or desktop action it means looking at the live UI. This is where Fazm's approach to computer use matters for verification specifically: its desktop and browser tools read state through the macOS accessibility tree, not screenshots. When the agent reports "clicked Submit and the form saved," you can check that against the real control and field state, instead of against a picture the agent took of itself and then described. A screenshot the agent narrates is just another summary.

Verify-after is the right default for everyday work on your own machine, where almost everything is reversible: a bad edit is a git checkout away, a bad file is in the Trash. It is not the right model when an action is irreversible or hits something you do not own.

Deleting production data, sending email to real recipients, moving money, force-pushing to a shared branch, running anything with credentials that reach beyond your laptop: for those, reading the record afterward is too late, because there is no afterward you can undo. The honest position is that verification has two regimes. For reversible local work, verify-after with a strong record wins, and a per-call prompt is mostly theater. For irreversible or outward-facing actions, you want a real gate, and ideally you want the agent to not have those credentials in scope at all.

Verifying is also only half of staying in control. The other half is being able to stop a run that has clearly gone wrong before it finishes. That is a separate mechanism, the interrupt path and the stuck-tool watchdog, covered in the companion guide on the containment-action gap on the desktop.