DEV Community: Q00

Your agent loop is teaching the model to cheat

Q00 — Sun, 09 Aug 2026 01:43:54 +0000

Wrapping a loop around an AI coding agent is the obvious next move once single-shot prompting stops working. Run it, score it, retry if the score is low.

Two walls show up right after:

The score goes up and the work is still wrong. The agent learned to satisfy the grader, not the task.
Failure is a dead end. Every piece of the loop exists, but a failed run never feeds the next one.

Both are environment design problems rather than model problems, and they don't go away as models get stronger. A stronger model finds the shortcut faster.

I want to walk through both using a concrete, readable example: an RFC that recently landed in Ouroboros, an open-source Agent OS. The design is written up in issue #1917, implemented in #1916. You can read the whole thing yourself, which is why I'm using it rather than describing something abstract.

Wall 1: you handed the answer key to the candidate

Most agent harnesses render the acceptance criteria straight into the worker's prompt, including the command that will grade it and the assertion it will be graded against. The motive is reasonable: if the agent knows how it will be checked, it can aim at the right target.

Ouroboros did exactly this. _build_success_contract_block rendered verify_command and Expected output: <assertion> into the worker's instructions. A second leak was harder to spot: on retry, the failure reason carried the assertion's repr(), which rode result.error back into the next prompt.

Once the agent can see the assertion, satisfying the assertion is cheaper than satisfying the requirement. The RFC names this directly: a struggling worker's cheapest path is to game the assertion string rather than implement the acceptance criterion, with a postmortem (seed_2be2907edc07) attached. That is textbook reward hacking. You think you are measuring capability; you are measuring the ability to copy an answer.

The fix: hide it unconditionally

Both leak paths have to close. Closing the forward one alone accomplishes nothing:

Forward: _build_success_contract_block now renders only the AC description and expected_artifacts. The harness verifies independently, so the worker never sees the grading logic.
Backward: the verify-gate failure reason no longer embeds the assertion repr(). Retry hints come from a dedicated assertion-safe builder (orchestrator/retry_hints.py) that filters the assertion string out of every fragment, including the 2000-character tail of command output.

That 2000-character tail is the part worth copying. Plug the main path, forget the log tail, and the leak is still open.

The RFC also records that a "disclosure level" config knob was proposed and rejected. An information barrier that can be turned off will get turned off on some afternoon when someone is behind schedule, and nobody will notice, because the scores will look better afterward.

What a stuck agent gets instead

Hiding everything would leave the worker flailing, so the RFC pairs it with a hint loop. The next round's instructions are reconstructed from what the session actually did: the tool-call trace, the evidence manifest (reusing deliver_gate.load_ac_evidence_manifest, read-only), and the verifier's outcome. Not from the assertion.

	Disclose the answer	Trace-based hints
Agent sees	"the assertion requires output == `X`"	"you called A and B, artifact C is missing, verification failed at step 3"
Cheapest path	fabricate `X`	actually produce C
Does a rising score mean rising capability?	No	Yes

This is information asymmetry, the same arrangement human exams use: the examiner knows the answer, the candidate only learns where they went wrong.

Wall 2: failure is a dead end

From the RFC: every piece already existed (the verify gate, the run-to-eval chain, evolve_step, the Ralph driver, focus.select_evolution_focus), but nothing connected them.

A failed run never entered formal evaluation. Failure was terminal and surfaced as BLOCKED.
A rejected evaluation never entered evolution. Also terminal.

The loop existed as three disconnected segments. Failures were reported, not digested.

The fix: chain run to eval to evolve

Three constraints carry the weight:

1. Failed runs also chain into evaluation. The _run_succeeded gate is relaxed, so any run that produced a session chains into formal evaluation. Fail-open is preserved: an enqueue failure never flips the run's result.

2. A rejected evaluation triggers a budgeted evolution loop. Nobody reimplemented a convergence loop here. The evaluate job's terminal path enqueues the existing evolution machinery when final_approved is False.

The new piece is a Gen1 bridge: the run's seed plus the chained evaluation's multi-AC checklist get projected into lineage events, so evolve_step replays the plain run as Generation 1 and starts Generation 2 already focused.

3. Only failed ACs go to the next generation; passing ones freeze. This one buys the most.

Making it work required a checklist-to-ACResult converter that satisfies a strict bar: complete index coverage, verbatim ac_content, and semantic_ac_key identity. That strictness is what lets focus.select_evolution_focus freeze the passing ACs.

A loop that does not freeze what already passed will redo work it already got right, burning tokens and breaking correct implementations along the way. The symptom is a score that oscillates between generations.

The loop has to be able to stop

A loop will not stop on its own.

Ouroboros reuses Ralph's existing stop conditions: QA pass, convergence, oscillation detection, grade regression, and wall clock. execution.auto_evolve_max_generations defaults to 3, clamped to 1..10. BLOCKED only happens after the budget is exhausted.

Oscillation detection and grade regression are the two that catch false convergence: a score bouncing A to B to A to B, or a generation worse than its parent. Both halt the loop instead of burning more tokens.

One more fix. evolution/loop.py had a bare except with three silent paths to evaluation_summary=None. It now records a rejected summary carrying the failure reason, which preserves fail-closed focus semantics while making the failure durable.

Swallow an exception in a single run and you are wrong once. Swallow it in a loop and the error is amplified across N generations while your logs show nothing.

Cheap gates before expensive ones

The same pattern runs through the rest of the design.

Evaluation is tiered: Mechanical (free, deterministic checks), then Semantic, then Multi-Model Consensus. Anything rejected at layer one never reaches an LLM judge.

The interview stage uses a number instead of a tier. Ambiguity is quantified as the inverse of weighted clarity:

Ambiguity = 1 - Sum(clarity_i * weight_i)

A seed spec cannot be generated until it is <= 0.2, and convergence waits for ontology similarity >= 0.95. Two mathematical gates, and the README states the idea behind both: don't write until it's clear, don't stop until it's stable.

What to check in your own loop

Don't show the grading criteria to the candidate. Audit whether your harness leaks assert strings back through error messages, log tails, or retry prompts. Close the forward and backward paths, and don't make it a config option.
Failure needs a next step. Failed runs should reach evaluation, rejected evaluations should reach evolution, and passing work should freeze.
The loop must halt and must detect false convergence. Oscillation, grade regression, wall clock, generation budget.

Full RFC: Q00/ouroboros#1917. Implementation: #1916. Design docs live in-tree under docs/hidden-checklist-convergence/ (requirements, architecture, implementation). The project is github.com/Q00/ouroboros: MIT, local-first, and it sits in front of 13 runtime families.

If you're running multi-generation agent loops in production, how do you handle false convergence? That's the part I've seen the fewest good answers to.

Specification-first AI development with Ouroboros

Q00 — Sun, 09 Aug 2026 00:03:30 +0000

Most AI coding tools fail before they write a single line of code. The prompt was vague, and the model quietly filled the gaps with assumptions you never agreed to.

You ask for "a task management CLI." The model picks a data model, a priority scheme, a persistence layer — all reasonable, none of them yours. You find out three files in, during review, and you rework it. That's the loop most of us are stuck in: prompt, guess, rework, repeat.

Ouroboros is an open-source Agent OS that fixes the input instead of the output. It's a local-first runtime layer that sits in front of Claude Code, Codex CLI, OpenCode, Gemini CLI, GitHub Copilot CLI, Kiro, Hermes, Pi, and Zcode, and replaces ad-hoc prompting with a five-stage, replayable workflow: interview, seed, execute, evaluate, evolve.

The real problem is unclear intent

Ouroboros' own framing of this is a simple table:

Problem	What happens	Ouroboros fix
Vague prompts	AI guesses, you rework	Socratic interview exposes hidden assumptions
No spec	Architecture drifts mid-build	Immutable seed spec locks intent before code
Manual QA	"Looks good" isn't verification	3-stage automated evaluation gate

The fix targets clarity, not capability.

The loop

Interview -> Seed -> Execute -> Evaluate
    ^                           |
    +---- Evolutionary Loop ----+

Interview: Socratic questioning surfaces the assumptions you didn't know you were making.
Seed: your answers crystallize into an immutable specification: acceptance criteria, ontology, constraints.
Execute: the seed runs through a Double Diamond decomposition (Discover → Define → Design → Deliver).
Evaluate: a 3-stage gate: Mechanical (free, deterministic checks) → Semantic → Multi-Model Consensus.
Evolve: the evaluation output feeds back into the next generation's seed, and the cycle repeats until the system stops learning anything new.

Each cycle is meant to converge, not just repeat. The stopping condition isn't a timer or a step count. It's math.

The interview ends when the math says so

This is the part I found most concrete. Ouroboros scores ambiguity as the inverse of weighted clarity across four dimensions (goal, constraints, success criteria, and context for existing codebases):

Ambiguity = 1 - Sum(clarity_i * weight_i)

A greenfield example from the README:

Goal:       0.9 * 0.4  = 0.36
Constraint: 0.8 * 0.3  = 0.24
Success:    0.7 * 0.3  = 0.21
                        ------
Clarity                = 0.81
Ambiguity = 1 - 0.81   = 0.19  <= 0.2 -> Ready for Seed

A Seed, the immutable spec that execution is built from, can't be generated until ambiguity drops to 0.2 or below. Above that threshold, you're still guessing at architecture, so the system keeps asking questions instead of letting you (or the agent) start writing code on a shaky foundation.

The evolutionary loop has a matching gate on the way out: it stops when ontology similarity between consecutive generations reaches 0.95, with separate detection for stagnation, oscillation, and repetitive feedback so it doesn't spin forever on a question it already answered.

Trying it

curl -fsSL https://raw.githubusercontent.com/Q00/ouroboros/main/scripts/install.sh | bash

Then, inside a supported AI coding agent session:

> ooo interview "I want to build a task management CLI"

The installer auto-detects which supported runtime you're using (Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Hermes, Gemini, Kiro CLI, Pi CLI, Zcode) and registers the MCP server where the host supports it. Everything after ooo interview (seed generation, execution, evaluation, the evolve loop) is driven from inside that same session. There's also a plain ouroboros CLI for running things from the terminal directly (ouroboros run seed.yaml, ouroboros status executions, and so on).

There's also ooo ralph, which runs the evolutionary loop persistently across session boundaries. If your machine restarts mid-loop, it reconstructs the lineage from an event store and picks up where it left off rather than starting over.

What this changes in practice

Ouroboros makes the input to your first try something you actually agreed to — a paper trail (the seed, the ledger, the evaluation stages) you can inspect afterward instead of reconstructing intent from a diff. It won't guarantee better code on the first attempt; it guarantees you know what you asked for.

If you've felt the specific pain of "the AI built something reasonable, just not the thing I meant," a spec-first loop like this is worth a look. It's MIT-licensed, Python 3.12+, and the repo has runtime guides for each supported CLI: github.com/Q00/ouroboros.