Claude Fable 5 Quality Is Bottlenecked by Your Unknowns: A Walkthrough of Anthropic's Field Guide
Introduction
On July 6, 2026, Anthropic published "A field guide to Claude Fable 5: Finding your unknowns" on its official blog, written by Thariq Shihipar, a member of technical staff.
Claude Fable 5 is Anthropic's latest model built for long-horizon agentic work, where the AI works autonomously rather than waiting for step-by-step instructions. Shihipar calls it "the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns." In other words, the ceiling is no longer the model's capability but how well the user handles what they don't know.
This article walks through the guide's core framing and all eight prompt patterns, with the example prompts quoted from the original.
Key takeaways
- The gap between your instructions (the map) and reality (the territory) is what the guide calls "unknowns," and you can ask Claude to help find them
- Unknowns fall into four categories, from known knowns to unknown unknowns, each calling for a different prompt pattern
- Brainstorms, interviews, and prototypes are cheap ways to discover unknowns before they become expensive to fix
The Map, the Territory, and Your Unknowns
"The map is not the territory" is a maxim coined by the scholar Alfred Korzybski in the 1930s: never confuse a representation of a thing with the thing itself. The guide borrows this frame. The map is everything you hand Claude, meaning prompts, skills, and context. The territory is where the work actually happens: the codebase, the real world, and its actual constraints.
The gap between the two is what Shihipar calls unknowns. Every time Claude hits an unknown, it has to make a decision based on its best guess of what you want. The more work you delegate, the more unknowns it will run into.
Planning ahead is not always enough, the guide argues. You can find unknowns deep in implementation, and sometimes an unknown reveals that you should be solving the problem in a different way altogether. That is why Shihipar treats working with Fable as an iterative process of discovering unknowns before, during, and after implementation.
Why Four Categories of Unknowns?
Because each category calls for a different response. When bringing a problem to Claude, the guide breaks it down four ways:
- Known Knowns: what is in your prompt; what you told the agent you want
- Known Unknowns: what you haven't figured out yet, and you know it
- Unknown Knowns: what is so obvious you would never write it down, but you would recognize it if you saw it
- Unknown Unknowns: what you haven't considered at all, including how good the result could even be
This taxonomy became famous through Donald Rumsfeld's 2002 press briefing, and the guide applies it to agentic coding.
The guide points to Boris Cherny, creator of Claude Code, and Jarred Sumner, creator of Bun, as examples of the best agentic coders. Watching them prompt, Shihipar writes, it is obvious they know what they want in detail, deeply in sync with both the codebase and the model's behaviors. Yet even they assume unknowns will remain. Reducing and planning for your unknowns, the guide argues, is the skill of agentic coding.
There is also a balance in how specific to be. Too specific, and Claude follows your instructions even when a pivot would be better. Too vague, and Claude falls back on industry best practices that may not fit your task. Both failures come from not accounting for your unknowns.
Five Pre-implementation Patterns
The heart of the guide is five patterns to run before implementation. Each is a cheap way to surface unknowns while they are still cheap to act on.
1. Blind Spot Pass
In an unfamiliar area you carry many unknown unknowns: you may not know what questions to ask, what good looks like, or what potholes to avoid. The guide recommends using the literal words "blind spot pass" and "unknown unknowns," and giving Claude context on who you are and what you know.
I'm working on adding a new auth provider but I know nothing about the auth modules
in this codebase. Can you do a blind spot pass to help me figure out my relevant
unknown unknowns and help me prompt you better.2. Brainstorms and Prototypes
This pattern targets unknown knowns, the criteria you only know how to define once you see them. Small changes in a spec can produce drastically different implementations, so finding these during implementation is comparatively expensive.
I want a dashboard for this data but I have no visual taste and don't know what's
possible. Make me an HTML page with 4 wildly different design directions so I can
react to them.Here's my rough problem: users churn after onboarding. Search the codebase and
brainstorm 10 places we could intervene, from cheapest to most ambitious. I'll tell
you which ones resonate.Shihipar starts almost every coding session with an exploration or brainstorming phase. Claude often finds high-value approaches he would have missed, and sometimes misses the forest for the trees, so the exercise keeps the scope neither too narrow nor too wide.
3. Interviews
Whatever ambiguity survives the brainstorm, you resolve by having Claude ask the questions.
Interview me one question at a time about anything ambiguous, prioritize questions
where my answer would change the architecture.4. References
When you cannot describe what you want in words, hand over the real thing. Diagrams, documentation, and pictures all work, but the guide names source code as the absolute best reference, even in a different language.
This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want.
Read it and reimplement the same semantics in our TypeScript API client.5. Implementation Plans
Before implementing, have Claude write a plan that leads with the decisions most likely to change.
Write an implementation plan in HTML, but lead with the decisions I'm most likely to
tweak with: data model changes, new type interfaces, and anything user-facing. Bury
the mechanical refactoring at the bottom, I trust you on that part.What About During and After Implementation?
During implementation, have the agent keep a record of its judgment calls. No matter how much planning you do, unknown unknowns are always lurking, and the agent may need to take a different tack because of an edge case it found in the code.
Keep an implementation-notes.md file. If you hit an edge case that forces you to
deviate from the plan, pick the conservative option, log it under 'Deviations', and
keep going.After implementation, the guide offers two patterns. The first is pitches and explainers. Reviewers usually start with the same unknowns you did, so a document that answers those unknowns accelerates both understanding and approvals.
Package the prototype, the spec, and the implementation notes into a single doc I can
drop in Slack to get buy-in. Lead with the demo GIF.The second is quizzes. After a long session, Claude may have accomplished more than you realized, and reading diffs alone gives only a light understanding.
I want to make sure I understand everything that's happened in this change. Give me
a HTML report on the changes for me to read and understand with context, intuition,
what was done, etc. and a quiz at the bottom on the changes that I must pass.Shihipar merges only after passing the quiz perfectly.
Does This Work Outside of Code? The Fable Launch Video
Yes, and the guide's closing example is video editing rather than software. The launch video for Fable 5 was edited end-to-end using Claude Code, in a domain where Shihipar is by no means an expert.
He started with what he did know. Knowing Claude could edit and transcribe video with code, he first asked it to explain how transcription tools like Whisper work, and whether ffmpeg could accurately cut out filler words and long pauses. Unsure whether an on-screen UI timed to his speech was even possible, he had Claude build a prototype video with Remotion, a programmatic video library, to find out.
The color grading anecdote is the most instructive. His first attempt was to generate a few variations and pick one, until he realized he did not know what "good" looked like in color grading. So he changed course and asked Claude to teach him the fundamentals instead. Before choosing between options, he built the eye to choose with.
What This Means in Practice
The following is our own reading at ZenChAIne, beyond what the guide states.
Discovering unknowns is work that traditional software contracting has long priced under the name of requirements definition: rounds of interviews, surfacing undecided points, freezing them into documents. The guide's patterns collapse the cost of one lap of that exploration to a few minutes of prompting, and the interview pattern reverses the roles, with the AI asking and the human answering.
At the same time, mapping the four categories onto a real organization shows where the limit is. Many unknown unknowns hide in tacit knowledge: internal conventions, the history behind past incidents, constraints between departments that were never written down. Claude can search a repository and the web at high speed, but it cannot find what exists nowhere in writing. Writing tacit knowledge down into files like CLAUDE.md and skills is the precondition for a blind spot pass to work, a topic we covered in our article on agent readiness in practice.
The color grading episode also suggests an order of adoption. For decisions where you cannot yet judge the output, asking the AI to teach you first beats asking it for options to choose from.
FAQ
Q. How do I prompt about unknown unknowns if I am not aware of them?
A. Delegate the discovery itself. The guide recommends literally writing "do a blind spot pass" or "help me find my unknown unknowns," along with context about your experience and where you are in your thinking.
Q. Do these patterns require Claude Fable 5?
A. No, they work with any capable model. The guide's point is that the better the model, the more the right approach pays off; with Fable 5's long autonomous sessions, clarifying unknowns effectively becomes the quality ceiling.
Q. Why do long tasks fail even with a solid plan?
A. Because unknown unknowns survive any amount of planning. The guide reads a failed long-horizon task as a signal to spend more time defining unknowns, and recommends implementation notes so that deviations become lessons for the next attempt.
Summary
The guide fits in one sentence: every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn't know, before it gets expensive to fix.
- Unknowns are the gap between the map you give Claude and the territory where the work happens
- Sort them into four categories and attack each with the matching pattern
- Five patterns before implementation, one during, two after
- Read a failed long-horizon task as a sign that unknowns were left undefined
The guide closes with simple advice: start your next project by asking Claude to help you find your unknowns. At ZenChAIne we use this same loop in both our development and our writing, and we help companies adopt it.