The Auditor's Job Is to Find Problems
The executor's job is simply to do the work — we covered that in the previous chapter.
The executor focuses on the task. And the executor does not approve their own work.
So what does the auditor actually do — the role responsible for that approval check? This chapter looks at what that role involves.
What the Auditor Does
An audit is the act of reviewing a piece of work or output through the eyes of a third party, checking whether problems exist.
Where the executor handles "write and build," the auditor handles "examine and question."
The key point is that the auditor has no authority to produce anything. Rewriting an article or modifying data is the executor's work. The auditor's role ends at finding a problem and reporting it to the executor or the approver (the role responsible for final sign-off).
Why design it this way? Because when authority overlaps, the precision of the check drops. When you are in a position to fix something, you unconsciously start looking at it through the lens of "a fix will handle this." The drive to find problems and the drive to solve problems interfere with each other when they operate inside the same agent at the same time. So we keep them separate.
Three Things the Auditor Does
In practice, the auditor's work breaks down into roughly three actions.
First: checking against the original policy.
The auditor asks whether the output has drifted away from the rules and direction set at the start. During execution, the executor makes one judgment call after another. Those accumulated calls can cause a slow drift from the original policy. The auditor places the finished output side by side with the starting policy and checks for gaps.
Second: finding gaps and contradictions.
Does the first half of the article contradict the second half? Is a necessary explanation missing? Has a prohibited expression or piece of information slipped in? The auditor examines these details from a perspective different from the executor's.
The executor writes while following the overall flow of the piece. The auditor has no need to follow the flow — they can focus on individual questions one at a time. This difference in stance is the mechanism that catches what would otherwise be missed.
Third: recording the problems found.
Rather than quietly suppressing a finding with "this is probably fine," the auditor records it. Even minor issues are included in the output, leaving the approver in a position to make the final call. When the auditor independently judges that a problem is small and keeps it hidden, the trail goes cold — there is no way to ask later "why did this get through?" The act of recording is itself part of completing the audit role.
Finding Problems Is What Success Looks Like
There is one point worth keeping in mind here.
When an auditor returns a report saying "no issues found, all clear" — it is worth not taking that entirely at face value.
Sometimes there genuinely are no problems. But when a perfectly clean report comes back every single time, it is worth pausing to think.
Were there truly no problems? Or did the auditor fail to find them? Or did the auditor find something but decide "it is not worth writing down" and leave it out?
The auditor is a detection mechanism. Problems surfacing in the output is a sign that the mechanism is working. Conversely, when nothing surfaces, we consider the possibility that the mechanism has stopped functioning.
We arrived at this understanding through actual operation. Early on, a string of "no issues" reports read as "things are going well." Then at a certain point, a "no issues" report came back on output that clearly had problems. That told us the detection criteria had been set too loosely.
The experience is why an unbroken string of approvals now reads as a warning signal rather than a reassurance.
Why the Auditor Is Kept Separate from the Executor
We assign the auditor role to a different AI from the executor.
In this series, we do not have a single AI handle both execution and audit. If we ask the same AI to "write and then check its own writing," the judgment framework it used while writing carries over into the check. The reverse distortion also tends to emerge: writing in a way that will pass the check.
When the executor is operating in a mode optimized for getting work done, that same mode does not serve problem detection. Finding problems requires a stance of deliberate skepticism — which does not fit well with the "keep moving" stance of active work. The point raised in the previous chapter — that the executor cannot audit themselves — is not a question of capability. It is a question of stance.
Keeping the roles separate allows each agent to focus on its own function.
Why we often use a different vendor's AI, and what class of problems that prevents, will be covered in a separate chapter. Here we simply confirm the principle: keep them separate, not combined.
Summary
The auditor's job is to find problems. That function is made up of three actions: checking against the original policy, finding gaps and contradictions, and recording what is found.
Problems surfacing in the output is a sign that the audit is functioning. When a perfectly clean report comes back every time, that is when we question the detection criteria. The reason for keeping the auditor separate from the executor is the same question of stance. The drive to surface problems does not work well inside the same agent that is driving the work forward. So we keep them separate.