DEV Community

weiwuji
weiwuji

Posted on

Correction Sedimentation: How to Make Your System Never Repeat the Same Mistake

#engineering #agents #ai

The Pain: Your agent made a mistake. You corrected it. It apologized and said "got it, I'll remember." A week later it makes the same mistake again — just in a different disguise. You keep treating the symptom, and the problem never actually gets fixed.
What You'll Learn:

  • Why "next time, pay attention" is the biggest lie in agent development — and why LLM memory can never replace system-level rules
  • The five-step correction sedimentation loop: error occurs → record → extract root cause → embed rule → never repeat
  • A concrete FailureRecord schema and a SCENE_CONFIG example that physically hardens your agent
  • How to "physicalize" rules into verify scripts, gate checks, tool whitelists, and SOP injection
  • Why correction sedimentation beats "a smarter model" for production systems — and how the two complement each other

1. The Problem: "Next Time, Pay Attention" Is the Biggest Lie

When an LLM agent makes a mistake, this is the most common way it gets handled:

Developer: This is wrong. Next time, pay attention.
Agent: Got it. I'll remember. Next time I'll be careful.
(One week later)
Agent: Made the same mistake again — just in a different disguise.
Enter fullscreen mode Exit fullscreen mode

Why does "next time, pay attention" never work?

Because the LLM's "memory" is a soft constraint. It forgets across multi-turn dialogs. Its attention drifts inside long contexts. Under pressure it falls back to its "most comfortable" generation mode. When you tell it to "remember", it's only agreeing in the moment — it has no ability to "embed" the rule at the system level.

This is the watershed between lab prototypes and commercial systems:

  • Lab prototype: improvement relies on the LLM's "memory" (a soft constraint — it forgets)
  • Commercial system: improvement relies on engineering-level "embedding" (a hard constraint — it never forgets)

💡 Core insight: every human correction is a rule-embedding opportunity — don't tell the LLM "next time, pay attention"; directly modify the verify script or add a gate check so the system blocks this class of error forever.

The correction sedimentation loop: error occurs → record → root cause → embed rule → never repeat
Correction sedimentation is a five-step closed loop — every failure feeds the next correction.

2. The Core Mechanism: A Five-Step Closed Loop

Correction sedimentation is a complete five-step loop:

① Error occurs → ② Record → ③ Extract root cause → ④ Embed rule → ⑤ Never repeat
Enter fullscreen mode Exit fullscreen mode

Step 1: Error Occurs

The agent produces non-compliant output. It gets intercepted by a gate, or the developer/user spots it by hand.

Step 2: Record

Log it into the failure store — not just the error message, but also: the scene, the tool-call chain, a context summary, and the error type.

failure_capture.py --record \
  --scene email \
  --tool-calls '["fetch_inbox", "send_email"]' \
  --error "user asked to forward the email to sunny, but the agent queried shipping costs"
Enter fullscreen mode Exit fullscreen mode

Step 3: Extract Root Cause

Analyze the error and find the real cause — not the surface description "the agent used the wrong tool", but "smtp_send is missing from the email scene's tool whitelist".

Step 4: Embed the Rule

Turn the root cause into an executable rule:

  • Modify the verify script
  • Add a new gate check
  • Update the scene's tool whitelist 
# Before hardening
SCENE_CONFIG = {
    "email": {
        "tools": ["imap_fetch", "contact_lookup"],  # smtp_send is missing
    },
}

# After hardening
SCENE_CONFIG = {
    "email": {
        "tools": ["imap_fetch", "smtp_send", "contact_lookup"],  # smtp_send added
        "gates": ["check_forward_intent"],  # new gate added
    },
}
Enter fullscreen mode Exit fullscreen mode

Step 5: Never Repeat

Once the rule is embedded, the system blocks the error automatically — nobody needs to "pay attention", and the error becomes impossible.

3. Technical Implementation

3.1 Failure Record Format

Every correction needs a structured home. This is the schema the failure store uses:

from dataclasses import dataclass


@dataclass
class FailureRecord:
    """A record of one failure/correction"""
    timestamp: str
    scene_id: str
    error_type: str      # tool_misuse / format_error / missing_step
    description: str     # human description
    root_cause: str      # root-cause analysis
    fix_rule: str        # the embedded rule
    status: str          # pending / embedded
Enter fullscreen mode Exit fullscreen mode

3.2 Physicalizing Rules

Here is the rule that makes this whole mechanism work: every embedded rule must be "physicalized" into the system layer — not written into a prompt, written into a script.

Embedding method Example Effect
Modify a verify script verify/no_fabricated_data.py automatic check before output
Add a gate check new gate in gate-check.sh intercept at critical nodes
Update a tool whitelist add/remove tools in SCENE_CONFIG banned at the source
Update SOP injection refresh scene SOP in inject-sop injected before execution

Correction store architecture: gate intercept → failure store → verify scripts, gate checks, tool whitelists, SOP injection
The failure store sits between the gate and the four embedding targets — rules live in scripts, not in prompts.

3.3 Weekly Review

Embedding is not a one-time action. Rules decay, scenes change, and new error types appear — so the loop needs a regular review cadence:

# every Monday, auto-scan corrections that have not been embedded yet
scan_corrections.py --unembedded
# output: 3 new corrections this week, 2 embedded, 1 pending analysis
Enter fullscreen mode Exit fullscreen mode

Each un-embedded correction goes back through root-cause analysis. Each embedded rule has to pass the regression suite before it is trusted:

Weekly regression verification flow: scan → root-cause analysis → embed rule → regression tests → all pass? → mark embedded, or loop back to re-analyze
Regression verification closes the loop — every rule is proven before it is trusted.

4. Why This Matters More Than a Smarter Model

Many people assume the agent makes mistakes because the model isn't smart enough, and that switching to a stronger model will fix everything.

That's a misconception.

A stronger model does lower the error rate — but it will never reach 100%. Correction sedimentation, on the other hand, turns any already-discovered error into "impossible to recur", no matter how strong or weak the model is.

The two are complementary:

  • Stronger model → lowers the occurrence rate of unknown errors
  • Correction sedimentation → eliminates the recurrence rate of known errors

Commercial systems don't chase "never making a mistake". They chase "automatically improving after a mistake". Correction sedimentation is the underlying mechanism of that automatic improvement.

5. Where You Stand Now

Right now, you are no longer the helpless developer who tells the agent "next time, pay attention" after every mistake. You are becoming an engineer who can turn every mistake into evolutionary fuel for the system.

Every human correction isn't wasted effort — it's feeding the system one evolution. Error → record → root cause → embed rule → never repeat the same mistake. Day by day the system gets more stable, and your maintenance cost keeps dropping.

Next article: the last safety pillar — tool isolation and least privilege, locking down the agent's behavioral boundary completely.

About the author: Wu Ji (无记) — AI & digitalization practitioner focused on Agent engineering, Loop Engineering, and digital transformation. Practical, hands-on tutorials — follow along and it just works.

Top comments (0)