The Model Is the Engine, the Harness Is the Car: Fable 5.2's Prompt Guide Has Been Squeezed Into a Ride-Along Tool

NO1ennn posted that Fable 5.2's prompting guide is gold and compressed it into a single prompt. Drop it into Claude Code, and it will make an agent build a harness from scratch: an orchestrator breaks the goal into tasks, each with a completion check; the builder runs at low effort, with a self-contained brief for each task; subagents are used only for parallelism, because each one costs money; reading files, running tests, and safe retries require no approval, while risky actions must be approved; the reviewer looks at the diff, not the summary, and reruns the tests; evals score every change and record the tokens burned. Errors and timeouts are not considered blocking; it diagnoses, retries, switches tools, and keeps going. Original post here.

First, some background. The model is the engine; the harness is the car. An engine sitting on a desk can't take you anywhere. The harness is everything outside the model: context, tools, loops, evals, rules, and human handoffs. The first five let the agent do work; evals tell you whether it can still do it. An eval is a set of repeatable tests that scores the agent each time. In the article NO1ennn cites, the author has 412 evals and runs them every night.

The article's author handed the nightly evals to Viktor, an AI employee who lives in Slack. He wrote six work instructions: run the full suite at 2 a.m. every night; read every failed run; compare with last night; send a report before 8 a.m.; attach a PR to each regression; do not merge or change anything yourself. The last one is the most important. He repeated the original line: do not merge or change anything on your own. Three PRs sat at Waiting for approval until he opened them. Original article here.

The first report's numbers: 412 runs completed, pass rate 88.6%, down 2.4 points from last night. Three new regressions. refund_multistep fell from 0.91 to 0.74 because, after a prompt change to the tool rules that afternoon, the agent began skipping the order lookup before refunds. PR #128 restores the rule and adds 6 tests. invoice_extract went from 0.95 to 0.87: invoice totals in two currencies were parsed incorrectly, and 11 of 64 cases failed on the same field. PR #129 passes the currency to the parsing tool and scores each total separately. calendar_reschedule went from 0.88 to 0.79: the timezone was lost when a meeting crossed days, affecting only users outside UTC. PR #130 preserves the user's timezone and adds 4 cross-day cases. Two flaky tests were flagged separately and not force-fixed: web_search_summary passed three out of five reruns, with external pages timing out; pdf_table_read gave two scores for the same input, and the scorer needs a fixed seed. The second is a harness problem, not an agent problem. Two also improved: email_triage from 0.82 to 0.90, crm_update from 0.86 to 0.89, with no regressions for 7 consecutive nights. At the bottom of the report: run again tonight at 2:00; approved fixes go into tonight's suite; unapproved PRs stay open and will appear again in tomorrow's report.

This practice lines up with Anthropic's Fable 5.2 prompting guide. The guide says effort should be chosen by task: low is good for fast, well-defined, highly parallel subtasks; medium is for everyday work; high is for difficult coding and long unattended runs; xhigh and max are reserved for the hardest tasks. Subagents drive up cost, so descriptions should state the cost first and then when delegation is worth it. Approval rules must clearly state which actions they cover; otherwise the model will follow them literally and may block routine requests that should go through. The code-ownership line makes the model more proactive about merging duplicate code and fixing nearby issues, but it also increases output tokens and the number of changes. Cautions also pile up: leftover 'never do this' instructions in memory, notes, and instruction files make the model overly cautious, to the point where it won't even retry. The guide recommends deleting cautions you no longer need and writing exceptions into the rules themselves. Reports should be written for low-context readers, with the conclusion in the first few sentences. These practices are unglamorous, but they are all engineering constraints. The guide is in the Anthropic docs.

The counterintuitive part is that everyone watches the model version, while what really determines whether an agent is usable is the harness and evals. Evals expire because the agent changes every day. Change one prompt in the afternoon to fix one workflow, and another workflow may quietly get worse. Nothing crashes, no error is thrown; the score just slides down. The first person to notice is usually the user. The author says that on his busiest days he changes the agent the most and is also most likely to skip running evals. The days with the highest risk get the fewest checks.

In Viktor's case, the permission design is the most worth studying. It can read, compare, diagnose, and draft PRs, but it cannot merge. Every important action waits for a human to click approve. The original article is sponsored content for Viktor, with promo links and discount codes in the original. This boundary is worth copying: the agent can prepare everything but cannot push it through itself. The word autonomous still has 'not unsupervised' in front of it.

Fable 5.2's release information is also here. AGTP's post lists the numbers: up to 30% faster than Fable 5.1, with pricing cut from $10 per million input tokens and $50 per million output tokens to $8 and $40; on FrontierCode 2.0, High effort is roughly equivalent to Opus 5.5 Max at about half the cost; Xhigh is the highest among released models; 1,000 Fable 5.2 agents formalized Fermat's Last Theorem in 30 hours, while Opus 5.5 with the same setup completed only 26% in 18 hours. Anthropic still recommends starting most coding and knowledge work with Opus 5.5. Fable and Mythos are the same underlying model; Fable has stronger safeguards, and Mythos is only given to vetted organizations. The post is here.

If you're going to get to work tonight, don't start by looking for a magic prompt. Write down three things: when this eval suite runs, what the report looks like, and which actions must wait for human approval. Then let the agent run. After it runs, read the failed runs and do not draw conclusions from the pass rate alone. The human's place is in front of the approve button.