Reflection

Also known as: self-critique, self-refine, self-review

The agent critiques and revises its own output before returning it.

TrackAgentic systems FamilyCore loop Maturity Established ChangesVerification

Problem

First drafts from a model often have fixable problems: a missed requirement, a wrong number, a format slip, an unsupported claim. The model could catch many of these if asked to look, but in a single pass it never does.

Reviewing is easier than writing, so a second look catches real errors.
The same model shares its own blind spots and tends to approve its work.
Every review round adds latency and cost.
Vague “make it better” prompts produce cosmetic edits, not fixes.

Solution

After the first draft, run the same model again with a critic prompt and an explicit checklist: requirements met, facts supported by the provided sources, format correct. The critic lists concrete issues or says none. If there are issues, the model revises the draft to address exactly those, and the loop stops after one or two rounds. Where you can, replace self-judgment with an external check such as running the code, validating the schema or matching numbers to source data.

Diagram

A checklist keeps the critique specific. External checks, like running tests, are stronger signals than the model's own opinion.

When to use

Use it when

Errors are cheap to detect once you look (format, missing items, math)
You can write a short, specific checklist
A bit of extra latency is acceptable for higher quality
An external signal is available, such as tests, a schema or source data

Avoid it when

Quality needs an independent judge; use Evaluator–Optimizer
The task is simple and first drafts are already reliable
Real-time responses where every second counts

Trade-offs

Latency

Adds 1–2 extra model passes

Cost

Roughly 2–3× a single pass

Complexity

One extra prompt and a round limit

Reliability

Catches surface errors; misses shared blind spots

Gains

Cheap quality lift with no extra models or infrastructure
Catches missed requirements and format errors reliably
The critique doubles as an explanation of what was checked

Costs

Self-approval bias, since the model often likes its own work
Can over-edit good drafts into worse ones
Weak on factual errors the model believes are true

Worked example

Scenario
An agent drafts a customer email summarizing a production incident, using the incident ticket as its source.

DraftWrites a 180-word email covering impact, root cause and next steps.
CritiqueChecklist results: duration in the email says 2 hours but the ticket says 47 minutes. No ETA for the fix. Internal hostname db-prod-07 is exposed. verdict: revise (3 issues)
ReviseCorrects the duration to 47 minutes, adds a fix date of Nov 12, and replaces the hostname with “a primary database”.
CritiqueAll checklist items pass. verdict: done (round 2)
LogOver a month, the “internal details exposed” check fires most often. That becomes a permanent rule in the drafting prompt.

Failure modes

Failure	Symptom	Mitigation
Rubber-stamping	Critic says "looks good" almost every time	Ask for specific issues per checklist item; add external checks
Over-editing	Revisions change correct content or tone	Revise only flagged issues; keep the rest verbatim
Shared blind spot	Same wrong fact survives every round	Check facts against sources, or use a different model as judge
Endless polishing	Rounds continue with tiny changes	Cap at 2 rounds; stop when no checklist item fails