Every task gets two separate agents — a builder does the work, a validator audits it against the spec (never the builder's output) — because no agent certifies its own output.

Pattern

Builder-Validator Pair

The shape

Two agents. Two prompts. One task.

Builderexecutes

1reads task + requiredReads

2performs Write / Edit

3runs verification cmds

4writes build-summary.md

5writes discoveredContext

6writes selfAudit

7task_update completed

→

spawn

Validatoraudits

1reads TDD spec (ground truth)

2reads discoveredContext

3reads selfAudit

4runs verification cmds independently

5scrutinizes shortcuts

6writes report.md

7STATUS: PASS / FAIL

PASS → next builder spawns

FAIL → correction task for builder

Stop hook → verifies filesExpected

The pair is atomic per task — not a pipeline stage you can skip. A task without a paired validator is self-certified work, which is not verification.

The mechanism that makes it bite

selfAudit — the builder's forced confession.

selfAudit: {...}

attack surface

selfAudit:

assumptions:

- "task didn't specify timezone — assumed UTC"

shortcuts:

- " skipped error handling when fetch() returns None"

- "no retry logic on the HTTP client"

patternAlignment:

- "followed existing auth middleware pattern" # claim

Effect on Builder

Declaring a shortcut costs more than taking it silently. Agents that must self-report tend to take fewer undeclared shortcuts.

Effect on Validator

Instead of generic review, the validator gets a self-flagged risk map. "Skipped error handling for None" is an exact audit instruction.

selfAudit is the intelligence that converts the validator from a generic checker into a targeted auditor. Remove the field and the pair becomes ceremonial.

The ground-truth rule

Ground truth is the spec — not the builder's output.

Corroborationworthless vs systematic error

1Validator reads build-summary.md

↓

2confirms builder's story

↓

3PASS — internally consistent

The builder misunderstood the spec. The validator read the builder's interpretation and confirmed that was consistent. Two agents, one blind spot, shipped.

Independent verificationcatches systematic error

1Validator reads TDD spec

↓

2derives expected output

↓

3checks actual vs derived

Spec is ground truth. Output is a claim. The validator's derivation is independent of the builder's interpretation — so a shared misread doesn't survive.

Running the same grep the builder ran and agreeing with the result is not an independent audit either. The verification commands the validator runs must be derived from the spec, not copied from the summary.

Specialist audits beyond the validator

Companion agents — deployed by risk class, not as second validators.

Trigger condition

Companion

Builder touched async code or error handling

silent-failure-hunter

Builder touched visible UI

ui-tester

Builder added a new API endpoint

test-creator

Last task in a phase

code-simplifier

Companions are specialized auditors, not a second general validator. They cover risk classes a general-purpose validator doesn't dig into deeply enough — and they're conditional, not mandatory.

The discipline

Self-certified work is a claim. Independent audit against the spec is proof.

Two agents, two prompts, two perspectives — one task. The builder executes and confesses; the validator audits the confession against the source of truth. No exceptions, no pipelines without the pair, no validator that trusts the summary over the spec.