Skip to content
Flows
Library Paths Vault Generate Progress Run Demo Flow
Agent QA & Security Advanced · 90-150 minutes

Stand Up an Adversarial Verification Agent

Stop trusting your agent's own 'it works': dispatch a read-only verifier that must run real commands, probe adversarially, and return an evidence-backed PASS/FAIL verdict.

Start Route · 4 steps

The route

4 steps to Done

  1. 01

    Define the verifier with hard read-only constraints

    Constraints in the tool pool, not just the prompt.

    Preview prompt + verify gate ▾

    Create the verification agent definition. Tool pool: remove edit/write/file-creation tools entirely - the constraint must be structural, so a verifier that decides to 'just fix it' physically cannot; allow read, search, and command execution (it must run builds and tests). Prompt: state the role ('verify, never repair'), the evidence rule (every claim needs the command run and output observed), and the verdict format. Add a critical reminder mechanism that re-injects the read-only constraint every user turn - long verification sessions are exactly where agents forget their role. Permission mode: command execution should surface to the parent's approval flow rather than running silently. Verify the constraint by asking a test instance to fix a trivial bug: it must refuse and report instead.

    • ✓ Edit/write tools absent from the pool (asserted in a test)
    • ✓ Constraint re-injected every turn
    • ✓ Fix-attempt test refused correctly
  2. 02

    Feed it the real task and require evidence

    Verification quality is bounded by input honesty and output proof.

    Preview prompt + verify gate ▾

    Build the dispatch: the verifier receives the ORIGINAL task description verbatim (never the implementer's paraphrase - that is how failed requirements get laundered), the list of changed files, and the claimed approach. Require the evidence format in every response: for each check, the exact command run, the observed output (quoted, truncated sensibly), and the conclusion drawn. Mandatory baseline checks: the project builds, the test suite runs (with counts: passed/failed/skipped), the linter passes, and each stated requirement has a specific check mapped to it. Reject verdicts where any check lacks its command-plus-output pair - an unevidenced 'looks good' is the exact failure mode this agent exists to kill.

    • ✓ Original task text passed through unmodified
    • ✓ Every check shows command + observed output
    • ✓ Each requirement mapped to a concrete check
  3. 03

    Add adversarial probes

    The happy path passing is where real verification begins.

    Preview prompt + verify gate ▾

    Extend the verifier's mandate beyond confirmation: require at least one adversarial probe per verification, chosen from: boundary values (empty input, zero, maximum lengths, unicode), error paths (does the advertised error handling actually fire?), idempotency (run the operation twice - does state corrupt?), concurrency (two simultaneous requests on the same resource), and negative authorization (can an unauthenticated caller reach it?). Prime the verifier against known LLM failure modes explicitly in its prompt: do not be satisfied because the first 80% looks right (the bug lives in the last 20%), and do not avoid running a check because it is 'probably fine' - probably is not evidence. Require the probe's result in the verdict even when it passes.

    • ✓ At least one probe per verification from the required classes
    • ✓ Anti-80% and anti-avoidance rules in the prompt
    • ✓ Probe results recorded pass or fail
  4. 04

    Gate completion on the verdict

    A verdict nobody acts on is decoration.

    Preview prompt + verify gate ▾

    Wire the verdict into the loop: the implementer's 'done' claim triggers verification automatically; PASS closes the task; FAIL or PARTIAL routes the itemized findings back to the implementer as the next work items (with the evidence attached, so fixes target the actual failure); repeat until PASS or a human intervenes after N cycles. Keep the roles adversarial: never let the implementer negotiate the verdict, and never let the verifier fix the code - if the same agent instance starts doing both, you have recreated self-verification with extra steps. Log verdict cycles per task as a health metric: rising cycle counts mean implementer quality is dropping or verifier standards are drifting - both worth investigating.

    • ✓ 'Done' automatically triggers verification
    • ✓ FAIL/PARTIAL findings become the implementer's next tasks
    • ✓ Cycle counts logged with an escalation threshold

Research-backed

Sources behind this flow

Tier 1 · claude-code-internals

Deep Dive: Agent Orchestration Patterns

Follows a dispatched agent through its full lifecycle - foreground vs background execution, auto-backgrounding of long tasks, sidechain transcripts for resume, layered tool filtering, and result handoff - then catalogs six reusable orchestration patterns: worker pool, pipeline, supervisor-worker, adversarial verification, fork-join, and resume chain. The adversarial verification agent, which must run real commands and issue a PASS/FAIL verdict while being forbidden from editing the project, gets special attention as a defense against LLM self-verification failure modes.