The agent's summary is a claim. The diff is the evidence.

An agent finishes a job and tells you what it did. The account is clear, it is written with confidence, and it is the agent's own description of its own work. Your repository holds what happened. Reading the second before you believe the first is the habit that lets you run more than one of these at a time.

It does not have to take long. Here is the order that works, in DevThrottle or out of it.

Start from the count, not the terminal

In the Director, a session card can carry an amber badge such as 4 chg: the uncommitted changes in that session's working tree. Treat it as a rough size rather than an inventory, because a file that was staged and then edited again counts in both halves of its life. Two more things to know about it:

• It belongs to the folder, not the session. Every session in the same checkout wears the same number, whoever made the changes.
• No badge is not proof of nothing. The badge never reads 0 chg. It is absent when the tree is clean and equally absent when the count is unknown.

Hold the story, then compare it to the list

Read the last thing the agent printed: which files, and why. Two or three items is all you need in your head. That story is the claim you are about to check.

Now open the Source Control tab next to Terminal. Its Changes page names your branch and lists the changed files, each with a letter: M modified, A added, D deleted, U for a new file git is not tracking yet. Compare that list against the story. A file the agent never mentioned is not an alarm. It is simply the first one you open.

Then read the lines

The session's tab tells you what changed. Line by line lives on the repository screen: open Repositories at the bottom of the left rail, pick the repository, and click a file on its Changes tab. The pane shows old and new line numbers, with additions on green and removals on red.

Read it unevenly, on purpose. Slow down in the files that matter and wherever the change is bigger or stranger than the job called for. Skim the rest. If the diff is doing something the story never mentioned, you have found what this whole exercise is for.

Keep it, or send it back

• Keep it. Tell the agent "commit this", or stage each file you accept and use Commit staged.
• Send it back. Most changes you dislike are not wrong, only wrong so far. Say what is wrong with it and let the agent go round again. That is the cheapest fix there is.
• Throw it away. Discard changes asks first, and the button that commits to it reads Delete changes. There is no undo. It appears only on a tracked file with unstaged edits, so a wrong new file is one you delete yourself.

Review after every job, not after five

Each new job lands in the same tree as the last one, and three jobs later the difference is one tangle nobody can read. An amber count that climbs instead of clearing is the early warning. And when a diff surprises you, set the Cockpit's Chat tab to Normal. That shows every edit and command the agent made, in order, and nothing else, which is usually the fastest way to see where the agent left the path.

The full walk-through is on See what changed, and every badge and status letter is on Source control and history. When you would rather a second agent did the first read, see the agent that wrote the code should not be the one that says it works.