Back to course overview
Module 2Planning & reasoning 11 min

Self-reflection

Agents that check their own work: verify-after-act, the pre-finalize review, retry-with-lessons — and the hard limits of self-correction.

Pipelines get external validators. Agents can do something pipelines can't: check their own work mid-task and change course. Used precisely, reflection converts a class of failures into recoveries. Used naively, it's expensive self-congratulation. Three patterns earn their tokens:

  • Verify-after-act: after a consequential write, read it back. Updated the ticket? get_ticket and confirm the note landed as intended. Trivial, mechanical, catches silent API half-failures that would otherwise surface as customer complaints. Cheapest reflection there is — make it a rule for every write tool.
  • Pre-finalize review: before declaring done, one structured pass — 'Re-read the original ticket. List each thing the customer asked for and where your resolution addressed it. Anything unaddressed → not done.' This catches the classic agent failure of resolving a task instead of the task (answering the damage claim, missing the 'also, change my address' buried in paragraph two).
  • Retry-with-lessons: on a failed approach, force an explicit lesson before the next attempt — 'state what you tried, why it failed, and what you'll do differently.' Without the articulation step, agents retry the same move with cosmetic variations; with it, retries actually branch. (Your validator retry-with-feedback pattern, running inside the loop.)

The limits — respect them

  • Reflection shares the blind spots of the reasoning it reviews. An agent that misread the policy will 'verify' its refund against the same misreading. Self-review catches slips (skipped steps, half-done writes, unmet sub-requests) far better than misconceptions. For misconceptions you need something outside the loop: a differently-prompted checker (your judge patterns), a validator, a human.
  • Self-assessed confidence inflates. 'Are you sure?' produces yes. Structured checklists ('list each request → point to its resolution') work because they demand evidence, not vibes — the same lesson as judges needing anchored rubrics.
  • Budget it. Reflection multiplies turns. Verify-after-act on writes: always. Pre-finalize review: once. Open-ended 'reflect until satisfied': never — that's how 40-turn trajectories are born.
Prompt to try

Add this pre-finalize rule to my agent's system prompt and re-run a multi-request ticket: "Before your final summary: quote each distinct request from the original ticket, and next to each, state exactly how it was resolved or why it was escalated. If any request has no entry, keep working." Compare the trajectory with and without the rule — what did the checklist catch, and what did it cost in turns?

The shape to remember

Reflection is an inspection step the model runs on itself — powerful against incompleteness, weak against being wrong. Pair it with external validation and you have defense in depth; use it alone and you have a very articulate single point of failure.