The Anti-Fragile Agent: specific "Lessons Learned" vs. RAG

The Concept

Moving Beyond Statelessness

In traditional cloud architecture, statelessness is a virtue. Infrastructure Managers and Stability-Focused Architects rightly prioritize systems that reset to a clean state upon failure. This ensures predictability and eliminates "ghosts in the machine."

However, when we apply this rigorous statelessness to AI Agents, we introduce a significant efficiency gap. We are essentially building a "Junior Developer" that suffers from total amnesia. If your agent makes a SQL syntax error today and you patch it manually, the agent remains unaware of that history. Without context, it is destined to repeat the same error next week unless the system prompt is permanently (and manually) expanded.

To bridge this gap, I advocate for Anti-Fragile Software.

The goal is not just error handling, but error capitalization. When the software encounters an exception, it should record the logic that led to the failure. This creates a system utilizing Recursive Memory: the agent learns like a human employee—by screwing up, taking notes, and referencing those notes before the next attempt.

The Scenario: The SQL Crash

Consider a standard operational scenario involving Supabase infrastructure.

1. An agent is tasked with a complex data retrieval operation.
2. The agent opts for a CTE (Common Table Expression) to organize the query.
3. The Supabase Edge Function throws a Security Exception: Recursive CTEs not allowed.

The Legacy Habit: In a standard workflow, a developer reviews the logs, identifies the platform constraint, and manually updates the system prompt ("Do not use CTEs for this client"). While this offers maximum control, it introduces operational drag. The "Time to Recovery" is measured in human minutes (or hours).

The Agentic Strategy: The agent catches the exception. It analyzes the error message. It refactors the solution (e.g., swapping the CTE for a Subquery). Crucially, it then utilizes a tool called add_learned_lesson to append a specific constraint to its local context: "Do not use CTEs for User-Queries."

On the next execution, the agent injects this agent_memory.md into its context window before generating code. It has effectively patched itself.

The Code

Implementation: The Argument for Text over Vectors

When discussing memory, the industry default is often a Vector Database (RAG). While RAG is excellent for retrieving vast amounts of unstructured documentation, it can be "fuzzy" when dealing with strict operational constraints.

For meta-rules ("Do not use CTEs"), we do not need embeddings; we need explicit instructions.

The Strategic Trade-off: I utilize simple text files (Markdown) over vector stores for this specific layer of memory.

1. Determinism: Text injection is harder for the LLM to ignore than a retrieved embedding.
2. The "Human Review" Safety Net: This is the most critical component. Automated code generation scares stakeholders because of the risk of infinite loops or hallucinated logic. By writing lessons to a simple Markdown file, we maintain a Human-in-the-Loop architecture. A senior engineer can open agent_memory.md, review the lessons learned, and delete any incorrect deductions before they become permanent doctrine.

We are not allowing the agent to rewrite its own source code blindly; we are allowing it to leave "Post-it notes" for its future self.

(CAG - Code Augmented Generation): The implementation logic is intentionally low-fidelity to maintain high observability. The agent simply appends a timestamped lesson to a file, which is then loaded as a System Message during the next initialization.

The Verdict

Compound Interest for Intelligence

This architecture fundamentally changes the trajectory of technical debt. Standard software suffers from entropy—it requires constant maintenance to stay relevant.

With Recursive Memory, the system leverages the concept of Anti-Fragility. Every runtime error translates into a permanent rule that prevents that specific failure mode from recurring. If the agent fails 10 times in development, it enters production with 10 hardened guardrails it didn't have yesterday.

Strategic Recommendation: While rigid pipelines serve a purpose, there is a diminishing return on systems that require manual intervention for every edge case. I advise shifting from static prompt engineering to dynamic context refinement.

The Bottom Line: Do not just build tools that execute commands. Build teammates that accumulate experience.

For a practical implementation of this architecture, including the specific add_learned_lesson tool logic, you can review my Agentic Orchestration Layer Model (see Dominien on GitHub).