Eight copy-ready prompts from Anthropic's Mike Krieger and the Every team, plus the full interview transcript behind them. Use this to plan, build, research, verify, and hand off work that runs for hours.
Exclusive interview
Mike Krieger, Instagram cofounder and head of Anthropic Labs, has used Fable 5 for months. In this conversation with Dan Shipper, he explains how he delegates work overnight, plans before building, and verifies what the model ships.
Watch the conversation or download the transcript for your agent. We turned four of Mike's workflows into copy-ready prompts below.
These prompts are based on the workflows Krieger described in the interview. Fill in the brackets, add your context, and give Fable room to work.
Use this when: The task will take hours and can keep moving without your input.
I'm handing you this task to run unsupervised overnight: [describe the task] Done means: [definition of done] Use this context: [repository, documents, access, constraints] Work through the task to completion. If you hit a blocker, do not stop. Use mocks, stubs, or documented assumptions where appropriate. Record each workaround and continue with everything that does not require my decision. By morning, leave me: 1. What you completed 2. What you worked around and why 3. What still needs my decision 4. The evidence that the work functions as intended
Why it works: Fable knows what completion looks like, how much autonomy it has, and what to do when the obvious path breaks.
Use this when: A product or feature needs technical planning and team alignment before implementation.
Before writing code, help me plan [project or feature]. Current context: [what it does, who it serves, and where it runs today] Where it is going: [expected scale, timeline, and release stage] Challenge any infrastructure or abstraction that does not fit this stage. Avoid planning for scale we do not have and avoid shortcuts that will make an imminent release fragile. Work through the tradeoffs with me until we agree on the architecture. Then create one artifact I can share with the team: an HTML page or markdown document with diagrams, the chosen architecture, the alternatives we rejected, and why.
Why it works: The model produces a decision artifact before it produces code, giving humans a clear point to review and align.
Use this when: An agent is changing an interface or workflow that needs more than a passing test.
For every change you make to [application or feature], attach evidence that it works. Exercise the real flows using [staging or test account] and representative data. Capture screenshots of every screen you changed, including error states and edge cases. Record a short video of the main flow. Review your own captures. Scrub through the video and flag broken animations, layout shifts, missing states, and anything a user could encounter that the tests did not cover. Return the test results, screenshot gallery, video, issues you found, and any remaining uncertainty.
Why it works: The agent has to inspect the product a user would see, rather than treating a successful build or test suite as proof of completion.
Use this when: A migration is too large for one pass and needs its own repeatable execution system.
I need [codebase or module] ported from [language A] to [language B] because [reason]. Before starting the port, design the workflow and show it to me in code. The workflow should: 1. Map the existing system and write a specification of its behavior. 2. Translate it module by module. 3. Test each module as it is translated. 4. Run an adversarial review at the end for omissions and behavior changes. 5. Document anything deliberately excluded from the port and why. After I approve the workflow, run it from start to finish. When the port is complete, show me where it improves on the original, where behavior may differ, and which areas deserve the closest human review.
Why it works: Fable builds a process that can survive a long migration, check its own progress, and expose gaps before declaring the port complete.
Live camp · Friday, June 12
We turned four launch-week assignments into reusable prompts for engineering, growth, product, and workflow design.
Use this when: An agent keeps failing, running slowly, or producing expensive, inconsistent work.
Here is a session log from an agent attempting this workflow: [describe workflow] It struggled with: [time, cost, errors, poor outputs, or repeated failures] Analyze where the current tool, skill, or workflow breaks down. Identify the root cause instead of patching the latest symptom. Make a plan. Then build or specify the upgrade and test it against a comparable task. Return: 1. The root cause 2. The change you made 3. The before-and-after result 4. The infrastructure that faster or cheaper models can reuse 5. Any failure you could not resolve
Why it works: The assignment asks Fable to improve the system around the task, leaving behind tools that make future runs cheaper and more reliable.
Use this when: A strategy needs to reconcile customer research, analytics, internal plans, and conflicting assumptions.
Use the attached source pack to analyze [business area, launch, audience, or funnel]. Sources include: [survey data, customer research, analytics dashboards, website context, planning documents, meeting notes, Slack discussions, and internal goals] Our goal is [specific business goal] for [target customer or profile]. Test our assumptions against the evidence. Do not treat internal consensus as fact. Produce: 1. The 10 findings most likely to change how we operate 2. A ranked list of 10 things we should ship, test, or stop doing 3. The evidence behind each recommendation 4. Source conflicts, stale rules, unclear metric definitions, and assumptions that need verification Flag any conclusion that depends heavily on one source or internal rule, and explain how you would verify it before we act.
Why it works: The model receives the sources of truth, a business goal, a required output, and permission to disagree with the existing plan.
Use this when: Feedback is scattered across Slack, support, recordings, customer calls, and production data.
Collect feedback about [product, feature, or workflow] from: [Slack channel, support tickets, screen recordings, screenshots, production logs, customer calls, and meeting notes] Group the feedback into themes. Separate: 1. Changes that are clearly actionable 2. Decisions that require my judgment 3. Requests that conflict with our strategy, user profile, or product direction 4. The evidence supporting each theme Create one coherent plan for the actionable changes. If you have the tools and approval to implement them, make the changes as one batch and check that the fixes do not conflict. Return what changed, what you skipped, what still needs review, and the evidence that the changes work.
Why it works: Fable gets the full feedback trail and a clear boundary between autonomous work and decisions that belong to a person.
Use this when: You can provide the same brief, context, and edge cases you would give a senior engineer.
Build a first working version of [product, website, or tool]. Product specification: [paste specification] Users: [who it serves] Domain context: [terms, workflows, examples, and constraints] Tricky cases: [edge cases] Required behavior: [requirements] Acceptable rough edges: [scope boundaries] Make a plan before you build. Then implement the first version and test it in the environment where it will be used. When you finish, give me: 1. Instructions for trying it 2. The main decisions you made 3. What you left out 4. Test results and other evidence 5. The areas I should review most carefully
Why it works: A complete brief gives Fable room to make implementation decisions while preserving clear boundaries and a useful human review step.
Live camp · Friday, June 12
Join the Every team live this Friday to run these workflows on your own projects—and learn how to get the most out of Fable 5.
Join Fable 5 Camp →
Every
Every is a frontier AI lab for the future of work, trusted by 100,000 builders and operators.
Prompt copied.
We use analytics and advertising tools by default. You can update this anytime.
