Loops And Verification Patterns

Loops and Verification Patterns

Process reference. The two kinds of loop that drive work on a2waspwarfare — recurring execution and the adversarial verification loop — plus the convergence patterns. Written 2026-06-24. Part of the Agent orchestration playbook; methodology, not gameplay code.

Two Senses Of "Loop"

"Loop" means two different things here, and both matter:

1. Recurring execution — run the same task again on an interval or schedule (monitoring, polling, standing passes).
2. Iteration for thoroughness — re-run within a single task until you have converged (found everything, or confirmed a finding).

Recurring Execution

Mechanism	What it does
/loop <interval> <command>	Re-run a prompt or slash command on a fixed interval, e.g. /loop 5m /minipc to poll health, or a watcher that re-scans logs.
/loop (no interval)	Self-paced: the model schedules its own next wake-up, sized to what it is waiting for.
Scheduled skills / cron	Run a routine on a wall-clock schedule, unattended.

Self-pacing has a cost model worth knowing: the prompt cache has a roughly 5-minute time-to-live, so a wake-up under ~270s stays warm and cheap, while idle checks should sleep long (20 to 30 minutes) rather than burn cache every few minutes for nothing.

On this project the recurring loop shows up as RPT error trackers (re-scan the client log every few minutes and digest new errors) and the standing documentation pass in Claude loop goal.

Iteration For Thoroughness

Inside one task, loop until a stop condition instead of guessing a fixed amount of work:

Pattern	Stop condition
Loop-until-count	Accumulate findings until you hit a target (e.g. 10 bugs).
Loop-until-budget	Keep going while token budget remains — scales depth to a "+500k"-style directive.
Loop-until-dry	Stop after K consecutive rounds find nothing new. Best for unknown-size discovery.

The Verification Loop

This is the heart of how findings become trustworthy here. The standing rule on this project is to use subagents and loops with adversarial verification by default on substantive work — not single-pass answers.

The shape:

1. Find — a fleet of finders surfaces candidates.
2. Verify — each candidate goes to independent skeptics prompted to refute it, defaulting to "refuted" when uncertain.
3. Confirm — keep a candidate only if a majority fail to refute it.

Why it works: a single agent will confidently report a plausible-but-wrong finding. Independent refutation, with the burden of proof on the claim, filters those out before they drive a change.

The wiki's own accuracy pass is a worked example: a find pass produced a large candidate set of corrections; a second strict refute-default reverify, run against the correct branch baseline, confirmed most as real and rejected the rest as branch-baseline artifacts. The corrections were only then applied.

Convergence Pitfalls

• Dedup against everything seen, not everything confirmed. In a loop-until-dry, if you dedup new findings only against confirmed ones, judge-rejected findings reappear every round and the loop never converges. Track a seen set.
• Don't poll work the harness will notify you about. If a background agent or tracked job will wake you on completion, sleeping to poll it is wasted — schedule a long fallback instead.
• Announce silent stops. If a loop is capped (max rounds, sampling), say so — a silent cap reads as "covered everything" when it didn't.

Putting It Together

A thorough pass on this project is usually all three primitives at once: loop-until-dry over a fleet of finder subagents, each fresh finding routed through the verification loop before it is written to an owner page. See Agent orchestration playbook for how the pieces fit, and Agent collaboration protocol for the publish gates.

Continue Reading

Previous: Multi-agent fleet orchestration | Next: Agent collaboration protocol

Main map: Home | Fast path: Quickstart | Agent file: agent-context.json