No One Audits Themselves

Picture an AI agent demo. Any of them. The agent reviews some code, finds a bug, fixes the bug, ships the fix. Sixty seconds. Everyone in the room claps.

Three weeks later, the same demo in production breaks something a customer pays for. Nobody can figure out why. The agent reviewed the code and signed off. The agent fixed the bug. The audit log says the audit passed. The audit log also says the same agent did all three steps.

That's the bug.

The agent that finds the bug doesn't fix the bug. Different agent, different session, different context.

That's the rule in the agent org that runs SpeyAI. It's the first principle in the constitution, and it's enforced at the database level, not in a policy document someone signed during onboarding. The rest of this paper is about why the rule has to exist, why most teams can't bring themselves to enforce it, and what becomes possible when it actually holds.

Mark your own homework, get an A every time

Most companies say they audit their work. They mostly don't.

A developer writes code. A reviewer looks at it. The reviewer is on the same team, has the same goals, has a deadline pressing on them, and is friends with the developer. The reviewer says "looks good." The code ships. Two weeks later the same developer finds the bug they wrote. They fix it. They don't tell anyone. The audit log shows a clean trail.

This is how every team operates, including teams that swear they're rigorous about review. The structural problem is that the reviewer and the writer are essentially the same role, just at different moments. They have the same context. They make the same assumptions. They notice the same things and miss the same things. The review isn't a check. It's a second reading by the same worldview.

Now hand that pattern to an AI agent and remove the human parts that partially compensate: the embarrassment, the reputation, the colleague who remembers the last three times you shipped something broken. What's left is a system that marks its own homework at machine speed and files the grade in a log nobody reads.

The financial world figured this out a hundred years ago. The accountant who keeps the books does not audit the books. The auditor is external. They show up with different incentives, a different process, and no skin in last quarter's numbers. The standard that governs the profession, AICPA AU-C Section 200, is explicit that the auditor's value comes from independence: the audit means something precisely because the auditor didn't write what they're checking (AICPA, AU-C Section 200).

Most software teams have never absorbed this. Most AI agent demos don't even pretend to. And the auditors watching agents are already calling the violation by its name. In ISACA's industry journal, Nirupam Samanta walks through an agent that grants access to another system after judging the request reasonable, with no formal approval anywhere in the loop, and states the finding plainly: from an audit standpoint, that violates separation of duties (Samanta, 2025). The agent did the work and blessed the work. The century-old rule and the brand-new failure mode are the same rule and the same failure mode.

An audit is something someone else does to you.

Two independent hallucinations rarely align

In the agent org, the rule is structural, and the mechanics matter, so here they are.

A reviewer role finds an issue. The reviewer publishes a finding. The finding is a row in a table. The row has a reviewer identity, a timestamp, the file the issue lives in, a description, a severity. The row sits in a queue.

A different role picks up the finding. A different agent. A different session. A different context that includes the finding but does not include the reasoning that produced the finding. The implementing role builds the fix. The fix goes through the standard review path. The original reviewer back-reviews the fix and either closes the finding or kicks it back.

Three different sessions. Three different contexts. No shared brain.

That last part is the move that matters for AI specifically. When an agent hallucinates a fact in turn one, then proceeds to turn two with that fact loaded as context, every subsequent turn builds on the hallucination. By turn fifteen the agent is confidently constructing an entire output on a foundation that was wrong the whole time. The research literature documents the tendency of large language models to compound errors when their own prior output is loaded as input to subsequent reasoning (Ji et al., 2023). Long-running agent loops are a hallucination amplifier.

Two independent agent calls, with two independent contexts, looking at the same artifact from different angles, rarely arrive at the same wrong answer. Each one might hallucinate. The hallucinations rarely line up. The disagreement is the signal. The agreement of two independent sessions is what trust looks like in this architecture.

A single agent reviewing its own work has no disagreement. It can't. It's the same brain at two different moments, and the second moment loads the first moment's conclusions as context. The audit is theater.

The lifecycle is in a table

The constitution names this as the first principle, and the principle is short. The reviewer role that publishes a finding does not author or co-author the work that closes the finding. The implementation routes through the same pipeline every other change runs through. A separate role claims it.

The enforcement isn't a guideline. It's a table.

Every finding has a status: open, in progress, fixed, back-review pending, closed. Every status change has a timestamp and a role that owns the change. The reviewer who published the finding can be the role that closes the back-review at the end. But the role that did the work in the middle has to be a different one. The check that enforces this lives in the pipeline and runs on every state transition. A finding can't move from "in progress" to "fixed" if the role that owns the work is also the role that published the finding.

Try to skip the rule and the pipeline rejects the transition. There is no override that doesn't leave a row in another table flagging the override. That table is part of what makes the whole system answerable to an outside question, which is a bigger subject than this paper. Logs Are Not Audit takes it on directly: the finding lifecycle described here is exactly the kind of queryable record that separates an audit trail from a pile of log files.

The hot-fix exception, bounded

Sometimes production is on fire. A customer can't load the thing they pay for. The bug is in code that someone, anyone, has to fix in the next thirty minutes. Insisting on the full separation in that moment is the wrong move, and a governance system that can't admit that will simply get bypassed, which is worse.

So the constitution has a bounded exception. A role with full-stop authority can declare a hot fix. The fix ships through the shortest path. The separation rule is suspended for that one change.

The exception isn't free. The same declaration that authorized the hot fix schedules a back-review within forty-eight hours. The back-review is a finding in the same table, queued automatically the moment the hot fix shipped. A different role conducts it. If the review finds the hot fix introduced new problems, those problems get their own findings and follow the normal lifecycle.

The exception exists because the rule has to bend in the rare case without breaking. The bound exists because the exception can't become the default. The forty-eight-hour clock isn't a guideline. It's a row in a scheduled-task table. The back-review fires whether anyone remembers it or not.

Most companies have hot-fix policies. Most companies have post-mortem policies. Most companies do not have a database row that automatically schedules the post-mortem and follows up on its own. The difference between "we have a policy" and "the system fires the review" is the difference between intention and architecture.

Why most teams can't help themselves

The auditor-implementer rule is brutally hard to enforce on humans, and it's worth being honest about why.

The person who wrote the code is the cheapest person to fix the bug they wrote. They already understand the context. They already know what they intended. Pulling in a different developer costs hours of context transfer and raises the odds of breaking adjacent code. Under deadline, the rule loses. The original developer fixes it. Everyone moves on. The audit log shows whatever the team agrees to write.

This is why most teams talk a good game about review but quietly let people fix their own work. The cost of enforcement is high, and the visible cost of skipping is zero, right up until it isn't.

In an agent org, the cost calculus inverts. The cost of routing a finding to a different agent is the cost of a fresh session loading the finding and doing the work. That's measured in pennies, not in hours. The cost of skipping the rule is the same as it is for humans: the audit becomes theater, the hallucinations compound, the system degrades quietly. The difference is that the structural cost of doing it right is now low enough that there is no excuse left.

That's the part I find most interesting about agents as a class of worker. Humans have legitimate reasons to occasionally break this rule. Agents don't. The pipeline enforces what humans could never quite afford to.

What this lets you trust

When a finding closes in this architecture, the closing represents three independent agent calls agreeing the issue is resolved. The reviewer who found it. The implementer who fixed it. The back-reviewer who confirmed the fix. Each one in its own session, looking at the work from its own angle.

That's a structurally different artifact than a closed ticket on a normal team. A closed ticket says "someone marked this done." A closed finding here says "three perspectives, each independent, agree the issue is no longer present." If any one of the three calls hallucinated, the other two had a strong chance of catching it.

And because the lifecycle lives in a queryable table with timestamps and role identities on every transition, the whole thing becomes measurable in ways a normal team's process never is. The closing rate on findings is a number. The back-review rejection rate is a number. The time from open to close is a number. None of these are numbers on most teams, because the audit trail isn't structured. Here they're numbers because the structure came first.

The reviewer's job gets harder, in a useful way. A reviewer that publishes findings that don't survive back-review starts to lose credibility, and the loss shows up in the data, not in a hallway reputation. Reviewers whose findings consistently close, with low rejection rates, end up as the trusted ones. The trust is earned in the table, not in the room.

The implementer's job changes too. They can't talk their way past a finding. The back-reviewer doesn't share the implementer's context, so the implementer can't lean on "I know what I meant." The work has to stand on its own, read cold, by a reader with no investment in it being right.

What this looks like forward

The separation only works because of a deeper design choice: the agents don't share a brain to begin with. Every invocation is a discrete session, and the handoff between reviewer and implementer is a file the next agent reads, not a conversation it inherits. Files, Not Memories takes that apart. If the agents shared context, the separation described in this paper would be cosmetic. They don't, by architectural design. The independence isn't aspirational. It's mechanical.

And separation protects you from bad work getting in, not from good intentions breaking the foundations. Some code shouldn't be touched by anyone, finder or fixer, no matter how clean their record is. The Code the Build Won't Let You Touch covers the frozen registry that handles that.

The takeaway: The agent that finds the bug doesn't fix the bug. Different agent, different session, different context, enforced by the database, with a bounded hot-fix exception and a back-review that fires whether anyone remembers it or not. Two independent hallucinations rarely align. The agreement of independent sessions is what trust looks like in this architecture.

References

1. SpeyAI agent org architecture. Live reference at speyai.com.

2. American Institute of Certified Public Accountants. AU-C Section 200, Overall Objectives of the Independent Auditor. The foundational principle of audit independence: the auditor performs services with objectivity and is not in a position where their judgment is compromised by relationships with the audited entity. The hundred-year-old version of the rule the agent org enforces in code.

3. Ji, Lee, Frieske, Yu, Su, Xu, Ishii, Bang, Madotto, & Fung. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 55(12). On the documented tendency of large language models to compound errors when prior output is loaded as input to subsequent reasoning. The mechanical basis for why two independent sessions are structurally more reliable than one long session.

4. Samanta, N. (2025, September 2). The Growing Challenge of Auditing Agentic AI. ISACA Industry News. Identifies a separation-of-duties violation when an AI agent grants access without formal approval, and argues an auditable agent system must give each agent a distinct identity, intentionally scoped authority, a reconstructable execution context, and a human accountable for its existence.

This paper is part of Rise of the Agent Org, a series by Ed Hoehn, SpeyAI. The full library is at speyai.com/record.