Where to put the model.

Your pilot worked. Production doesn't. The team's instinct is that the prompt needs work, or the model needs upgrading, or retrieval needs to get better. It's usually none of those. It's placement.

The failure you're seeing

Here's the shape of it, measured. On τ-bench — a benchmark built specifically to test whether an agent follows domain policy in a customer-service interaction — frontier agents solved under 50% of tasks on a single attempt. But the number that matters for production is pass^8: the probability the agent solves the same task on all eight independent tries. GPT-4o's retail pass^8 fell below 25% (Yao et al.).

Read that carefully. On tasks it can sometimes do, it cannot do them eight times running. A demo is a pass^1 event. Production traffic is pass^k, and users don't retry.

Two more numbers worth having in your head: TheAgentCompany put agents in a simulated company with a code host, chat, docs, and project tracking, gave them 175 real professional tasks, and the best agent finished ~30% autonomously (Xu et al.). OSWorld, on open-ended computer tasks, measured 12.24% against a 72.36% human baseline (Xie et al.).

This is not a prompt problem. A component that cannot repeat itself cannot carry a correctness guarantee — so the guarantee has to live somewhere else.

Why your best people are the ones getting hurt

A 758-consultant Boston Consulting Group field experiment found a jagged frontier: inside AI's capability boundary, consultants completed 12.2% more work, 25.1% faster, at roughly 40% higher quality. Outside it, they performed 19 percentage points worse than colleagues working without AI at all (Dell'Acqua et al.).

Jagged means the boundary isn't visible from inside the task. Putting the model on the default path asks every operator to make that judgment call, continuously, under time pressure — and it lands hardest on your experts. Computer-aided detection reduced the sensitivity of the most discriminating mammography readers on difficult cancers while helping the weaker ones (Povyakalo et al.). Adenoma detection in standard non-AI colonoscopy fell from 28.4% to 22.4% after endoscopists began routine AI use (Budzyń et al.). Lisanne Bainbridge named the mechanism in 1983: unused skills decay, so the human is least prepared exactly when the automation hands control back.

The fix, in one sentence

Put a deterministic check on the default path. Keep the model on what the check can't decide.

Not remove the model. Demote it.

Why demote, not delete

Because everyone who has actually built this kept the model, and got better results than the teams who didn't.

"Deterministic gates do not guarantee task success, but they can deterministically prevent a known class of silent policy-violating writes at the action boundary." — Reddy et al.

That team also published negative controls: gates help where tools are policy-permissive and add little where tools already enforce their own rules. That's a team you can trust.

When is full deletion safe? Two documented cases, and they share something: Intel made formal verification the primary validation vehicle for the Core i7 execution cluster and dropped coverage-driven testing entirely (~20 person-years). CompCert's verified compiler middle end has never produced a wrong-code error across six CPU-years of random testing. Both are fixed, discrete domains where the option space doesn't drift — an execution cluster, a compiler.

A claims workflow is not a compiler. Demote.

The move that unlocks everything: manufacture the check

The question teams ask is "does this decision have a checkable criterion?" — and they get stuck, because usually it doesn't. Wrong question. Ask instead:

"What would I have to constrain about the output for a checkable criterion to exist?"

This is how DeepSeek-R1 got reliable rule-based verification: the model was required to provide the final answer in a specified format, inside a box (Guo et al., Nature, 2025). The task didn't arrive checkable. It was made checkable by restricting what the model was allowed to emit — which turns an unanswerable classification problem into an ordinary design problem.

Practical forms of this:

• Force a schema, then validate it — constrained decoding gives you structural conformance for free.
• Force the model to name which policy rule it's invoking, then check that rule independently.
• Force a bounded enum instead of free text wherever a decision is categorical.
• Force the model to emit its inputs to a decision, and compute the decision yourself.

One caution so you don't overclaim: determinism is not what makes a verifier robust. In the same study, a model-based verifier held at 0.0–1.1% failure across every reward-hacking pattern tested. Robustness is an implementation property — this licenses "use a robust verifier," not "verifiers must be deterministic."

Triage: which of your model calls qualify

Run each call against four conditions. All four, or leave it alone.

(i) Is the option space finite and enumerable — right now? A snapshot property, not a domain property. If the domain were stable, you probably wouldn't have reached for a general model in the first place. A demoted call site can notice its option space has stopped being enumerable; a deleted one can't. That asymmetry is most of the reason to demote.

(ii) Does the correctness rule already exist in writing, predating the model? Statute, published policy, contract, a rate card, an SLA. If you'd have to author the rule from scratch, stop — that's the expensive case, and Brooks settled it in 1986: "the hardest part of the software task is arriving at a complete and consistent specification." You may look at logs to learn which cases arrive — that's the domain of your predicate. The criterion has to come from somewhere other than the model's behavior.

(iii) Can a domain expert ratify the criterion? Treat this as your weakest condition, not your safest. EvalPlus found 18 defects across 11% of HumanEval's 164 human-written ground-truth solutions — ten of them cases where the reference implementation simply implemented the wrong thing — sitting undetected for roughly two years in the most scrutinized code benchmark in the field (Liu et al.). Experts stated the correctness criterion 164 times and were wrong 11% of the time. Get a second ratifier.

(iv) Is the predicate demonstrably non-vacuous? This is the condition everyone skips, and it exists because return true satisfies the other three. Generated verification annotations are frequently "syntactically valid but semantically weak, such as trivially true conditions or overly conservative constraints" (Beg et al. 2026). A green check certifies conformance to the check. Enumerate your option space against the predicate and prove it discriminates.

And one variable that isn't a condition: is anything trying to fool the verifier? Two frontier labs faced identical conditions and made opposite choices — one built two learned judges, one refuses neural reward models entirely. Whatever separates them isn't in the checklist. If your predicate sits where someone benefits from gaming it, budget accordingly.

Where this does not apply

The predictive layer is never authorable. Estimating an unobservable — will this borrower default, is this transaction fraudulent, which ad wins — is irreducibly statistical. No specification determines it because no specification contains it.

What is authorable is the procedural layer wrapped around the estimate: thresholds, notices, audit records, retry semantics, escalation, cost attribution. Credit scoring is the case that forces the split — wrap prediction, don't replace it. If someone on your team is trying to write rules that replace a fraud model, redirect them to the decision logic around the score.

The four commitments

If you do this, do all four. The first three without the fourth is how you get a rule base nobody can maintain.

1. Manufacture adequacy. Constrain the output until a check exists.
2. Demote, never delete — outside fixed discrete domains. Predicate on the default path, model on the residual, differential monitor over live traffic so drift is visible.
3. Prove non-vacuity before trusting a green check.
4. Ship an expiry review and a re-entry path with every predicate. Adequacy decays — rule-based recall measured falling from ~0.95 to ~0.92 as generators got stronger (Huang et al.). Put a date on it and a named owner.

Plus one discipline from Parnas: every predicate ships an explicit declaration of what it doesn't cover.

What could go wrong, honestly

Your rule base could rot. DEC's XCON went from 250 rules in 1979 to over 6,200 by 1987, with roughly half of them changing annually and about four worker-years per year of maintenance forever. Its own team wrote: "It is difficult now to believe R1 will ever be done." If your churn looks like that, the predicate isn't worth building.

Two facts cut the other way. seL4 found re-verification under a fixed specification is "roughly proportional to the size of the change," and one class of change stops happening entirely after verification: implementation bug fixes. And across 171 projects, Menzies et al. "found no evidence for the delayed issue effect" — meaning a wrongly frozen predicate is cheap to unfreeze. That's demotion's main risk, and it appears survivable.

Don't do this for cost. Inference for a fixed capability level fell more than 280-fold in 23 months; nothing amortizes against that. Do it for examinability: a deterministic predicate admits exhaustive enumeration, deterministic replay, and diff review by a named human. A sampled generator admits none of those. That's worth real money in an audited process — but it's a judgment about examination risk, not a regulatory exemption. (If someone tells you a regulator rewards this: the 2026 revised U.S. bank model-risk guidance puts generative AI and theory-free deterministic software both outside its scope, and explicitly obliges no one. There is no regulatory arbitrage here.)

The honest state of the evidence: wrap-and-retain has replicated, statistically significant instances. The full "instrument, specify, replace, delete" cycle has zero documented instances — and formal methods, which is the same mechanism, has had four decades, working tools, and real technical wins without achieving routine adoption. The set of decisions that qualify is a minority of what most teams do. This is about that minority.

Monday morning

1. Pick your highest-volume model call that touches a write.
2. Ask what it would take to constrain its output so a check exists.
3. Find the written rule it's supposed to be following. If there isn't one, pick a different call.
4. Build the check as a read-only gate in front of the write. Log disagreements. Change nothing yet.
5. Run it for two weeks. Look at the disagreements — that's your data on whether the predicate is adequate.
6. Only then move the gate onto the default path, with the model behind it on the residual.

Step 4 is the whole thing. A read-only gate that only logs is free to build, impossible to break, and tells you within a fortnight whether the rest is worth doing.

It's the same instinct behind two things already on this site: Postgres forcing row-level security before a row comes back, rather than trusting application code to remember the filter every time — and a fail-closed publish gate that blocks a push outright rather than asking a model to judge whether it's safe. Deterministic check in front. Judgment retained for what the check can't decide.

Where the numbers come from. This is the field-guide summary of a longer position paper, Demote, Don't Delete — ~7,600 words, ~100 sources, MLA-cited, and openly adversarial to its own earlier draft: twelve claims from that draft are withdrawn outright, and the paper prints the strongest case against itself, unrebutted, before its conclusion. The 2026-dated results cited above (Reddy, Qiu, Huang, Beg) came through delegated research with adversarial fact-checking and are worth confirming against the source papers before you build a business case on them.