Reflexion memory lets an AI agent reuse lessons from past attempts without changing its model weights. The rule is simple: store lessons with their source records, retrieve only those that fit the task, and check whether they help.
A working system needs two memory tiers: short-lived task reflections and longer-lived lessons approved for reuse. It also needs to:
- Keep each customer’s records separate.
- Limit how much memory enters the agent’s context.
- Update or retire outdated and conflicting advice.
- Test success rates, errors, time and total cost against a no-memory baseline.
Stored lessons are guidance - not facts or policy. Persistent memory should move beyond a pilot only when tests show better results and pass checks for outdated guidance and cross-customer data leaks.
::: @figure 
{Reflexion Memory: The Agent Learning Loop}
:::
Store and Retrieve Relevant Lessons
Create Structured Reflection Records
After each attempt, turn the task record into a reusable lesson and keep the raw trace in storage. Use separate fields for tenant, task and attempt IDs, outcome, failure, recommended change, validation status, evidence links, and policy/tool versions.
Hypothetical UK returns workflow, 12 November 2026: A £45 refund for Order #UK-789 encounters a Stripe API v4.2 timeout after 30 seconds, leaving the transaction status unknown. The recommended change is to query provider status using idempotency key
REFUND_45_UK789before retrying. Store the feedback and outcome intrace_id_9912_raw.jsonin the secure tenant bucket, alongside Stripe API v4.2 and Returns Policy v3.1, effective 1 November 2026. Record the validation status as Verified by System Auditor, without treating that as confirmation that the refund succeeded.
These fields let later attempts trace the lesson back to the exact policy and tool state that produced it.
Filter, Rank and Select Lessons
Apply tenant and access filters before ranking. Check whether the policy applies and whether results have been verified. Then rank eligible lessons by task match, recency and evidence strength - not semantic similarity alone.
Remove duplicates and set a relevance threshold, maximum lesson count and token budget. Treat retrieved text as supporting evidence only: it cannot override current policies or task requirements.
Choose a Memory Format
Choose the format based on what the next attempt needs. There’s no need to retrieve the full history every time.
| Memory format | Purpose | Retrieval cost | Context usage | Update method | Persistence | Main risk |
|---|---|---|---|---|---|---|
| Raw transcripts | Accountability and audit | High | High (token-heavy) | Append-only | Long-term (external) | Privacy exposure |
| Episodic reflections | Recover a specific task | Moderate | Moderate | Checkpoint/snapshot | Task duration | Stale context |
| Summarised lessons | Reuse concise guidance | Low | Low | Merge/deduplicate | Long-term | Over-generalisation |
| Procedural rules | Enforce approved policy | Very low | Minimal | Human review | Permanent | Rigidity/obsolescence |
Use the smallest format that carries the right lesson into the next attempt. A compact reflection works when the outcome is clear; retrieve the evidence only when the result is disputed or unverified. A reflection may propose a rule change, but only human review can promote it to policy.
As new results arrive, the next step is to update, retire or reinforce the lesson.
Update Lessons Within Context Limits
Reinforce, Revise or Retire Lessons
Once you store a lesson, check whether it improves the next attempt. Treat each reflection as a hypothesis, not a fact. Run the agent, then compare its behaviour and deliverables against a reference run - not a static answer key [1]. Reinforce lessons that the results support, hold conflicting ones for review, and test those that remain uncertain.
Archive lessons when changes to workflows or tools make their assumptions invalid. Keep superseded versions out of active retrieval so the agent uses guidance for the current policy or tool version.
Resolve Outdated and Conflicting Lessons
When lessons conflict, check their versions to decide which stays active. Outdated guidance wasn't necessarily wrong when it was written. Use review dates, expiry rules, and policy or tool version checks to separate expired guidance from weak or incorrect advice.
Flag contradictory recommendations for revalidation. If you can't resolve a conflict, keep the disputed guidance out of active retrieval and escalate it.
Measure Results Within a Token Budget
Keep archived lessons in persistent storage, but load only the few needed for the task into working context. Space is limited: each lesson must earn its context cost. Version the prompt, memory-selection rules and tool guidance together so you can reproduce comparisons [1].
Compare each run against a reference run. When calculating cost per successful task, include the full cost of every attempt.
| Measure | Without reflections | With reflections |
|---|---|---|
| Task success | Successful tasks ÷ tasks tested | Same calculation on the comparison runs |
| Retrieval precision | Not applicable | Relevant retrieved lessons ÷ lessons retrieved |
| Regressions | Tasks previously passed but now failed | Same check |
| Contradictions | Runs containing conflicting guidance | Same check |
| Latency | Task duration | Same measure, including retrieval time |
| Token overhead | Total tokens across all attempts | Total tokens, with reflection-related tokens reported separately |
| Cost per successful task | Total measured spend in £ ÷ successful tasks | Same calculation, including memory costs |
Keep Customer Memories Separate
Enforce Tenant Boundaries on Every Action
Context limits keep memory small; tenant boundaries keep it isolated. Choose one tenant boundary - organisation, account or user - and apply it across storage, retrieval, updates, export, deletion, indexes, caches and audit logs.
Build a Two-Tier Memory System
Use short-lived episodic reflections for task-level learning and longer-lived lessons for reuse [1]. Promote reflections only after review, and keep them within their original tenant scope.
Apply these controls to every write, read, revision and deletion path.
| Action | Input validation | Audit record requirements |
|---|---|---|
| Write | Schema check, tenant ID verification | Timestamp, actor ID, policy version |
| Retrieve | Scope matching, validity date check | Query parameters, records accessed |
| Revise | Version conflict check (fencing tokens) | Previous version ID, reason for change |
| Archive or delete | Retention policy trigger, legal hold check | Approval ID, deletion confirmation |
Set Controls for Memory Changes and Access
Limit who can read, edit or promote reflections. Require approval before promotion.
Conclusion: Reflexion Memory Checklist
Check Readiness Before Deployment
A reusable lesson must be relevant, validated, current and tenant-isolated. Before enabling persistent memory, check that tenant boundaries and token budgets are enforced.
Both cross-tenant retrieval tests and expired-lesson tests must pass before deployment.
Expand Only After Measured Improvement
Once the checklist passes, test the memory loop in a sandbox using non-sensitive data in a network-restricted environment [1]. Define permitted tasks, update permissions, token budgets and rollback criteria before testing.
Compare results with the no-memory baseline. Move persistence beyond the pilot only when outcomes improve and both stale-lesson and cross-tenant leakage checks pass.
Before production, confirm test coverage, user exposure limits, support ownership and failure thresholds [2].
Self-Reflection for AI Agents: Reflexion and Self-Critique | NVIDIA Agentic AI Course 3.5
FAQs
How can I tell whether a reflection is worth storing?
Store reflections that are verified and useful for future tasks: validated inputs, confirmed decisions or proven outcomes. These records should help with later work without repeating tasks already completed. Check for duplicates, use metadata to record each item’s source and reliability, and queue conflicting information for review instead of treating it as fact.
Exclude raw credentials, sensitive personal data and excessive reasoning traces. Keep each customer’s records separate, with clear retention policies that comply with UK data-protection regulations.
How should I choose a memory token budget?
Balance task needs with cost control. Enforce hard token limits before every model or tool call, and track total token usage for each task. Once the token budget is reached, the agent must stop before making any further model calls.
Apply token limits as strictly as time limits and cost limits in pounds (£). Hokstad Consulting can help define these memory policies and implementation briefs to keep agent costs predictable.
How can I test for cross-customer memory leaks?
Check that workflows are isolated by tenant, with no memory or state shared between customers’ runs [1]. Verify that identity reconciliation keeps different users and accounts separate [2].
Test mismatched identities, such as unlinked web and email sessions. Confirm that neither session exposes another customer’s private information or context. Also check that your architecture maintains data boundaries through external, centralised stores, rather than local session storage [2].