Fable 5 Built a Business From One Goal Prompt. The Lesson Is Orchestration.

Nate Herk gave Claude Fable 5 a single goal: start with the open internet and build a complete company package from scratch.

A few hours later, his experiment had a product concept called Counterbrief, a landing page, a working product demo, two launch videos, a founder-style video, market research, a business plan, brand guidelines, logo files, red-team notes, and a recap page linking the whole package.

The headline is fun. The real lesson is more useful: Fable 5 is strongest when you stop treating it like a chat answer machine and start treating it like an orchestrator with a mission, guardrails, phases, critics, workers, and a definition of done.

Video credit: Nate Herk. Nate's public site describes his work as teaching AI agents, automations, and practical AI systems.

Source Note

This post uses the supplied transcript from Nate Herk's video as the primary commentary source, plus official Claude Code and Anthropic docs for /goal, dynamic workflows, subagents, and Fable 5 behavior. I also checked Shopify and Stripe dispute documentation because Nate's generated product idea, Counterbrief, targets chargeback evidence for ecommerce merchants.

Important distinction: Nate's run created a launch package, not a validated business. The product, market, pricing, claims, legal positioning, payments, privacy, integrations, and customer willingness to pay still need human validation.

Link Map

What Happened

Nate's run produced a fictional-but-plausible ecommerce product called Counterbrief. The idea: help Shopify merchants decide whether to fight or fold chargebacks, then assemble evidence into a response package.

The actual artifact set matters more than the product name:

• A landing page with pricing and positioning.
• A product dashboard for disputes and evidence review.
• Two launch videos: one faster product-demo style, one slower voiceover style.
• A founder-style video using Nate's existing avatar and voice tooling.
• Market research and candidate idea files.
• A business plan with ICP, pricing, unit economics, channels, and risks.
• Brand guidelines, logo candidates, exports, and voice notes.
• A red-team pass that attacked the idea and applied fixes.
• A recap HTML page that linked the whole package.

That is not "a company" in the legal or commercial sense. It is a company starter kit. But as a first pass, it compresses a surprising amount of founder busywork into one orchestrated run.

The Goal Prompt Pattern

Nate used /goal and placed the longer instruction set in a file because Claude Code documents a 4,000-character goal condition limit. That is a useful pattern: keep the /goal command short, then point it at a project file with the deeper mission, guardrails, phases, deliverables, and definition of done.

Here is an adapted version of the pattern. This is not Nate's full prompt and not a transcript paste; it is a safer reusable structure.

/goal Read docs/company-builder-goal.md and complete the package it defines.
Do not report done until recap.html proves the definition of done is met.
If blocked by a missing credential, unsafe action, purchase, or irreversible publish step, stop and explain the blocker.

Then the file can carry the real instructions:

# Company Builder Goal

## Mission
Find one painful, underserved business problem using public sources.
Design a small productized business around it.
Build a local launch package a founder could review this month.

## Guardrails
- Spend no money.
- Do not publish publicly.
- Do not invent market claims, stats, legal claims, or customer quotes.
- Verify important facts against public sources.
- Work only with tools and files already authorized in this project.
- Keep a decision log explaining major choices.

## Phases
1. Hunt for pains.
2. Select candidate ideas.
3. Run an idea tournament.
4. Verify the winner.
5. Design the offer and business model.
6. Build the product prototype and landing page.
7. Create launch assets.
8. Red-team the business.
9. Package the recap.

## Definition of done
A reviewer can open recap.html and find:
- the selected problem and evidence;
- the product demo;
- the landing page;
- the launch assets;
- the business plan;
- the red-team notes;
- what is verified and what still needs human validation.

The point is not to micromanage the path. The point is to define the outcome, constraints, and proof requirements clearly enough that the agent can choose its own route.

The Nine Phases

Nate's recap described a nine-phase run. Here is the practical version to copy:

Why Orchestration Mattered

Nate says Fable acted mostly as the manager: plan, delegate, review, and redirect. That matches Anthropic's own Fable prompting guide, which says Fable 5 is stronger at delegation, collaboration, ambiguity handling, and long-horizon autonomy than Opus 4.8.

Claude Code's dynamic workflows docs make the architectural point clearer: a workflow can orchestrate many subagents from a script Claude writes, while subagents isolate context and run parallel work. The business-builder pattern uses that shape naturally:

• Research agents search different source types.
• Verifier agents re-check important claims.
• Judge agents score business ideas.
• Skeptic agents try to kill the top choice.
• Builder agents create product, landing page, brand, and videos.
• The orchestrator decides when work is good enough or needs another pass.

This is why the experiment is interesting. It is not one prompt in the old sense. It is one top-level objective that creates a temporary company-building team.

The Deliverables

The right way to judge a run like this is not "was the landing page pretty?" It is whether the package helps a founder make a decision.

A strong AI-generated business package should include:

• Evidence file: source links, quotes summarized safely, dates, and why the pain is real.
• Decision log: why this idea beat the alternatives.
• ICP: exactly who has the problem and how to reach them.
• Offer: pricing, guarantee logic, onboarding, and delivery promise.
• Prototype: enough product surface to demo the core workflow.
• Landing page: clear problem, before/after, proof plan, call to action.
• Launch assets: scripts, videos, screenshots, social copy, outreach drafts.
• Red-team notes: reasons the idea might fail and what was changed.
• Human validation plan: interviews, waitlist, pre-sell, concierge pilot, or test ad.

Commercial Reality

Counterbrief is a smart example because chargebacks are a real operational pain. Shopify explains that merchants can submit evidence to support a dispute response. Stripe's dispute guidance emphasizes evidence organization, summaries, and clarity. Stripe also has Smart Disputes, which is a market signal that AI-assisted dispute management already exists as a category.

That makes the idea plausible, but not automatically good. Before building a real version, a founder would need to validate:

• How many disputes the target merchant gets per month.
• Whether $19 per approved response is attractive or too cheap to support service costs.
• Whether Shopify, Stripe, or existing tools already cover enough of the job.
• What evidence can legally and reliably be collected.
• Whether merchants want automation, a review queue, or a human-assisted service.
• What data privacy, payment, and platform approval issues exist.
• Whether the product can improve win rate or simply save time.

Nate's own takeaway is healthy: the package got him maybe halfway there. The next run should stress-test the idea harder before polishing the product assets.

How To Adapt This

Use this workflow for serious exploration, not instant company creation.

1. Pick a market you understand enough to judge.
2. Write the goal file with guardrails before launching /goal.
3. Make research and verification separate phases.
4. Require a tournament, not the first idea the model likes.
5. Require at least one skeptic agent per finalist.
6. Build only after the winner survives the red-team pass.
7. Keep all outputs local until reviewed.
8. Ask for a recap page that links every artifact.
9. Run a second goal: "stress-test this business before I spend money."
10. Do customer interviews before buying a domain, writing ads, or integrating payments.

The best use is not "build me a company." It is "compress the messy first 30 hours of research, ideation, prototyping, and packaging so I can make a better human decision."

Guardrails

The most important part of the prompt is not the ambition. It is the constraints.

• No spending: prevent accidental purchases, paid APIs, ads, or subscriptions.
• No public publishing: keep sites, videos, voice, and claims private until reviewed.
• No invented facts: require sources for market claims, stats, competitor notes, and legal language.
• No credential exposure: use only approved tools and never print keys into logs or outputs.
• No legal promises: a product touching chargebacks, finance, medical, security, or legal work needs expert review.
• No fake founder content: avatar and voice clones need explicit permission and should be labeled internally until approved.
• Red-team before build: put market risk ahead of design polish.
• Human review before launch: agents can draft a company kit; they should not autonomously launch a company.

Sources

• Nate Herk: Fable 5 Just Built Me a Business With One Prompt
• Nate Herk on X
• Nate Herk official site
• Claude Code docs: Keep Claude working toward a goal
• Claude Code docs: Orchestrate subagents at scale with dynamic workflows
• Claude Code docs: Subagents in the SDK
• Anthropic docs: Prompting Claude Fable 5
• Anthropic: Claude Fable 5 and Claude Mythos 5
• Anthropic: Redeploying Fable 5
• Shopify Help Center: Responding to chargebacks and inquiries
• Stripe docs: Dispute evidence best practices
• Stripe Radar: Dispute management