🔎 “Done” is a claim—not proof
🧠 Imagine it this way: a contractor calls and says, “I finished the renovation.” You don’t pay without going to the site, inspecting the work, and testing the faucet. With an AI agent, the instinct is the opposite: it writes “done ✅” so confidently that we forget to ask for the same proof we’d ask of a person.
In code, automation, databases, deploys, and documents, Fable 5 may report success even when something failed, was incomplete, or was never actually checked. It’s not bad faith—it’s the model describing what should having happened, rather than what actually happened in the tool.
The risk is higher precisely because Fable 5 is good at sounding confident: a well-written “everything’s fine” report inspires the same confidence as a real report. Without requiring evidence, silent errors turn into accumulated errors—and the cost of finding out late is always higher than the cost of checking early.
📊 What really changes
- Claim — “I’m done,” “working,” “deployed” (text, with no evidence attached)
- Evidence — test run, file changed, log, command output, verifiable result
- Practical rule — “done” only exists when the claim comes with evidence
In one sentence: "done" without evidence is just optimistic text—treat it as a hypothesis, not a fact, until you see the proof.
📋 The verification prompt: require evidence before saying "done"
🎯 The central idea
This is the direct antidote to the problem in topic 1: instead of trusting the report’s confident tone, the prompt requires Fable 5 to do 4 specific things, always in this order:
- •Confirm with real evidence: test, changed file, log, command output
- •If you didn't check, say "not verified" — instead of omitting it or generalizing
- •If it failed, show the failure — don't dress it up as "almost right"
- •If you skipped a step, admit that you skipped it
Notice that the prompt doesn't ask you to "be honest"—a vague request the model already "thinks" it is fulfilling. It defines a audit procedure concrete: every progress claim needs a specific kind of evidence behind it, or it must be labeled as unverified.
Goal: eliminate the generic “done” and make Fable 5 report only what it can prove—explicitly acknowledging what hasn’t been checked instead of sweeping it under the rug.
Before saying something is ready, confirm it with real evidence: a test run, changed file, log, command output, or verifiable result. If it wasn’t verified, say clearly: “not verified.” If it failed, show the failure. If you skipped a step, say so.
How to check: paste this at the beginning of the conversation or into the CLAUDE.md/system prompt for the project. Ask for a task with a verifiable step (run a test, apply a diff, check a log) and read the final report: it should cite the exact evidence ("3 of 3 tests passed, output: ...") instead of "everything works"—and say "not verified" when that's the case, without hedging.
The diamond is the only filter that matters: without real evidence from this session, the right answer is to admit “not verified” — never “it should be working.”
Cross-reference with Track 1
This tip directly echoes the technique "prove it's finished" of the module 1.4 — Let it act + prove it’s done, which is backed by Anthropic’s official documentation. Anthropic measured the effect of this type of instruction:
"In Anthropic's testing, this nearly eliminated fabricated status reports even on tasks designed to elicit them."
Translation: "In Anthropic's tests, this nearly eliminated fabricated status reports, even in tasks deliberately designed to induce them." → see the full module 1.4.
✓ What to DO
- ✓Ask for the exact evidence before accepting any “done”
- ✓Accept "unverified" as a valid answer—it's better than false optimism
✗ What to AVOID
- ✗Trusting “everything works” without a number, log, or attached output
- ✗Letting silence about a skipped step go unchallenged
🎭 A single opinion is a blind spot
🧠 Imagine it this way: a company that makes an important decision by listening only to sales gets it wrong in a different way than one that listens to sales, product, finance, and the skeptical board member at the same time. It’s not that sales is wrong—it’s that one lens alone never sees the whole picture.
When you ask Fable 5 for a generic "analysis," it responds based on a single angle — usually whatever the question itself suggested. If you asked about code, it focuses on code; it rarely connects the dots on its own to market positioning, the user journey, or execution risk, even when those angles are relevant to the actual decision.
The problem isn’t the quality of the answer—it’s the coverage. A product, offer, or campaign decision has at least 4-5 dimensions pulling in different directions; asking for a single answer means asking one of those dimensions to dominate the others without warning.
5 typical perspectives a single answer tends to leave out — topic 4 turns that into a prompt.
A note from someone who uses this every day: asking it to “be more critical” or “look at it from other angles” almost never works—it’s too vague for the model to know which angles. Explicitly naming the roles (next topic) is what actually forces coverage.
In one sentence: a response has only one point of view built in—to truly evaluate an idea, offer, or product, you need to name the perspectives you want to see.
🧭 The council prompt: 5 subagents, 5 lenses, 1 recommendation
Instead of asking for a single opinion, this prompt builds a advice from 5 subagents, each with a fixed specialty, and ends by asking for a consolidated single recommendation with priorities — the opposite of 5 separate reports with no synthesis.
Goal: evaluate ideas, offers, products, projects, or campaigns through multiple specialized lenses at the same time — without any one lens dominating by default.
Use a subagent structure: Agent 1: analyzes strategy and positioning. Agent 2: analyzes the product and user journey. Agent 3: analyzes content and communications. Agent 4: analyzes technology and automation. Agent 5: acts as a skeptic and looks for flaws. Then consolidate everything into a single recommendation with priorities.
How to check: use in <isto voce troca> — replace the object of analysis (idea, offer, product, project, campaign) before pasting. Confirm that the final answer has 5 clearly separated blocks, one per agent, and ends with a consolidation section with priorities — not a loose, unranked list.
Cross-reference with Track 1
The module 1.7 — Bonus: subagents, memory, and send_to_user explains, with official backing from Anthropic, how to delegate technically to subagents (asynchronously, with their own context). This topic here is about what role structure use within this delegation—the two complement each other.
"Claude Fable 5 dispatches parallel subagents more readily than prior models... prefer asynchronous communication between orchestrator and subagents over blocking until each subagent returns."
Translation: "Claude Fable 5 dispatches subagents in parallel more readily than previous models... prefer asynchronous communication between the orchestrator and subagents instead of blocking while waiting for each one to return." → see the full module 1.7.
5 cyan boxes = the 5 specialized agents, each analyzing in parallel. The blue box on the right, with a glow, is the point that completes the prompt: consolidation into a single recommendation.
🤝 The two tips together: advice that brings proof, not just opinion
🧠 Scenario: you’re deciding whether to launch a new pricing plan. Asking the 5 agents only "what do you think?" gets you 5 well-written opinions—but they’re still guesswork. Tip 5 comes in here: each council agent must provide evidence, just like any other claim that something is "done".
Tip 6 gives you the structure (5 perspectives, no blind spots). Tip 5 gives you the rigor (no lens is complete without proof). Together, they become a single rule: each agent on the council must point to concrete evidence before weighing in — not "I think the market responds well," but the data that supports that claim.
Strategy Agent
Analyze positioning vs. the competition.
Required evidence: price/offer benchmark of 3-5 direct competitors, not “I think it’s expensive.”
Product Agent
Analyzes the user journey.
Required evidence: churn, NPS, or funnel data that points out where the new plan helps or hinders.
Communications Agent
Analyzes the value proposition.
Required evidence: A/B test, research, or campaign history — not “this sentence sounds better.”
Technology Agent
Analyze feasibility and automation.
Required evidence: effort estimate and real dependencies of the billing system.
Skeptical Agent
Looks for flaws on purpose.
Required evidence: historical case or risk scenario where a similar change went wrong.
🧾 The consolidation
Only after all 5 agents have brought evidence (not unsupported opinions) does the prompt's final step — "consolidate everything into a single recommendation, with priorities" — become a reliable synthesis. Consolidating 5 guesses still produces a well-organized guess; consolidating 5 pieces of evidence produces a decision.
In one sentence: if a council agent doesn’t provide evidence, it isn’t finished — that’s the same standard as tip 5, now applied to each of the 5 lenses.
⚠️ Common mistakes with these 2 tips — and the quick checklist
The two prompts in this module fail in the same way when only partially applied: they become a show of rigor without truly changing the outcome. The most common mistakes:
⚠️ Where this breaks in practice
- ✗Accept "all good" without asking for the exact evidence again (returning to the blind spot in topic 1)
- ✗Ask only “be more critical” instead of explicitly naming the 5 roles
- ✗Leaving out the Skeptical Agent “so you don’t dampen the enthusiasm”—without it, the advice becomes an optimistic echo chamber
- ✗Consolidating without requiring evidence from each agent—5 opinions become 5 well-formatted guesses
- ✗Run the 5 agents but skip the consolidation step — you end up with 5 separate reports and no priorities
✓ Quick checklist
- ✓Did every claim of "done" come with a test, log, diff, or command output?
- ✓Is there an explicit “not verified” where it couldn’t be checked?
- ✓Does the council have all 5 named roles, including the skeptic?
- ✓Did each agent cite evidence, not just an opinion?
- ✓Is there a final consolidation with priorities—not 5 separate reports?
💡 Ready-to-paste combo
In upcoming sessions, try pasting both prompts from this module (topics 2 and 4) together in the same analysis request, and see whether the final result has 5 blocks with evidence + 1 synthesis—not loose text.
This is literally the example from topic 5, applied to your own project.
In one sentence: verification and advice only work when complete—halfway, both become a performance of rigor instead of actual rigor.
🧾 Module Summary
Next module:
2.4 — Project memory + continue until complete: how to turn decisions into persistent memory and keep Fable 5 from stopping too early on long tasks.