The maker is not the verifier: how I build self-improving agent loops without pretending models self-learn

Introduction

Fable 5 brought Mythos-tier capability back online July 1. Most teams I talk to are still using it like Sonnet with a bigger price tag: prompt harder, ship the answer, forget the run. That is not a system. That is a very expensive autocomplete loop.

I drew the how to actually use Fable 5 note after one too many engagements where "self-improving agent" meant "we added a memory field to the prompt." This post is the architecture behind that infographic: four layers, maker vs verifier, and where loop patterns from the 20 Loop Patterns catalog fit.

Self-learning vs self-improving (the distinction that matters)

When a vendor says "self-improving," ask which column they mean. If the answer is weight updates, they are describing research, not something you can buy on the API this quarter.

The four-layer architecture

1. 01
   Layer 1: Primitives

   Fable 5, sub-agents, MCP tools, the raw capabilities the system reaches for. Most teams stop here. Primitives without orchestration are demos.
2. 02
   Layer 2: Orchestration

   Goal-driven loops reviewed by an independent verifier. The orchestrator decides which primitive runs next, with exit conditions and budgets. See governing agent autonomy for production guardrails.
3. 03
   Layer 3: Memory

   Stores verified facts, learnings, and next steps per run. Skip this and every session restarts from zero. Match memory type to the job: wrong memory, dead agent for the four-type rule.
4. 04
   Layer 4: Self-improvement

   Reviews every output and saves key lessons for the next run. Tomorrow's run inherits today's sharpened system. This is not fine-tuning. It is distilled run logs plus retrieval at the right layer.

The golden rule: maker ≠ verifier

Bad pattern: one agent produces output and grades itself. "Looks good, ship it" is how hallucinated scores and polished-but-wrong content slip through. I see the same failure mode in content QA pipelines and in coding agents that self-approve PRs.

Good pattern: maker agent produces output; verifier agent checks against a rubric until pass or max iterations. The verifier can be a smaller model with a structured checklist, a rules engine, or a human-in-the-loop gate. What matters is independence.

The agentic AI content quality system note shows this split in production: read-only evaluators, write-only rewrite agent, orchestrator that never evaluates. Same architecture, different domain.

The self-improvement loop

• Run: execute the workflow with current primitives and memory.
• Output: capture artifacts, tool calls, and final response.
• Independent review: verifier scores against rubric; log failures with reasons.
• Lesson learned: distill one to three actionable improvements (prompt, tool description, memory entry).
• Next run (better): inject lessons into memory or orchestration config, not into model weights.

Picking loop patterns from the catalog

Improvising a new loop for every workflow is how teams end up with five incompatible agent configs. I keep a pattern catalog (see 20 Loop Patterns) and map workloads to known shapes: sequential pipelines, parallel fan-out, verifier-gated loops, human checkpoint gates, retry-with-backoff on tool failure.

Before you add a second agent, ask whether the workload is sequential (next step needs prior output) or parallel (independent reads). The sequential vs parallel workflow note is the one-page decision rule. Wrong execution flow costs 3x latency or breaks correctness.

Where Fable 5 fits (and where it does not)

Fable 5 belongs in the maker role on long-horizon tasks where cost per completed task wins after safeguard routing. It does not replace the verifier. It does not replace memory design. After the July 7 billing cliff, treat Fable as revocable frontier infrastructure with evals, not as "turn it on everywhere."

Common mistakes

• Calling prompt memory "self-improving" without a review step.
• Same agent as maker and verifier on high-stakes outputs.
• Storing raw chat logs as memory instead of distilled lessons.
• Skipping orchestration and expecting primitives to compound.
• Choosing parallel execution when the next agent needs the previous output.

Conclusion

Mythos-tier models need Mythos-tier habits: orchestration, memory, independent verification, distilled improvement. Prompt harder is Sonnet-tier thinking. Run, log, distill, repeat is how systems compound. Build the four layers, split maker from verifier, pick loop patterns from a catalog. The model can stay the same while the system gets sharper every week.