fable-loop-design

name	fable-loop-design
description	Use when designing a long-running agent loop, evaluation harness, or multi-session memory system with Fable 5 — covers self-correction loops, verifier sub-agents, and the memory progression pattern.

Fable Loop Design

Overview

Don't prompt and steer Fable 5 directly. Instead, design loops that let Fable self-correct in response to environment feedback and manage its own context. This is the pattern that gets the most out of Mythos-class models.

Two loop types:

1. Self-correction loops — within a session, Fable hillclimbs against a rubric until it passes
2. Memory loops — across sessions, Fable accumulates and distills verified facts so each session starts smarter than the last

---

Loop Type 1: Self-Correction

The pattern

Give Fable a rubric (a file of checkable criteria). Fable runs, collects feedback via the rubric, self-corrects, and repeats until all criteria are satisfied. The loop stops when the rubric passes — not when Fable decides it's done.

Fable runs task
    ↓
Verifier sub-agent grades against rubric (independent context window)
    ↓
Pass? → stop
Fail? → Fable reads feedback, corrects, re-runs

Critical: use a verifier sub-agent, not self-critique

Models have problems with self-critique on their own outputs. A verifier sub-agent outperforms self-critique because grading happens in an independent context window — the grader has no sunk cost in the prior attempt. This is Anthropic's official guidance for Fable 5: "Separate fresh-context verifier sub-agents tend to outperform self-critique" (the Claude model migration guide's long-running-agent recommendations).

// Run loop until rubric passes
let passed = false
let attempt = 0

while (!passed && attempt < maxAttempts) {
  await Agent({
    model: "fable",
    prompt: `Complete the task: <task>. 
             Rubric is at <rubric-path>. 
             Prior feedback (if any): <feedback>.
             Run, then return your output path.`,
  })

  const verdict = await Agent({
    model: "sonnet",   // independent context — not fable grading itself
    prompt: `Grade this output against the rubric at <rubric-path>.
             Output to grade: <output-path>.
             Return: { passed: bool, failed_criteria: string[], feedback: string }`,
    schema: VERDICT_SCHEMA,
  })

  passed = verdict.passed
  feedback = verdict.feedback
  attempt++
}

What makes a good rubric

A rubric is a file of checkable criteria — not vague goals. Each criterion must be verifiable by the grader sub-agent without ambiguity.

# Rubric: <task name>

- [ ] Ran a baseline before making changes
- [ ] Made at least 5 distinct experiments (not scalar-only tweaks)
- [ ] Each experiment includes a hypothesis, result, and decision
- [ ] Final output improves on baseline by measurable metric
- [ ] No experiment repeated a previously-failed approach without a changed premise

Anthropic primitives for this pattern

Primitive	What it gives you
/goal in Claude Code	Sets the direction for a run — the model works toward the stated goal
/loop in Claude Code	Re-runs a prompt or slash command until you stop it; built-in loop harness
Outcomes in Claude Managed Agents	A hosted iterate → grade → revise loop with an independent grader (see below)
Workflow tool	Manual loop with full control over verifier prompt and schema

Use /goal//loop or Outcomes for standard tasks. Use the Workflow tool when you need to control what the verifier sees or how feedback is formatted back to Fable.

Outcomes, concretely (Managed Agents)

Create a normal CMA session, then send a user.define_outcome event — not a session-create field, and don't also send a kickoff user.message:

{
  "type": "user.define_outcome",
  "description": "Build a DCF model for the target company in .xlsx",
  "rubric": { "type": "text", "content": "<markdown of independently gradeable criteria>" },
  "max_iterations": 5
}

• Rubric is required ({type:"text",content} or {type:"file",file_id}) — explicit, gradeable criteria ("CSV has a numeric price column"), never vibes ("data looks good").
• The grader is Anthropic-managed (you don't pick its model); progress arrives as span.outcome_evaluation_start/_ongoing/_end events.
• max_iterations defaults to 3, max 20. Terminal results: satisfied, max_iterations_reached, failed (rubric contradicts the task), interrupted; needs_revision starts another iteration.

Structural vs. scalar experiments

Fable 5 bets on structural changes (architecture, approach) and shows resilience through regressions. Opus 4.7 tends to find one small win and then adjust scalars around it.

Design your rubric and loop to reward structural exploration:

• Require a minimum number of experiments
• Require at least one experiment that changes the approach (not just a constant)
• Allow the loop to run through regressions without stopping early

---

Loop Type 2: Memory (Cross-Session Outer Loop)

The progression

Effective memory use is a progression. Models exit at different stages:

Stage	What happens	Sonnet 4.6	Opus 4.7	Fable 5
Fail	Get something wrong, document it	✓ (exits here)	✓	✓
Investigate	Before moving on, figure out why	rarely	✓	✓
Verify	Turn diagnosis into a checked fact	rarely	sometimes	consistently
Distill	Turn verification into a general rule	rarely	rarely	✓
Consult	Read the rule instead of re-deriving it	rarely	rarely	✓

Sonnet stores failure notes and open guesses. Fable distills verified facts into general rules and then actually reads them.

Designing for the full progression

Prompt Fable to complete all five stages, not just log failures:

After each task attempt:
1. If you failed, document what went wrong and WHY (not just that it failed).
2. Verify your diagnosis — confirm it with a follow-up check before writing it as fact.
3. Write a general rule to memory/rules.md, not a case-specific note.
4. At the start of each new task, READ memory/rules.md before starting.
   Do not re-derive what you've already verified.

Memory structure that works

memory/
  rules.md          # General verified rules (distilled, not raw notes)
  schema.md         # Verified schema facts (e.g., "prc is in cents, confirmed Q12")
  open-questions.md # Things not yet verified — flag as unverified
  failures.md       # Raw failure log — source material, not the output

The key split: rules.md contains only verified, distilled facts. Raw notes go in failures.md and get promoted to rules.md only after verification.

Cross-session setup

In Claude Code, use the auto-memory system (~/.claude/projects/<path>/memory/) or a project-local memory/ directory. For hosted agents, Claude Managed Agents memory stores are the equivalent: a workspace-scoped store mounted into each session's container as a filesystem the agent reads and writes with ordinary file tools, with per-mutation versioning for audit and rollback.

// Each session starts with:
const rules = Read("memory/rules.md")   // consult first

// Each session ends with:
// Fable writes new verified rules → memory/rules.md
// Fable flags open investigations → memory/open-questions.md

---

Choosing the Right Loop

digraph loop_choice {
    "Task type?" [shape=diamond];
    "Single session, clear success criteria" [shape=diamond];
    "Use self-correction loop" [shape=box];
    "Use /loop or Outcomes" [shape=box];
    "Use Workflow tool with verifier sub-agent" [shape=box];
    "Spans multiple sessions" [shape=box];
    "Design memory progression" [shape=box];
    "Combine both" [shape=box];

    "Task type?" -> "Single session, clear success criteria" [label="in-session"];
    "Task type?" -> "Spans multiple sessions" [label="cross-session"];
    "Task type?" -> "Combine both" [label="both"];
    "Single session, clear success criteria" -> "Use /loop or Outcomes" [label="yes — standard task"];
    "Single session, clear success criteria" -> "Use Workflow tool with verifier sub-agent" [label="no — custom grading needed"];
    "Spans multiple sessions" -> "Design memory progression";
    "Combine both" -> "Use self-correction loop";
    "Combine both" -> "Design memory progression";
}

---

Common Mistakes

Mistake	Fix
Letting Fable grade its own output	Always use a separate model in an independent context window as verifier
Rubric criteria that aren't checkable	Every criterion must be falsifiable by the grader — no vague goals
Memory = failure log	Failures are raw material; distilled verified rules are the output
Stopping the loop on first regression	Fable's biggest wins come after regressions — let it push through
Prompting Fable step-by-step	Design the environment (rubric, memory, feedback) and let Fable navigate it
Sonnet-style memory (open guesses)	Require verification before promotion to rules.md; flag unverified items explicitly

---

Quick Reference

Goal	Tool	Key design choice
Self-correction within session	/goal, /loop, Outcomes, Workflow	Rubric file + verifier sub-agent
Cross-session learning	Memory filesystem	Fail → Investigate → Verify → Distill → Consult
Long-running ML/research tasks	Claude Managed Agents + Outcomes	Structural experiment rubric; allow regressions
Code quality hillclimbing	/fable-repo-audit → self-correction loop	Audit findings as rubric criteria

Related Skills

• /fable-orchestrated-feature-dev — Fable as planner; use self-correction loop on the implementer output
• /fable-repo-audit — produces audit findings that can feed directly into a self-correction rubric