Marking its own homework: how do you check what an AI agent actually did?

I don't trust an AI agent with sensitive work, and I don't have to. The work gets checked by narrow specialists instead: one reviewer for data handling, one for whether the sources say what the text claims, one for whether the tests test anything. A reviewer with a single question to answer finds more than a reviewer asked to check everything.

The question I get asked most often about agents is some version of "how do you know it did the right thing?". It's the right question, and the honest answer is that you don't know, not from looking at the output. A wrong answer from a competent model looks exactly like a right one. It is well formatted, confident, and internally consistent, which is precisely why reading it over and thinking "that looks fine" is not a control.

So the checking has to be structural. Below is how I actually do it, what it costs, and the objection everyone raises in the first five minutes, which is a fair one.

Why does "check this for me" find so little?

Because an open brief turns a model into an editor, and editors improve prose.

Ask for a general review and you will get a tighter opening, better sentence structure, and a suggestion that the third section moves up. What you won't get is a note saying the second citation points at a real page that doesn't contain the claim attached to it. Not because the model could not tell, but because nothing in the brief made that its job. Given a vague instruction, a model optimises for the most obvious reading of it, and the most obvious reading of "review this" is "make it better".

There is a research version of this point. A Google DeepMind team examined intrinsic self-correction, where a model is asked to improve its own answer "based solely on its inherent capabilities, without the crutch of external feedback", and found that models "struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction" (Huang et al.). "Have another look" is close to the weakest instruction available. A named risk, a rubric and a pass or fail verdict is the external structure that makes the second look worth anything.

The more useful half of this is what it does to a clean result. When a specialist with one narrow question comes back with nothing, that silence carries information. When a general reviewer comes back with "looks good", it carries almost none.

What does a good specialist reviewer look like?

Narrow, adversarial, and unable to tidy anything. In practice each one has:

• One named risk, expressed as a question with a pass or fail answer.
• Evidence for every finding. Quote the line, name the file, cite the row. A finding without a location is an opinion.
• A playbook of failure modes to hunt for, written from things that have actually gone wrong before.
• No authority to fix. Separating finding from fixing keeps the record honest, and stops a reviewer quietly editing away the evidence of its own concern.
• Permission to be unsure, with "I don't know" routed to a person rather than rounded down to a pass.

The briefs themselves are boring, which is the point:

Overlap between them is a feature. Two specialists both looking at numbers from different angles is not duplicated effort, it's the cheapest redundancy you will ever buy. The waste worth worrying about is not a second reviewer, it's a review nobody reads.

I run exactly this on a client project I'm working on at the moment. Every change passes a panel of reviewers, each with one brief: data security, licensing, tests, plain English, whether it delivers what was asked. The few that guard something irreversible can block the change; the rest can only advise. None of them can edit a line. They cite the rule that was broken, and a separate agent does the fixing.

Isn't this just AI marking its own homework?

Technically, yes. It's worth being precise about what rescues that and what does not.

What doesn't rescue it: a second opinion from the same model, in the same conversation, under the same instructions. Same context, same assumptions, same blind spots, plus a bias towards agreeing with what's already on the page. Models are also measurably kind to themselves. One study found that GPT-4 and Llama 2 can distinguish their own outputs from other models' and from human text, and that there is "a linear correlation between self-recognition capability and the strength of self-preference bias" (Panickssery et al.). A model grading its own work in its own context isn't a review, it's a formality.

What helps is separation. A different context window, a different system prompt, a different rubric, and sometimes a different model. Anthropic describes the same mechanism in its own multi-agent systems, where subagents operate "in parallel with their own context windows" and each one provides a separation of concerns through distinct tools, prompts and exploration trajectories, "which reduces path dependency" (Anthropic). A reviewer that never saw the reasoning which produced the work cannot inherit the flaw in it.

Two things keep me honest about how far that goes. The independence is partial: two instances of the same model share training data, so they share some blind spots, and this is not the same as two unrelated auditors. And model judges have known, named biases, including position, verbosity and self-enhancement, alongside limited reasoning (Zheng et al.). The same work found strong judges reaching "over 80% agreement" with human preferences, "the same level of agreement between humans", which is the fairest summary of the whole approach: good enough to be genuinely useful, nowhere near good enough to be left alone.

So the playbooks exist mostly to blunt those specific biases. Judge the evidence, not the prose. Require a quote for every finding. Fix the order in which options are assessed. None of it is clever, it's just the difference between a review and a vibe.

Doesn't running five reviewers cost five times as much?

You wish it was only five. Anthropic's own measurement is that multi-agent systems use "about 15× more tokens than chats" (Anthropic). That's the honest starting position, and there are two answers to it.

The first is that the comparison is usually wrong. Five reviews of a document that decides a payment, a contract clause or what a customer is told is trivially cheap against the thing being protected. If the work genuinely doesn't matter, don't review it, and possibly don't automate it either.

The second is triage, for the cases where cost and correctness both matter: A cheap, fast model looks at each piece of work and decides which specialists need to wake up. The instruction it gets is deliberately lopsided: its job is to rule reviewers in, not out, and anything ambiguous gets the full treatment. That asymmetry is the whole design, because a wrong "no review needed" costs you an incident and a wrong "review it anyway" costs you pennies.

This is a cascade, and it's a well-studied pattern rather than a trick. The FrugalGPT work showed a learned cascade matching the best single model's performance "with up to 98% cost reduction" by sending only the queries that need it to the expensive model (Chen, Zaharia and Zou). It's the same shape as any sensible triage: cheap classification at the front, expert attention behind it, as in the IT ticket routing I built on the same principle.

What stops this being AI all the way down?

The specialists are the visible part. They only work because each one sits inside ordinary, boring engineering.

• Deterministic validation runs first. If a check can be code, it should be code. Schema validation, totals reconciling, a regular expression for card numbers, a link that has to return a 200. Never pay a model to do something an if statement does perfectly and for nothing.
• Guardrails on what each agent can reach. What it may read, write, spend and send, scoped as tightly as the job allows. A reviewer that only needs to read should only be able to read.
• Version control on the prompts and playbooks. They are configuration, they change, and a change to a reviewer's brief can quietly stop it catching things. This is one of the five habits in what makes an automation last, and prompts are not exempt from it.
• Evaluations made of real failures. A set of known-bad examples each specialist must catch, run whenever its brief changes. Without them, editing a reviewer prompt is guesswork with a good feeling attached.
• Audit logging on every verdict. What was checked, what was decided, on what evidence, by which model. You cannot reconstruct this later, because the information never existed.
• Escalation as the answer to uncertainty. "I am not sure" is a first-class output, routed to a human, not a failure state to be engineered away.

That last one does more work than any of the others. Most of the damage I've seen from automated work came from a system that had no way to express doubt, so it expressed confidence instead.

What is the difference between an agent and a subagent?

Frequently nothing at all. Same model, same tools, different brief. "Subagent" describes a position in a pipeline rather than a kind of thing: it was dispatched by something else rather than by you.

The arrangement that matters is how they get dispatched, and there are two:

• Fan out every time. Every specialist runs on every piece of work, independently and in parallel. Cost is predictable, nothing depends on a single judgement call, and it suits work where the stakes are uniform.
• Dispatch by an orchestrator. One triage step decides who runs. Cheaper on volume, and it adds a failure mode the first option doesn't have, because the dispatcher can be wrong about what matters. Hence biasing it towards over-calling.

Which one you want is a cost and variance decision, not a matter of principle. What doesn't change is the surrounding structure: the pipeline connecting them should be ordinary deterministic plumbing, with judgement confined to the steps that need it, which is the same argument as AI agents versus simple automation.

How would you apply this to a process of your own?

Five steps, in order, and the first one is not technical.

1. Write down what "wrong" would actually cost. Name specific failure modes, not "quality". A wrong figure in a board pack, a customer's data in the wrong place, a promise your terms don't support.
2. Give each failure mode one reviewer with one question. If you cannot phrase it as a question with a pass or fail answer, the brief is still too broad.
3. Move every check that can be code into code, and only then decide what is left for a model.
4. Decide the escalation route before you need it. Who receives the uncertain ones, how quickly, and what they are expected to do.
5. Keep every failure that escapes. Each one becomes a test case, and the reviewers get better at the specific ways your business goes wrong rather than at reviewing in general.

The bottom line

Do I trust my agents with sensitive work? No. I trust the arrangement around them, which is a different claim and a much more defensible one.

Now you know the arrangement: narrow specialists that each answer one question with evidence. Deliberate overlap, because redundancy is cheap. Separate contexts, so the checkers don't inherit the maker's assumptions. Deterministic validation wherever a rule can be written down. Logs of what was decided and why. A cheap triage step when volume makes the full set expensive. And a human on the end of every "I am not sure".

Trust is not a property of a model. It is a property of the system you put around one, and unlike the model, that part is entirely under your control.

If you have an agent doing something that would be expensive to get wrong, or you are about to build one, a thirty-minute discovery call will tell you where the checks need to sit. See AI consulting and process automation for how I approach the work.