Teaching My AI to Learn from Its Mistakes

An AI assistant that makes mistakes is frustrating. An AI assistant that makes the same mistake twice is unacceptable. But an AI assistant that learns from its mistakes — that gets genuinely better each week — is something worth building.

Since early January, I have been building a personal AI system using Daniel Miessler’s PAI (Personal AI) framework, which runs on top of Anthropic’s Claude Code CLI. PAI is an open-source operating system for AI assistants. It provides a structured algorithm that governs how tasks are observed, planned, built, verified, and learned from. It includes persistent memory across sessions, a skill system for specialized capabilities, hook-based event processing, and behavioral rules called AI Steering Rules that shape how the assistant operates. My AI assistant, SAM (Security Automation and Management), runs on this framework and handles everything from email triage and security assessments to blog post generation and domain management.

In my previous post, I described how I applied management delegation principles to SAM using initiative levels from The One Minute Manager Meets the Monkey. That post was about autonomy: getting SAM to act at the right initiative level instead of pushing every decision back to me.

This post is about a different problem: learning. Specifically, how I built a structured feedback loop that makes SAM’s behavior measurably better over time, using two complementary skills — Root Cause Analysis and Post-Mortem review.

The Problem with AI Mistakes

Large language models do not learn between sessions. Every conversation starts fresh. The model that made an error on Tuesday has no memory of that error on Wednesday. This is a fundamental architectural constraint, and no amount of prompt engineering changes it.

What you can change is the system around the model. PAI maintains persistent memory, behavioral rules, and a library of skills that load into every session. If SAM makes a mistake and I add a steering rule to prevent it, that rule is active in every future session. The model itself has not learned, but the system has.

The question becomes: how do you systematically identify what rules need to exist?

That is where Root Cause Analysis comes in.

From ISO 27001 to AI: The Origin of TRACE

The idea of applying structured root cause analysis to an AI system did not come from the AI world. It came from my work with ISO 27001, the international standard for information security management systems.

ISO 27001 requires organizations to investigate nonconformities — instances where the management system fails to meet its own requirements — and to determine their root causes before implementing corrective actions. The standard is explicit: you do not just fix the symptom. You trace the failure back to its origin, address the root cause, and verify that the correction is effective. This is codified in Clause 10.2, and auditors check for evidence that the process is being followed.

I have spent years helping organizations build and audit these systems. The discipline of structured nonconformity management — categorize the failure, trace the cause, propose a correction, require approval, verify effectiveness — is one of the most valuable practices in ISO 27001. When I started building SAM and noticed the same kinds of recurring failures that plague any complex system, the connection was obvious. If this process works for managing an ISMS, it should work for managing an AI assistant.

So I built TRACE.

The TRACE Framework: Structured Failure Investigation

When SAM makes a significant error — not a typo or a misunderstood instruction, but something that reveals a systemic gap — I invoke a formal Root Cause Analysis using the TRACE framework:

The five-level causal chain is the core of it. When SAM does something wrong, the temptation is to fix the immediate symptom and move on. The TRACE framework forces a deeper investigation. Each “Why?” peels back a layer until you reach the origin point — the deepest actionable cause.

Here is a real example from early February. SAM was creating a bash script and the --help flag did not work. To understand why, you need to know that PAI includes a coding standard document — a detailed specification that defines exactly how scripts should handle argument parsing, help text, error messages, and other conventions. SAM has access to this document in every session. The question was why SAM ignored it.

SYMPTOM: Script --help flag produces no output
↓ Why?
L1: getopts was used for argument parsing
↓ Why?
L2: SAM used general knowledge instead of consulting the coding standard
↓ Why?
L3: No pre-flight check to read SYSTEM docs before specialized work
↓ Why?
L4: The behavioral rule "read documentation first" existed but was not enforced
↓ Why?
ROOT: Text-based rules in steering documents are suggestions, not enforcement

The surface fix would have been simple: replace getopts with the correct pattern from the coding standard. But that addresses only L1. The five-level chain revealed that the real problem was at the bottom: SAM had a behavioral rule telling it to consult the coding standard before writing scripts, but nothing enforced that rule. It was text in a document that SAM could — and did — skip past.

This is a subtle but important distinction. AI Steering Rules in PAI are persistent behavioral directives that load into every session. They tell SAM things like “read the coding standard before creating scripts” or “verify before claiming completion.” But a steering rule is ultimately just a prompt instruction. The model can comply with it, or it can get caught up in the task at hand and skip past it. When the task feels straightforward — “just write a bash script” — the temptation to skip the pre-flight check and rely on general knowledge is strong.

The correction that came out of this RCA operated at two levels. First, a more explicit steering rule: “Before creating scripts or CLIs, read CODINGSTANDARD.md. This is a specification, not a suggestion.” Second, and more importantly, a hook — an event-driven script that fires automatically at specific points in SAM’s workflow. PAI’s hook system can trigger code on events like session start, tool use, or task completion. The new hook watches for script creation activity and flags when the coding standard has not been consulted, turning a text-based suggestion into automated enforcement.

The pattern repeated across other domains. Formatting rules that were being ignored got hooks that validate output. Documentation that was being skipped got pre-flight checks that surface it at the right moment. Each time, the RCA revealed the same root cause — text rules without enforcement — and the correction followed the same shape: make the rule, then build the mechanism that ensures compliance. Over time, the system shifted from relying on SAM’s diligence to relying on structural enforcement.

Categories Tell You Where to Look

Each RCA gets categorized using a standard code. For internal failures (SAM’s own errors), the categories include:

• PSK (Process Skip) — A documented process existed and was not followed
• ASM (Assumption) — Acted on an unvalidated belief instead of checking
• VFG (Verification Gap) — Claimed done without actually testing
• KNG (Knowledge Gap) — Lacked required information
• CTX (Context Loss) — Information lost between sessions

These categories matter because they aggregate. After running twelve RCAs over seven days, I performed a meta-analysis and found that 67% of all failures were Process Skip. Not knowledge gaps. Not assumptions. SAM knew what to do and had documentation for it. It just did not do it.

That single insight reshaped my entire approach. I stopped writing more documentation (SAM already had plenty) and started building automated enforcement — hooks that check behavior at commit time, session start, and task completion. The category data pointed me toward the right class of solution.

Severity and Escalation

Each internal RCA gets a severity rating: LOW, MEDIUM, or HIGH. This is not just bookkeeping. Severity drives escalation rules.

The most powerful escalation mechanism is the Three-Strike Rule. If the same feature accumulates three RCAs, incremental patching stops. The feature is declared architecturally unsound and gets a full redesign review.

This rule exists because of direct experience. In February, the notification system accumulated four RCAs in two days. Each fix addressed a real problem — a missing integration, a race condition, a wrong assumption, a missing fallback — but the fixes kept creating new failures. The system was telling me something that individual bug fixes could not: the architecture itself needed rethinking.

Without the RCA count as a signal, I would have kept patching indefinitely. The Three-Strike Rule converts a qualitative feeling (“this keeps breaking”) into a quantitative trigger for a different class of response.

Cascade Chains: The Most Expensive Pattern

The meta-analysis revealed something I had not expected: failures travel in chains.

Two cascade chains consumed seven of twelve total RCAs. The voice system migration started with one missed file update, which spawned a second RCA for four more files, which spawned a third for 133 additional files across five architectural layers. The notification system followed a similar pattern across four RCAs.

Each link in the chain happened because the previous fix addressed only the immediate layer without scanning for the same issue elsewhere. The insight was simple but powerful: the first fix is the cheapest fix, if you make it thorough. A single grep -r command after the first migration would have prevented five subsequent RCAs.

This led to a concrete rule: after any cross-cutting change, grep the entire codebase for the old pattern before declaring the work complete. Low effort, high prevention value.

The Approval Gate

Every RCA produces a proposed correction, and every correction requires my explicit approval before implementation. This is non-negotiable.

The approval gate exists because corrective actions modify the behavioral rules that govern SAM’s future behavior. A bad correction, applied automatically, could create worse problems than the one it fixes. The correction is presented with its full causal chain and rationale, and I choose from four options: approve, modify, log only, or reject.

In terms of the initiative levels I described previously, RCA investigation runs at Level D — SAM acts autonomously and reports what it found. But implementing the correction runs at Level C — SAM recommends the change with full rationale and waits for my explicit approval before modifying the system. The investigation is delegated. The decision to change process is not. This is the same insurance calibration that applies to any high-consequence action: the monkey stays on SAM’s back for the analysis work, but I own the approval decision.

Post-Mortems: The Broader View

RCA is focused on failures. It asks: what went wrong, and how do we prevent it? But not every learning comes from failure. Some of the most valuable insights come from projects that succeeded but could have gone better, or that revealed patterns worth replicating.

That is where the Post-Mortem skill comes in. It uses a different framework called RECAP:

The critical difference: RCA traces a single failure to its root cause. Post-Mortem reviews the full journey of a project or incident — successes, surprises, and learnings alike.

After completing the migration of my company website from WordPress to Hugo, I ran a Post-Mortem. The migration itself succeeded, but the review surfaced patterns I would not have captured otherwise: which automation steps saved the most time, where manual intervention was still needed, which architectural decisions paid off and which created friction. Those patterns became playbook entries for future migrations.

RCA prevents repeat failures. Post-Mortem captures institutional knowledge. Together, they create a complete learning system.

Beyond SAM: Generalized Skills for Consulting

Both the RCA and Post-Mortem skills are designed to operate in two modes. The examples above describe internal mode, where the target is SAM’s own behavior. But both skills also have an external mode, where the target is a client’s system, process, or infrastructure.

When I conduct a security assessment or incident response engagement for a client, I can invoke the same TRACE framework against their environment. The causal chain, category codes, and report format work identically — the only difference is that the categories shift from SAM-specific codes (Process Skip, Assumption, Context Loss) to general organizational codes (Communication, Process, System, Human, Design). The Post-Mortem skill works the same way: run RECAP against a client project to produce a structured lessons-learned document.

This dual-mode design was intentional. The skills encode a methodology, not just a SAM-specific behavior. The methodology is useful wherever structured analysis is needed — whether I am improving my own AI system or helping a client understand why their pipeline keeps failing.

The Feedback Loop

Here is how the pieces fit together into an iterative refinement cycle:

1. SAM operates using the current set of steering rules, skills, and memory
2. A failure occurs (or a project completes)
3. TRACE or RECAP runs, producing a structured analysis
4. A correction is proposed — a new steering rule, a skill update, an automated check
5. I approve the correction (with modifications if needed)
6. The correction is implemented — the system is now different
7. Return to step 1 with a better system

Each cycle through this loop makes the system meaningfully better. Not theoretically better — demonstrably better, with persistent artifacts that prove the improvement happened.

The persistent artifacts matter. Every RCA produces a report filed in a RETAIN directory. Every correction gets a changelog entry. Every new steering rule is documented with the RCA that motivated it. Six months from now, I can trace any behavioral rule back to the specific failure that created it.

What the Data Shows

After 28 RCAs over roughly five weeks, the pattern is clear:

• The rate of new RCAs has decreased. Early weeks produced clusters of failures. Recent weeks are quieter.
• The severity has shifted. Early RCAs were predominantly HIGH. Recent ones trend toward MEDIUM and LOW — the systemic issues have been addressed, leaving smaller gaps.
• The category distribution has shifted. Process Skip dominated early (67%). Recent failures are more evenly distributed, suggesting that the automated enforcement for process compliance is working.
• Cascade chains have not recurred since implementing the Three-Strike Rule and the grep-before-done practice.

This is not a controlled experiment. I cannot isolate the effect of any single improvement. But the trend is consistent and directional: the system is making fewer mistakes, catching them faster when they occur, and preventing repeat occurrences more reliably.

Lessons for Anyone Building AI Systems

Three principles emerged from this work that I believe apply broadly:

First, the model does not learn, but the system can. If you treat an AI assistant as a standalone model, its mistakes are random and unpreventable. If you treat it as a system with persistent state, behavioral rules, and automated enforcement, you can make it genuinely better over time. The learning lives in the system, not the model.

Second, categories matter more than individual incidents. Any single failure is just a bug to fix. But when you categorize failures and aggregate the data, you see systemic patterns that point to structural improvements. Twelve incidents is noise. Twelve categorized incidents showing 67% Process Skip is a signal that changes your strategy.

Third, the approval gate is essential. It is tempting to let the system self-correct automatically. Resist that temptation. The approval gate ensures that a human evaluates every behavioral change before it takes effect. The cost is a few seconds of review per RCA. The benefit is preventing compounding errors where a bad correction creates a worse problem.

The Broader Pattern

What I have described is not novel in concept. The practice of structured root cause analysis dates back decades in manufacturing, aviation, and healthcare. The TRACE framework draws on established techniques like Five Whys and fishbone diagrams. Post-mortems are standard practice in software engineering and incident response.

What is new is applying these practices to the behavior of an AI assistant, treating the AI system as an operational system that deserves the same rigor we would apply to a production service or a manufacturing line. The AI makes decisions. Those decisions have consequences. When the consequences are bad, you investigate. When you investigate, you improve.

The result is a system that does not just execute tasks but actively gets better at executing them. That is the difference between a tool and a teammate.