10 — Reflection Loops

Concept overview

Reflection loops evaluate an agent's draft or execution result and feed actionable feedback into a revision step. The evaluator may be a separate model, deterministic checks, a human rubric, or a combination. The key distinction is that a critique identifies a concrete defect and an acceptance criterion; asking the same model to think harder is not a reliable architecture.

Repeated model agreement does not establish truth because correlated errors can survive every pass. Anchor reflection in external evidence, schema checks, or executable tests. Preserve the original artifact and each revision so operators can detect when a superficially polished version introduces factual regression.

Why it matters in production

Proof of concept

A prototype can compare first drafts with one revised draft on a labeled evaluation set. Keep the loop only if improvement exceeds the added latency and cost.

Production

Production separates factual checks from style preferences, caps revision attempts, and prevents a critic from broadening the task. Revisions must revalidate evidence references and mandatory content.

Enterprise scale

At scale, route only likely-defective artifacts through expensive critique. Track defect classes, critic precision, revision acceptance, and cases where the original draft was better than the revised result.

Architecture components

Draft producer

Creates an initial artifact with explicit evidence and output requirements.

Rubric evaluator

Identifies localized defects against versioned criteria and records supporting observations.

Revision worker

Applies bounded corrections without changing accepted facts or expanding authorized actions.

Comparison gate

Checks regressions and selects the best validated version rather than always choosing the latest.

Revision ledger

Stores artifact versions, critique reasons, outcomes, and consumed budget.

The architecture, mapped

flowchart LR
 E["Verified evidence"] --> D["Initial draft"]
 D --> C["Rubric critic"]
 C --> R["Targeted revision"]
 R --> V["Regression checks"]
 D --> B["Version comparison"]
 V --> B
 B --> A["Accepted artifact"]
 V --> X["Unresolved defect queue"]

Runtime flow

1. 1

   Establish rubric

   Define what correctness, completeness, and presentation mean for this particular artifact.

2. 2

   Create baseline

   Generate and retain the first draft with its source evidence and configuration versions.

3. 3

   Evaluate defects

   Apply deterministic checks first, then use a critic where semantic judgment is necessary.

4. 4

   Request targeted revision

   Send specific defects and protected facts, with a maximum change scope and budget.

5. 5

   Check regressions

   Re-run factual and structural validation and compare the revised artifact against the baseline.

6. 6

   Accept or escalate

   Publish a validated version or expose unresolved defects when the revision ceiling is reached.

Reviewing a patient-facing appointment letter

Healthcare administration · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A hospital scheduling service produces letters that combine appointment instructions, location details, and accessibility information.

The problem

Initial drafts can omit preparation instructions or introduce confusing phrasing even when the source schedule is correct.

Agent requirement

The assistant must improve clarity and completeness while preserving verified times, locations, and clinician-approved instructions.

Architecture

A draft generator uses approved records; deterministic checks protect critical fields, and a semantic critic evaluates readability and missing requirements.

Runtime

• The first draft is checked against a letter rubric, and a missing transport-access note becomes a targeted revision request.
• The revised letter is compared with the original, with appointment facts checked again before staff release.

Failure scenario

If the critic recommends an unsupported preparation instruction, the evidence gate rejects that change and retains the verified draft.

Operational impact

Measure omission rate, introduced factual errors, revision acceptance, and staff editing effort. The loop supports communication quality, not clinical decision authority.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Treating self-approval as factual verification

Ground checks in evidence or independent test criteria.

Always publishing the last revision

Compare validated versions and preserve the best result.

Using an unbounded improve prompt

Specify defects, protected facts, and stopping conditions.

When to choose this pattern

Choose it when

• Artifacts have clear rubrics and measurable defect classes.
• One revision produces demonstrable quality improvement.
• The workflow can afford additional evaluation latency.

Avoid it when

• No external criterion distinguishes improvement from preference.
• The task requires immediate response with no revision budget.
• The same ungrounded model is the only source of truth.

Architecture checklist

• Version the critique rubric.
• Preserve the original artifact.
• Protect critical facts during revision.
• Limit critique and revision attempts.
• Measure critic precision and introduced errors.
• Provide a terminal unresolved-defect outcome.

Related concepts

• 9 — ReAct Framework (Reasoning + Acting)
• 28 — Deterministic Data Grounding
• 31 — LLM Evaluation Frameworks (TruLens/Ragas)
• 43 — Self-Correction Loops
• 72 — Self-RAG / Self-Reflection

Primary references

• Reflexion: Language Agents with Verbal Reinforcement Learning
• TruLens: the RAG triad