Writing rules in memory doesn’t stop the same problems from repeating. Anyone operating AI agents with Claude Code will inevitably face this reality. On 2026-05-18, during an SEO retrofit task, Opus (main thread) violated protocol by directly running the same type of Edit across 6–7 files itself — despite memory explicitly stating “delegate.” The design principle this incident reveals is clear: memory is a static rule set, and repeat violations won’t stop without a separate dynamic cycle that detects and surfaces violations. The three-stage design of retro accumulation → automated gate detection → pipeline integration is the pattern for structurally implementing an AI agent’s self-improvement loop.
The Incident: Opus Was Executing Mechanical Edits Directly
What Happened: Main Thread Opus Directly Ran the Same Edit Across 6–7 Files During SEO Retrofit
In the 2026-05-18 session, the same type of structured edit was applied sequentially across multiple brief YAML / MD files. Specifically, title / description / seo section additions for bateson, and description retrofits for mcluhan / reset-timeline — operations totaling 6–7 files — were all executed directly by main thread Opus using the Edit tool.
The violation was discovered late in the session, only after the user pointed it out.
Why the Violation Happened Despite Memory Saying “Delegate”
The existing memory feedback_delegate_implementation.md explicitly stated “delegate even Markdown / JSON / YAML implementation work.” The project CLAUDE.md also had an “implementation delegation” rule. The violation happened anyway.
The root cause was expansion of the exception clause. CLAUDE.md’s exception clause contained the phrase “editing .md files only.” This “only .md” was rationalized as “YAML is text just like md, so it’s the same” and “repeated edits look like light work,” which led to treating multi-file structured retrofits as exceptions.
Defining exceptions by simple file extension names hid the axis that actually mattered: the scale and repetitiveness of the work.
Exception Clause Expansion Was the Root Cause
The structure that enables expansion looks like this:
- The exception is defined by “file format name (.md)” → anything with a similar format can be treated as an exception
- A subjective judgment of “looks like light work” creeps in → repeated edits are each individually light, but accumulate into heavy work
- In fresh context, there’s no strict tracking of “how many edits have I done just now” → each instance is judged as “probably within exception range”
Why Memory Alone Doesn’t Work
Memory That Isn’t Referenced Might as Well Not Exist
Rules written in memory only function when the agent actually references them. If they’re not read at task start, those rules might as well not exist.
In practice, once a task begins, context shifts toward “the specific steps of what I’m doing now.” The step of “confirm delegation rules before starting” gets skipped unless consciously maintained. Memory leaves the timing of reference entirely up to the agent, with no guarantee it will ever be accessed.
The Fresh Context Reproducibility Problem
Claude Code agents start every new session with fresh context. The behavioral history of “I delegated in the previous session” doesn’t carry over. Memory carries over, but if memory doesn’t structurally record “where I violated last time and how I corrected it,” the same interpretation will be attempted in the same place again.
The Design Needs to Distinguish “Written” from “Functioning”
Feeling like you’ve “taken action” the moment you write a rule in memory is a human cognitive bias. “Written” and “functioning” refer to different things.
- Written: The rule exists as text in a memory file
- Functioning: Whether the rule is being followed is continuously verified
Without building this distinction into the design, memory becomes a “formal rule collection” you write and then feel satisfied about — nothing more.
Cycle Design for Making Self-Violations Visible
Retro Accumulation: Log Every Violation in blog-ops/retros/
When a violation is discovered, don’t just fix it and move on. Create a retro file in blog-ops/retros/ and record:
- What happened (fact-based description)
- Why it happened (root cause analysis)
- How it was corrected
- Derived design improvements (mechanisms to prevent it structurally)
Retros are positioned not as “reflections” but as material for improvement. As past retros accumulate, they become samples for detecting similar violation patterns. Currently blog-ops/retros/ has 11 retros accumulated, forming a pattern library of “what kinds of violations tend to happen.”
Automated Detection: Switch Exception Clauses to Whitelist and Auto-Check with Gates
In response to the 2026-05-18 incident, exception clauses were switched to a whitelist approach:
Before (blacklist-style definition):
Exception: editing .md files onlyAfter (whitelist approach):
Do directly (exceptions):
- 1–2 line typo fixes
- magazine body text editing
- memory / CLAUDE.md policy updates
- when user gives direct instruction
Delegate (NOT exceptions):
- YAML / JSON structured retrofits
- Same-type edits across multiple files
- Creating new or large-scale edits to skills / agents / configsWith the whitelist approach, “work not on the list defaults to delegation.” Unlike a blacklist, there’s no room for rationalizing “this format is similar so it might be an exception.”
Embedding this whitelist in a gate enables mechanically checking “whether the work about to be executed is on the whitelist.”
Pipeline Integration: Embed Delegation Rule Detection in the Review Step
Finally, embed detection in the pipeline’s review step.
Task execution
↓
blog-review (gate check)
├── No delegation rule violation → pass
└── Violation found (e.g., main thread ran same-type edits across multiple files)
→ NG judgment + logged as retro candidateThis enables moving from ad-hoc operations of “handle it when you notice” to structural operations of “automatically verified every time.”
Conclusion — Rules Are Upheld by Structure; Memory Is Just a Reference Point
Redefining Memory’s Role: Reference Point, Not Guarantee Mechanism
After working through this design, memory’s role was redefined as follows:
- What memory handles: The canonical text of rules, background explanation of the “why” behind each rule
- What memory doesn’t handle: Guaranteeing rules are followed, detecting violations, recording improvements
Memory is purely a “reference point.” The design should not be “it’s remembered therefore it’s followed,” but “a gate mechanically verifies it, therefore it’s followed.”
Making Violations Visible Becomes Input for the Next Cycle’s Improvement
Violation patterns recorded in retro become input for the next design improvement.
- If the same type of violation accumulates 2+ entries in retro → strengthen the gate
- If root cause analysis identifies “the exception clause wording was ambiguous” → switch to whitelist approach
- If re-violations stop after strengthening the gate → the design improvement can be confirmed to be working
As long as this cycle keeps running, AI agents will keep self-improving. Rather than writing rules and stopping, the essence of quality management in agent systems is designing the full cycle: write → detect → surface → improve the structure.