Claude Fable, Claude Tag, and Anthropic's Culture — Cat Wu & Thariq Shihipar ft Simon Willison

Fable has just come back online. Simon Willison regained access roughly a minute and a half before taking the stage with Anthropic’s Cat Wu and Thariq Shihipar. The timing makes the opening question immediate: when a new model changes what a coding agent can accomplish, how quickly should you change the work you give it? Claude Fable is the latest step in a transition that began with Claude Code’s introduction alongside Claude 3.7 Sonnet. Willison remembers the coding agent as a bullet point in that launch, in February of the previous year.

Wu remembers reading every permission prompt, frequently rejecting actions, and asking whether Claude had checked particular files. Successive model generations let her step back from that supervision and spend more time deciding what the product experience should be. With Fable, she reports that many of the team’s feature requests can now succeed in one shot.

Shihipar first tried Claude Code around the arrival of Opus 4, an experience compelling enough to make him want to join Anthropic. Now Auto Mode feels so routine that he has almost forgotten the repeated approval clicks. His response is to raise the quality bar: video work must satisfy the brand team’s exacting standards within a couple of hours, or it is not useful. Willison recognizes the same pressure. Engineering can feel harder because the feasible projects are more ambitious, expectations rise, and the thinking left to humans is demanding.

The old product process could spend months interviewing customers, aligning cross-functional teams around a product requirements document, and specifying implementation before writing code. Wu estimates that, in relevant product engineering work, idea-to-build timelines can shrink from six–12 months to perhaps a week. That makes business sense and product taste more valuable: an engineer needs to judge which idea deserves to exist and whether it can improve the business. She explicitly separates infrastructure work, where getting execution details right remains central.

Shihipar’s corresponding change of mind concerns rewrites. Against the caution he associates with The Mythical Man-Month, he is increasingly willing to rewrite a system—provided it has a good test suite. Preparing a rewrite can itself force a team to improve those tests. The existing codebase is a specification, sometimes the only complete specification of all its branching behavior. An agent can use that artifact to produce a different implementation without requiring someone to remember every branch.

His example is Bun’s rewrite in Rust, which he says is already running internally beneath Claude Code. When Willison asks whether it is shipping publicly, the onstage answer establishes internal use; Willison’s later companion article adds a correction that public shipping began June 17. Willison then extends the testing idea: prepare a strong suite, generate three implementations, and compare which best preserves the required behavior. He also finds himself prototyping from his phone during the conference, leaving working starting points to revisit later.

Claude Tag, launched in Slack the previous week, changes the unit of interaction from an individual session to a team conversation. Wu describes three properties:

• Multiplayer collaboration: teammates can join the same conversation and steer work on a pull request.
• Proactive work: a standing instruction can tell Tag to monitor bug reports, prepare fixes, and tag the engineer who last touched the relevant code. The instruction continues for the channel’s lifetime without repeated mentions.
• Team memory: preferences persist across future posts. A channel can ask Tag to investigate outages while leaving warnings alone, and that preference applies to everyone using it there.

Wu reports that the internal version of Claude Tag lands 65% of her product engineering team’s PRs. The scope is that team and its internal version, rather than all of Anthropic. The division of labor she describes is practical:

Tag reduces the need to start a fresh coding session for every bug report that appears after a feature ships.

The same access also makes Tag useful outside engineering. Before the talk, the guests asked it to search Slack for Fable’s release timing. Connected to an event store, it can answer product-metrics questions. For marketing, it can inspect a repository, explain a feature, and produce a recording of itself using that feature. The person asking does not need to know how to clone and navigate the codebase; the agent does.

Wu’s Cowork example shows how a shared session can carry a feature across disciplines:

1. A product manager asks Tag for a first implementation.
2. Tag shares a recording of the result.
3. Design joins the conversation and steers revisions.
4. Engineering finishes the work and takes it to production.

The social rules for steering one session are still developing, but colleagues learn by watching one another. Shihipar sees a quality benefit in that visibility: a vague request such as asking Claude to fix something is exposed to the same peers who will see the result. Public collaboration encourages more deliberate instructions.

Cheaper implementation makes prioritization more consequential. Wu describes a strong dogfooding rule: when an internal need exposes a limitation, fix the product instead of finding another solution. Features first reach Anthropic employees and early customers willing to give blunt feedback. Public release requires meeting internal active-user and retention thresholds, although she does not give their values. This ties polish to the release decision: if the experience drives people away, it has not cleared the bar.

Remote control challenged Wu’s own instincts. It connects a phone or browser to a Claude Code session running in a local CLI. She usually starts simpler tasks directly from mobile in a cloud environment and initially thought people should configure remote development environments instead. Users demonstrated a different preference: leave the laptop powered, open remote-control sessions, lock the screen, and continue working from the couch. The local environment was part of the value. Willison uses exactly that pattern, and the team is now investing in a workflow Wu did not initially understand.

Review responsibility varies with the change. Critical areas, including the system prompt, have code owners whose approval is required. A GitHub review bot examines every PR and often performs most of the review. Complex changes may also arrive with an explanatory artifact that helps another person understand the design. CI/CD, regression tests after failures, and an environment in which Claude can control and test Claude Code provide additional checks.

Wu describes more than six months of investment before some outer-layer changes moved to automated-only review. Core product changes still receive manual review from their owners. The transition began with humans reviewing everything, then narrowed the human requirement for specific files where the team observed automated review catching all the issues under consideration. That was a local basis for expanding trust, not a claim that the reviewer detects every possible defect.

Incident review closes the loop:

1. Identify the PR that caused the incident.
2. Change the reviewer so it can catch that failure.
3. Add the offending PR to an evaluation set.
4. Run future reviewer changes against that set to detect regressions.

Removing a human review requirement therefore depends on accumulated verification infrastructure. It is the result of repeated evidence about particular failure modes, rather than a switch flipped because a new model looks capable.

Willison already trusts Opus 4.8 with a familiar task: write a JSON endpoint that runs a SQL query and returns the result. A new model creates a calibration problem. How does he know it will preserve that reliability? Wu’s answer is the accumulated eval set. Before replacing a model, the team runs the full suite to establish that the new candidate improves on the old one. These include team-specific evaluations and code-review evaluations spanning Anthropic’s repositories. Auto Mode additionally receives internal testing and external red-team environments containing prompt injections and malicious inputs.

Prompt changes pose the same question at a smaller scale. Wu does not claim complete confidence that every tweak improves the product. The starting point is a trusted external evaluation suite, complemented by a larger internal suite. Capability tests give Claude a complete task definition and the codebase, then check whether it makes the right decisions, fixes the bug, and passes the tests.

But correctness alone misses behaviors that make an agent frustrating to use. Telling someone to go to sleep is unwelcome; stopping after two of five requested parts to ask whether to continue defeats the original instruction. The team ranks user feedback and turns recurring problems into behavioral evals. Coverage remains incomplete, but each new case makes a previously subjective complaint something a future change can be checked against.

The product and research teams plan together around longer-horizon work and models that remain honest, harmless, and helpful. Another goal is interpreting fuzzy intent: users should provide clear context, but the model also needs to make reasonable assumptions when instructions are incomplete.

That improved judgment changes the system prompt. Shihipar corrects the idea that the leaner prompt came only from Fable; Opus 4.8 contributed too, and different models now receive different prompts. Some examples useful to older models became constraints on newer ones. Removing them allowed solutions more creative than the examples the team had supplied. The team also replaced some hard prohibitions with context, reducing conflicts between the system prompt, skills, and later user instructions. Those changes were developed through evals.

Verification illustrates the problem with an instruction that is usually right but not always right. A blanket requirement to verify every front-end change can be excessive when the user wants a quick copy-string edit and a test update. A more informative instruction explains why verification matters: checking backend endpoints does not reveal the complete front-end experience. Yet even asking the agent to run the app for large changes introduces a new ambiguity—what counts as large?

Wu’s test for persistent instructions is to imagine how a well-intentioned person could misinterpret them. Scope the wording accurately enough that it remains useful across the situations in which the model receives it. This places more weight on model judgment, which Willison points out is difficult to assume when routing work to cheaper or older models. Wu reports an 80% reduction in system-prompt tokens for the most frontier models; older models retain the full prompt. That reduction concerns the system prompt, not total session tokens or cost.

Could Fable or Opus compensate for Haiku’s weaker judgment by giving it more detailed instructions? Wu thinks that should be possible but says the team lacks precise evaluations or hard data establishing it. Shihipar adds another complication: on a hard problem, a larger model can use fewer tokens than a smaller one. Choosing the cheaper model per token does not settle the cost of completing the task.

Model-authored prompts are already routine in subagent delegation. Willison finds that framing helpful: one Claude instance must tell another what to do. Workflows extend that pattern to orchestrating many subagents, each with a detailed prompt. Shihipar also gives Claude access to the Gemini API for image generation and finds that it writes more thorough image prompts than he does. Wu thinks Claude wrote the workflow tool’s own prompt as well.

For Willison, these prompts are product documentation. He says the published Claude prompts omit tool prompts, while inspecting Claude Code’s prompts requires him to intercept requests with a proxy. Comparing old and new versions reveals changes in capabilities and expected behavior. He asks for deliberate publication of both the prompts and their diffs. Wu records the request, and Shihipar says he still needs to write a detailed explanation of the prompt reduction. Neither exchange establishes that publication has happened.

Adding a tool is not simply adding capability. Shihipar’s AskUserQuestion tool is difficult to evaluate because whether a question helps depends partly on user preference. Early decisions relied heavily on internal use—Anthropic’s antfooding. The overall direction is toward fewer, more general tools, with the task tool cited as a recent example.

For search, Shihipar reports removing dedicated grep and glob tools in favor of native Bash. The underlying operations remain available through shell commands. For example, a repository search can combine filename discovery with a content query:

find src -type f -name '*.ts'
grep -R -n --include='*.ts' 'createSession' src

This illustrates the general tool replacing specialized wrappers; it is not a transcript of a live shell demonstration. Shihipar describes tool design as closer to biology or art than physics: the model’s response to an interface has to be observed.

Wu’s design rule is to keep tool cardinality low and each function distinct enough that Claude can easily choose. A dedicated file-edit tool survives for another reason: the tool call is also a user-interface event. It lets the application deterministically recognize a proposed file change and render an approval view. New users still value that visible control. Wu speculates that experienced Auto Mode users might manage without it, but the dedicated edit tool remains in the system being discussed.

Willison knows the risk of prompt injection yet admits to habitually using YOLO mode, which skips permission checks. He has recently begun defaulting to Auto Mode but wants a better understanding of its protection. Wu says nearly everyone inside Anthropic uses it and describes thousands of evals, external adversarial testing, and fixes for every issue those testers found. When Willison challenges the breadth of the claim, she narrows it: Auto Mode does not catch everything. She reports lower risk than an average human reviewer for categories such as prompt injection and data exfiltration, with supporting public evals still promised at the time of the conversation.

Shihipar describes a Sonnet classifier that examines a proposed tool action together with the conversation and the user’s instructions. The same shell command can deserve different decisions:

The operation alone is insufficient. A persistent blanket permission for git push would lose the distinction between these requests. Auto Mode can instead catch an overeager agent attempting an action the user excluded.

The same mechanism works with sandboxing. When an operation needs to cross a sandbox boundary—for example, to make a network request—Auto Mode assesses whether that request makes sense in context. Wu says it interacts with any permission prompt the user would otherwise see. Anthropic had used it internally since January, working with alignment and safeguards teams before wider rollout. Willison’s remaining requirement is understandable documentation: what does the system protect, and what exposure remains?

Claude Tag uses Auto Mode, which matters because a Slack agent reads material from many people. A customer-feedback channel is also an entry point for hostile instructions. Shihipar cautions against treating a custom AI Slack bot as a trivial integration: its usefulness can expose a broad attack surface. He describes layered defenses, including reinforcement learning against attacks, rather than relying on a single permission check.

Tag can receive its own credentials and act under a separate Claude identity, making its actions easier to inspect and audit without impersonating a user. The shared setting broadens who can influence the agent, so identity and authorization need to remain explicit. Shihipar also mentions probes associated with Fable and connects this work to the challenge of keeping an agent aligned over long periods.

Wu adds trusted devices for remote-control users and credential injection for remote environments. Her example is Datadog: the agent should be able to make an authorized request without holding the real Datadog credential. A proxy supplies the secret when the request goes out. In the teaching example below, the agent presents agent-placeholder; on a matching request to api.datadog.com, the proxy substitutes example-secret. Those token strings illustrate the boundary: the outgoing request changes, while the real credential stays outside the agent’s accessible state.

The conversation turns from permissions to craft. What happens when work that once defined an engineer’s skill becomes a prompt? Shihipar acknowledges the sense of loss. Cat and Boris repeatedly push him to be more ambitious, and he tries to revisit tasks whose apparent difficulty may come from experience with an older model. His example is Jarred’s work on Bun: first the pleasure of hand-writing Zig in an Oakland apartment, later the pleasure of undertaking the Rust rewrite. The new project offers a different scale of challenge.

That response means pursuing projects or skills previously out of reach. Wu describes a related change in product management. Her team’s PMs combine engineering, design, and product work; most were formerly full-time engineers. Their role is to find the gap between a promising idea and a customer receiving it, then close that gap.

• An idea lacks an implementer: build a notebook prototype that makes it tangible enough for an engineer to take toward production.
• A design needs a first pass: start from a comparable page, then bring in someone with stronger attention to detail.
• A growing organization needs coordination: automate discovery of the launch calendar and collect status asynchronously, reducing interruptions. Keep updates about Claude Code, Claude Tag, and Cowork detailed and concise across the internal announcement channels.

Willison’s familiar example of a company with a thousand-item backlog captures why this work keeps expanding: there has rarely been a shortage of useful things people wanted to build.

Shihipar’s most concrete Fable anecdote begins with a delayed conference video. After speaking at the ACM Agentic Conference, he wanted an edited recording to share with his communications team. Instead, he obtained the raw materials: stage footage, a recording of the slide deck, and a separate audio file. He supplied those to Claude along with the HTML deck and asked it to edit them together.

The useful part was how it handled imperfect inputs:

1. Transcribe the recording. Establish what was said across the talk.
2. Detect the contaminated slide feed. An auto-update popup interrupted the deck recording.
3. Reconstruct the slide presentation. Determine which slide belonged at each point and substitute the HTML source for the flawed footage.
4. Track the speaker. Dynamically crop the wide stage video as Shihipar paced, keeping him framed alongside the deck and transcription.

He identifies Fable as the model and describes this initial edit as the result of one good prompt. Animations and graphics came in a subsequent request. FFmpeg and Remotion were among the tools it used; Shihipar’s assessment was that the result was ready to ship.

Asked what still disappoints her, Wu wants better design and UX taste. A detailed behavioral specification usually produces the requested behavior, but padding can be wrong and the interface may lack delight. Familiar application conventions also do not answer every interaction-design question created by frontier AI products. Willison recognizes an Opus aesthetic; Wu identifies the cream-colored look. She wants future models to become thought partners in designing new interactions.

Shihipar wants more engagement with the physical world, including orchestrating scientific experiments. Coding is only one part of that ambition; broader judgment is needed too. Willison brings up the newly launched Claude Science, but Shihipar says he lacks context about it, and Wu identifies it as a partner team’s product. The exchange leaves experiment orchestration as a desired capability rather than an established outcome of that product.

Wu’s cultural recommendation is to work in public company channels. Tag can search across the public channels it can access, so the quality of an answer depends partly on where the organization keeps its context. Shihipar offers a co-founder maxim: “We don't negotiate against ourselves.” Before abandoning an ambitious idea because of a plausible trade-off, try it and require evidence that the trade-off is real. Willison contrasts this with decades of engineering intuition that treats no as the safe default because every feature has a cost.

The personal projects show what becomes worth attempting. Shihipar is building a Street Fighter II-style 2D fighting game starring himself and his friends. Claude Code prompts Gemini and Seedance for visuals and animated material, inspects frames to judge animation quality, and identifies positions such as a character’s fist to produce JSON hitboxes. He has not decided whether to release it, although he offers to share a screenshot.

Wu’s project is a climbing app for recording the routes she and her friends are working on. Workflows also handles research that extends well beyond coding, including travel and team off-site venues. For a climbing trip, it combines direct flights from the group’s different home locations, Mountain Project routes at suitable grades, Airbnb options, and a constraint Wu cares about especially: a short walk from the parking spot to the rock. Those preferences become a custom map instead of a sequence of manual searches through Mountain Project. Willison calls it “Jira for mountain climbing.”

An audience question asks for tools to build eval datasets and observe agent and workflow performance. Wu says Anthropic has considered eval tooling, but she sees the larger constraint in the time and skill required to create high-quality evaluations. The team wants to invest internally and potentially share best practices. Her answer offers no separate observability-tool commitment.

The final question returns to multiplayer memory: should it live in files, or does scaling require a datastore? Shihipar gives a concrete description of the current system. Claude Tag’s memory is channel-specific, shared by Claude instances in that channel. Each instance also has a session, and a session can contribute back to the shared memory. The storage is a Markdown file per channel. Memory experiments continue, but he announces no datastore migration. The shared team behavior described earlier rests on that simple separation between a session’s working context and the channel’s persistent record.