← All posts

The 7-section Self-Critique Gate: how we automate trust

To move fast, you must be your own harshest critic. Inside the 7-section block that tamer enforces on every single Work Item [DONE] event.

· tamer team · 11 min read

In a traditional development workflow, the "Peer Review" is the final gate. But when you are shipping at a multi-agent cadence, waiting for a human to review every single line of code becomes the primary bottleneck.

To solve this, we don't just ask agents to "review their work." We enforce a 7-section Self-Critique Gate on every [DONE] event. Before a worker is allowed to submit its Work Item (WI), it must fill out these seven sections with brutal honesty.

1. AC actually covered

This isn't a simple "Yes/No." The agent must explicitly map each Acceptance Criterion (AC) from the spec to a specific file or test case. If an AC is missing, the gate remains closed. This prevents the "I forgot the last point" failure mode.

2. What I skipped / hand-waved / assumed

This is the most critical section for long-term health. Agents are naturally "eager to please" and often hide complexity behind assumptions. By forcing them to list what they didn't do or what they "hand-waved" (e.g., using a mock instead of a real integration), we make the technical debt visible before it's even committed.

3. Edge cases not covered

No PR covers every edge case. But knowing which ones were skipped allows the Master Agent to create follow-up WIs immediately. "I didn't handle the empty-string case in the parser" becomes a task for the next worker, rather than a bug for the next month.

4. Scope drift

Did the agent fix a "small bug" in a distant file while working on the primary task? In tamer, this is often a regression risk. If the agent admits to scope drift, the Master Agent can flag it for manual review or ask the worker to revert the unrelated changes.

5. Tests: Contract or just Happy Path?

We ask the agent to self-assess the quality of its tests. Is the test suite a true "contract" that ensures the invariant holds, or is it just a "happy path" that gets the coverage bars to turn green? If it's just a happy path, the task is marked as "Technical Debt Pending."

6. What was cut for time

When a worker reaches its token limit or its "max-turns" threshold, it often rushes to finish. This section asks: "If you had 10 more turns, what would you have done differently?" This surfaces the refactorings that were skipped under pressure.

7. What could break this

A request for "Anticipated Regressions." We ask the agent to think like an attacker or a frustrated colleague. "A change in the Nginx config could break the CSP headers I just added." This section populates the project's Risk Ledger, which the Master Agent uses to prioritize future audits.

Why this works

The 7-section gate works because it leverages the asymmetry of agentic intelligence: an agent might not be smart enough to implement a perfect feature on the first try, but it is often smart enough to identify its own shortcuts when forced to reflect on them.

By making this self-critique a mandatory part of the protocol, we turn "ghost bugs" into "known limitations." And in agentic engineering, a known limitation is just a Work Item waiting to happen.


Learn more: