Resilience, Reliability & Failure Handling

43 — Self-Correction Loops

Repair specific validated defects in an agent’s work through bounded feedback, preserving accepted facts and preventing repeated unsafe actions.

Concept overview

Self-correction loops use observed errors to revise an output or proposed action. A parser error, failed test, missing citation, or tool-schema rejection can provide precise feedback. The loop is useful when the defect is repairable and a reliable validator can tell whether the repair succeeded.

Distinguish correction from retry. A transient network failure may justify repeating the same request; a malformed query needs a changed proposal; an unauthorized action must remain denied. Never allow correction prompts to weaken policy or invent missing evidence simply to satisfy a validator. Preserve original errors and accepted intermediate results.

Why it matters in production

Proof of concept

A prototype can feed structured validation errors back to the model once and compare repaired output with the original. Measure introduced defects as well as successful repairs.

Production

Production classifies errors, limits attempts, protects immutable facts, and requires every revision to pass the same checks. Commands with side effects need reconciliation before any corrected attempt.

Enterprise scale

At scale, analyze repair success by defect class and disable loops that mostly consume tokens. Frequent correction may indicate a bad schema, unclear tool contract, or inadequate base model rather than a need for more iterations.

Architecture components

Error classifier

Separates transient, repairable, policy-denied, and irrecoverable failures.

Validator

Produces concrete machine-readable defects and independently checks corrected artifacts.

Correction worker

Revises only the permitted fields or action arguments within the original task scope.

Protected artifact store

Retains accepted facts, previous versions, and external operation identities.

Loop governor

Caps attempts, cost, elapsed time, and repeated equivalent failures.

The architecture, mapped

Repair follows error classification — Only repairable defects enter correction; policy denials and uncertain effects follow different recovery paths.

flowchart LR
 A["Candidate artifact"] --> V["Independent validator"]
 V --> E["Error classification"]
 E --> C["Bounded correction"]
 E --> R["Transient retry policy"]
 E --> H["Stop or human review"]
 C --> G["Regression validation"]
 G --> S["Accepted artifact"]
 G --> E
 P["Protected facts and operation IDs"] --> C

Runtime flow

1
Capture defect
Record the failed artifact and a specific validator result without losing original evidence.
2
Classify recoverability
Decide whether to retry, revise, escalate, or stop based on error semantics.
3
Constrain repair
Identify editable fields and protect verified facts, permissions, and completed operations.
4
Generate correction
Request a targeted change using structured feedback and remaining budget.
5
Revalidate fully
Apply the original checks plus regression checks on previously accepted content.
6
Finish or stop
Accept the corrected artifact or return an explicit unresolved result when progress or budget is exhausted.

Repairing a generated read-only query

Manufacturing analytics · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A factory analyst asks an assistant to compare downtime across production lines using a governed analytics service.

The problem

The model sometimes references a renamed column or returns a query whose aggregation does not match the requested period.

Agent requirement

The assistant must repair valid analytical mistakes without expanding access or issuing unrestricted database commands.

Architecture

A read-only query gateway validates schema, permitted tables, and result shape; structured errors feed a bounded correction worker.

Runtime

An unknown-column error returns the approved schema fragment, and the model proposes a corrected query within the same access scope.
The query is validated again and its result is checked for the required grouping before the explanation is generated.

Failure scenario

If the correction requests a restricted table, authorization denies it and the loop stops instead of trying alternative access paths.

Operational impact

Track repair success, repeated error classes, introduced regressions, and total cost per accepted query. Correction is a recovery mechanism, not proof of analytical correctness.

Architecture tradeoffs

Decision	Benefit	Cost
Targeted feedback	Concrete defects are often easier to fix than regenerate broadly.	Validators need precise and safe error messages.
Multiple attempts	Some repairable tasks can recover without human work.	Repeated revisions consume latency and may drift from the objective.
Protected facts	Accepted evidence survives local repairs.	Change constraints can limit legitimate broader corrections.

Failure scenarios & recovery

The model repeats the same invalid proposal

Detect: Normalized artifact fingerprints and error codes repeat.

Recover: Stop and escalate with the original defect evidence.

A repair fixes syntax but changes the requested meaning

Detect: Regression checks find altered filters or aggregation semantics.

Recover: Reject the revision and preserve the prior validated scope.

Common architecture mistakes

Sending every failure into one repair prompt

Classify transient, semantic, policy, and uncertain-effect errors.

Relaxing validation after repeated failures

Keep acceptance rules stable and stop when limits are reached.

Reexecuting a command to repair its response

Reconcile the existing operation before any new effect.

When to choose this pattern

Choose it when

Defects are localized and independently detectable.
A corrected proposal can be revalidated safely.
Repair has demonstrated value within a bounded budget.

Avoid it when

The validator cannot distinguish correct from plausible output.
The failure is an authorization denial.
The attempted effect has an unresolved external outcome.

Architecture checklist

Classify errors before choosing recovery.
Provide concrete structured feedback.
Protect accepted facts and operation identity.
Limit attempts and repeated fingerprints.
Run full regression validation after repair.
Measure repair cost and introduced errors.