In most of this book, a wrong answer costs a little rework. In finance, law, insurance, tax, government, and medicine, a wrong answer costs a lost deal, a lawsuit, a denied treatment, or a fine. This is the part of the long tail where the environment does not merely resist the generic agent playbook — it raises the price of every mistake until the playbook has to change shape.
The tempting story is that these domains need a smarter model. The people building in them tell a different one. A finance-LLM team says its training recipe is general, with requirements that "apply across industries." A finance-benchmark team finds its grounding-failure result reappears, unchanged, in medicine. An insurance team's fixes turn out to be ordinary engineering hygiene. Across the corpus, the practitioners closest to the regulation keep insisting their methods are not special.
That is the chapter's real finding, and it is more useful than the myth it replaces. What these domains change is not the technique but the standard. The methods are the same ones from the earlier chapters — evaluation, retrieval, guardrails, fine-tuning. The error tolerance is near zero. And when the tolerance goes to zero, evaluation and verification stop being a checkpoint you run before launch and become the product itself. The chapter runs in two movements — professional services, then healthcare and care — that argue one thesis from two directions: high stakes turn verification from a nicety into the thing customers actually buy.
Movement A — Professional services
"Trust, but verify" is an architecture, not a slogan
In finance and law, a you cannot trace to a source is worthless, so the systems are built to make every traceable. Mike Conover's team at Brightwave builds a research agent for due diligence and equity research — "a research agent that digests very large corpuses of content in the financial domain," where "you need to spot critical risk factors that would diminish asset performance" #423 — Conover, Brightwave. Two design choices carry the domain. Verification is a separate model call that checks each finding against the source document, not a single-pass self-check, because a model reviewing its own output is "primed to be credulous" about it. And every finding carries a citation and an inspectable audit trail, because a financial analyst needs to see the receipts behind any assertion before acting on it.
The same posture shows up in legal, where the hard part is not the retrieval algorithm but the evaluation around it. At Harvey, most of the engineering effort in enterprise legal RAG goes into eval-driven development rather than fancy retrieval, across a spectrum that runs from expensive expert review to labeled criteria sets to fast automated precision and recall #154 — Qi (Harvey) & She (LanceDB). A real legal query — the applicable regime for a class of covered bonds issued before a specific date under a named EU directive and article — mixes semantic search, date filters, and exact regulation IDs at once. The retrieval is only as good as the eval that proves it retrieved the right law, so the evaluation is where the work goes.
When the ceiling is not enough, the domain pushes you to a trained model
General models are good, and for these domains "good" is the problem. Waseem Alshikh's team at Writer built a finance benchmark that separates two things a model can fail at: whether it answers at all, and whether the answer stays grounded in the supplied context #406 — Alshikh, Writer. On financial tasks the two diverge sharply. Reasoning models almost never refuse; given wrong or irrelevant context, they hallucinate rather than flag the mismatch. Even the best model's combined grounding-plus-answer score tops out around 81% — roughly one in five queries answered confidently wrong under imperfect context. When a confident wrong answer is unbounded in cost, a one-in-five error rate is disqualifying, which is the argument for domain-specific models backed by a full retrieval and guardrail stack rather than a general model alone.
That argument is what motivates teams who actually train. Gradient's Leo Pekelis describes training a finance LLM because, as the talk frames it, financial agents completing "complex workflows like tabular reasoning or sentiment analysis" fail on "the reliability of executing numerous chained" steps — the reliability of the chain, not the cleverness of any single call, is what forces the investment #473 — Pekelis, Gradient. The honest caveat, and it is the chapter's spine: both Alshikh and Pekelis say their findings are general. Writer sees the same grounding failure in a medical benchmark; Pekelis calls his training requirements ones that "apply across industries." So the domain does not supply a new technique. It supplies a standard the technique has to clear, and a stake high enough to justify paying for it.
Sometimes the safest design keeps the model out of the answer
The most conservative verification pattern is to deny the model the dangerous job entirely. Intuit's tax-explanation assistant serves enormous scale — "TurboTax successfully processed 44 million tax returns for tax year 23, and that's really the scale we're going for" — and the central design decision is that the model never calculates a tax number #197 — Singh, Intuit. Every figure comes from a deterministic tax engine; the LLM only explains it; and a separate guardrail model checks each explanation against the real numbers to catch a hallucinated figure before it reaches a taxpayer. In-house tax analysts write the prompts and build the golden evaluation set, because a wrong number is legal liability — the team "focuses heavily on legal and privacy controls." The model is used where it is safe (explanation) and walled off from where it is not (the number).
That is the domain being load-bearing. It is worth showing the case where it is not. AXA's data-innovation lab built a chatbot to explain insurance terms and reports that its real gains came from disciplined evaluation and prompt optimization — building labeled eval sets, modularizing before optimizing, writing custom metrics for German #469 — Morina, AXA. Almost none of that is insurance-specific. The one genuinely domain-forced constraint is data residency: the model runs on an internally hosted platform so customer data never leaves the company's infrastructure. The lesson is not that regulated industries force novel engineering everywhere. It is that they force it in exactly the places where the stakes concentrate — the number, the private data — and leave the rest as ordinary practice.
Compliance and confidentiality are design inputs from day one
For government and other high-compliance buyers, the regulatory stack is not a deployment detail added at the end. It is a gate the system must clear before it can be fielded at all. Mark Myshatyn, an enterprise AI architect at Los Alamos National Laboratory — a lab that has, as he notes, "been doing applied AI/ML for almost 70 years" — describes an agent that read fusion-capsule research and ran real hydrodynamic simulations on 's supercomputers #86 — Myshatyn, Los Alamos. The demo is the easy part. The hard part is the compliance regime any agentic tool must satisfy: NIST 800-53 with its thousand-plus controls, FedRAMP authorization, the DoD's Compliance Security Requirements Guide and its impact levels, CNSSI 1253, and two just-issued OMB memoranda forcing agencies to define AI governance inside a fixed rulemaking window. The standard AI-engineering playbook has no slot for this. Myshatyn's asks to vendors — build for explainability, build for isolation and self-hosting, ship governance artifacts like a software bill of materials, and don't let the federal version lag years behind the commercial one — are a design brief that has to be read before the first line of code, not after.
Confidentiality is the same kind of upstream constraint, and it is where this chapter meets a thread from the inference-economics chapter. There, trust and confidentiality were named as first-class requirements that the industries with the most to spend — healthcare, finance — impose on how and where a model runs. Here that abstraction becomes concrete: AXA's internally hosted platform, Intuit's legal and privacy controls, Los Alamos's demand for isolation and self-hosting for classified work. The requirement is not a property of the model. It is a property of the deployment, and it is decided on day one.
Movement B — Healthcare and care
The value is in the broken back office, not the clinical frontier
The public imagination puts medical AI at the bedside — diagnosis, imaging, the clinical frontier. The money and the failure are somewhere less glamorous. Nathan Wan of Ensemble Health opens on the scale of the problem: "Almost half the hospitals in the country are losing money… and it's not because of the clinical costs. It's because of the broken and manual processes around the revenue cycle" #187 — Wan, Ensemble Health. Most denials are technical registration and data errors, not medical disagreements, so the highest-leverage AI sits in the administrative machinery: correcting data upstream, and drafting appeal letters for clinical denials. Off-the-shelf generative AI "wasn't sufficient" for the appeal task on its own; the team built a custom model and pipeline with its clinical experts, who keep final sign-off, and measures the result as ROI — a reported 40% cut in appeal turnaround and a tracked denial-overturn rate.
The same shape recurs in oncology. Risa Labs automates cancer-care workflows end to end, and the flagship is prior authorization — filing drug authorizations for cancer patients, starting from order intake and eligibility-and-benefits verification #883 — Shankhdhar, Risa Labs. Again the target is the administrative process that decides whether a patient gets a covered drug, not the clinical decision about which drug. In healthcare, the boring back office is where AI both pays and breaks.
At scale, evaluation is the product
When there is no room for error and no time for a human to check every output, the evaluation layer is what earns a customer's trust — so the eval is the product. Anterior built exactly this for prior-authorization decisions: a system "that supports mission-critical decisions like in healthcare where there's no room for error," having "scaled to now serve insurance providers covering 50 million American lives" #446 — Anterior. The motive is compliance, stated plainly: many US healthcare organizations "are being sued right now for using AI automation inappropriately." Human review alone cannot scale — holding review at a fixed ratio means clinician headcount grows linearly with volume — and offline eval sets always lag the edge cases that only appear in live traffic. Anterior's answer is a real-time, reference-free eval layer that scores every case before ground truth exists, and uses that score to decide which scarce cases reach a human.
The definition of "correct" is the domain expert's, not the engineer's, and that is what makes this a domain argument rather than a technique one. At SonderMind, whose mental-health coach has served over a million people, a licensed clinician reviews traced conversations — including indirect, coded language a general filter would miss — and annotates each with an expected observation that an extraction script turns into a test gating every prompt, model, and guardrail change in CI #938 — Reed & Revere, SonderMind. Their design goal is "more correct triggers," not more triggers: general-purpose guardrails were so conservative they had to be turned off on day one, because over-triggering in mental health denies people care. The clinician's judgment lives in the test suite. It is the ground truth the whole system is measured against, and — as the team notes — the pattern is reusable in any high-stakes domain, not just this one.
Where automation stops and the human starts
One talk in the cluster asks the question in its title — can oncology workflows run without human touch — and the honest answer the corpus gives is: not where the cost of error is unbounded. Across both movements, the human stays in the loop through an explicit, staffed escalation path, not a generic error message. Dan Mason's telemedicine support agent makes the boundary architectural #339 — Mason. The agent speaks only from medically approved scripts co-owned by a physician's assistant. A separate self-evaluation scores every outgoing message and deliberately deducts confidence for unusual situations — not because the answer is wrong, but because a human should look — and anything below a 75% threshold is held for human approval. A human's review never raises the score back up, which keeps the audit trail honest. When a case falls outside the script, it escalates through Slack to the physician's assistant; anything requiring genuine medical judgment routes to "call 911, go to your doctor" rather than to the model.
That structure — a confidence gate, a named human on call, a hard stop — is the same one the other high-stakes systems build. Anterior routes low-confidence cases to a stronger model or an on-call clinician #446 — Anterior. Ensemble Health puts a clinical expert's sign-off before any appeal letter reaches a payer #187 — Wan. Brightwave deliberately withholds full autonomy on judgment calls, because the tacit knowledge that decides them — a conversation with management, a portfolio manager's read on a sector — was never digitized into the corpus #423 — Conover. The human is not a fallback bolted on for comfort. The human is where the unbounded risk is parked by design.
The stake is the standard
Read across the two movements and the shared is clear. What makes a domain high-stakes is not that it needs different methods. It is that it sets the error tolerance to zero, and a zero tolerance promotes evaluation and verification from optional to load-bearing. That is why the practitioners keep saying their techniques are general and are still, in the same breath, describing something the earlier chapters did not need: a separate verification call, a deterministic engine walling the model off from the number, a compliance stack read before the first commit, a clinician's judgment compiled into CI, a staffed escalation path for the cases no model should own.
Scale sharpens the same edge. When you serve 44 million tax returns or cover 50 million lives, edge cases stop being rare and become certainties, so the evaluation cannot run once before launch — it has to run continuously in production. Intuit rebuilds its knowledge engine and prompts every year as IRS forms change, and treats even a same-vendor model upgrade as a full re-evaluation event #197 — Singh. Anterior runs its reference-free eval on every live case because the offline set can never keep up #446 — Anterior. In these domains, the eval system is not the thing you build to ship the product. It is the product — the part customers are actually paying for, because it is the part that lets them trust the rest.