The Cost of a False Positive vs. a False Negative, by Vertical: How Error Asymmetry Decides Where Agents Get Deployed

Table of Contents

• Why "Accuracy" Hides the Decision That Actually Matters
• Defining the Two Errors in an Agentic Context
• The Cost Asymmetry, Vertical by Vertical
• Fraud and Payments: False Positives Bleed You Slowly
• Healthcare and Clinical Triage: The False Negative Is the Catastrophe
• Legal and Compliance: Both Errors Are Expensive, Differently
• Customer Support: Cheap Errors, Volume Problem
• Sales and Outbound: The Reputation Tax
• Code Generation: The Silent False Negative
• How Error Asymmetry Should Reshape Your Threshold
• What This Means for GaaS Pricing and Contracts
• Insights Most People Overlook
• References

Why "Accuracy" Hides the Decision That Actually Matters

Spend ten minutes on any agent vendor's homepage and you'll see a number: 94% accurate, 97% task success, "9 out of 10 resolved autonomously." It looks reassuring. It's also nearly useless on its own, because it averages together two failure modes that have nothing in common except that they're both wrong.

Imagine two agents that each get 5% of cases wrong. The first one, when it errs, refuses to act, it kicks the case to a human. The second, when it errs, acts confidently in the wrong direction, it issues the refund, files the document, deletes the record. Same accuracy. Completely different risk profile. In a payments shop the first agent is a minor annoyance and the second is a liability. In an emergency triage line the calculus flips entirely.

This is the part the marketing number erases. Every classification or action an agent takes can fail in two directions, and the two directions almost never cost the same. Statisticians have called this the Type I / Type II distinction for a century. The new wrinkle is that agents don't just predict, they act, and an action is far harder to claw back than a prediction sitting in a dashboard. When an analytics model produces a false positive, someone reads a wrong chart. When an agent produces a false positive, money has already moved.

If you're building or buying a vertical agent, the first question isn't "how accurate is it?" It's "which way does it fail, and what does that direction cost me in this business?"

Defining the Two Errors in an Agentic Context

Let's nail down the vocabulary, because in an agentic setting it drifts from the textbook.

A false positive is when the agent decides a condition is present and acts on it, but the condition wasn't there. The fraud agent blocks a legitimate transaction. The moderation agent removes a clean post. The triage agent flags a healthy patient for escalation. The agent did something, and the something was unwarranted.

A false negative is when the agent decides a condition is absent and stands down, but the condition was there. The fraud agent waves through a stolen card. The compliance agent misses the disclosure that needed filing. The medical agent reassures a patient who actually needed the ER.

Two complications make agents harder than classifiers. First, agents chain steps, so a single false negative early in a workflow can propagate, the agent that fails to detect it needs a tool then never calls the tool, and everything downstream is quietly built on the gap. That's the silent-failure pattern, and it's worth understanding on its own. Second, agents have a third option a classifier doesn't: escalate. A well-designed agent can convert a would-be error into a human handoff, which is why escalation design is one of the highest-leverage reliability moves you can make.

Keep those two definitions straight, because the entire cost analysis below hangs on which direction the agent leans.

The Cost Asymmetry, Vertical by Vertical

Here's the through-line: the optimal error to make is the cheap one to recover from. What's cheap to recover from changes completely depending on the vertical. Walk through six.

Fraud and Payments: False Positives Bleed You Slowly

Fraud is the canonical asymmetry, and most people get the direction backwards. The instinct is that a false negative, letting fraud through, is the expensive error. And the direct loss on a single missed fraudulent transaction is real.

But at scale, false positives often cost more. A blocked legitimate transaction is a "false decline," and the numbers here are brutal: industry estimates have long pegged false declines as costing merchants more in lost revenue and abandoned customers than actual fraud losses, with research cited by payments analysts putting false-decline losses several times higher than the fraud they were trying to stop. A customer whose card gets wrongly declined at checkout doesn't just lose that sale, a meaningful share never come back, and the lifetime-value loss dwarfs the saved fraud amount. The Federal Trade Commission's consumer fraud reporting underscores how high real fraud volume is, but the recovery cost of a false decline is what quietly drains the P&L.

So a fraud agent should usually be tuned to tolerate a slightly higher false-negative rate in exchange for fewer false positives, up to the dollar threshold where a missed fraud becomes catastrophic. Below $200, let marginal cases through. Above $20,000, escalate aggressively. The asymmetry isn't even constant within the vertical; it's a function of transaction size.

Healthcare and Clinical Triage: The False Negative Is the Catastrophe

Flip everything. In clinical triage, a false positive, telling a healthy person to get checked, costs an unnecessary appointment, some anxiety, and a bit of system load. Annoying, recoverable, rarely fatal. A false negative, telling a person with a real emergency that they're fine, can kill someone. There is no recovery from that.

So healthcare agents are deliberately, aggressively biased toward over-referral. The whole field is built around sensitivity over specificity for exactly this reason, and regulators reinforce it: the FDA's framework for AI-enabled medical devices treats the consequences of a missed condition as a primary risk axis. A GaaS vendor selling into healthcare who tunes for "balanced accuracy" has fundamentally misread the assignment. The right metric is "how few true emergencies did we miss," and you accept a flood of false positives to get there.

This is also why pure autonomy is rare in clinical settings, the false-negative cost is so high that a human verification layer is almost always mandatory, not optional.

Legal and Compliance: Both Errors Are Expensive, Differently

Legal is the vertical where neither error is cheap, which makes it genuinely hard.

A false positive in contract review, flagging a clause as risky when it's standard, costs attorney review time and erodes trust in the tool. Multiply across thousands of clauses and you've recreated the alert-fatigue problem that plagues security operations centers: reviewers start ignoring the agent because it cries wolf. A false negative, missing the indemnification clause that actually mattered, can cost a client a lawsuit. Different shape, both expensive.

The practical answer most legal-tech teams land on: tune toward false positives (over-flag), but invest heavily in ranking and explanation so a human can clear the false positives in seconds. The error you can triage quickly is the error you can afford to make more of. This is why golden datasets built from real reviewed contracts matter so much in this vertical, you can't tune the threshold without ground truth.

Customer Support: Cheap Errors, Volume Problem

Support is the forgiving vertical, which is exactly why it was the first beachhead for autonomous agents. A false positive, the agent answers when it should have escalated, usually costs one annoyed customer and a follow-up ticket. A false negative, escalating something the agent could have handled, costs a bit of human time. Both are measured in dollars and minutes, not lawsuits or lives.

The catch is volume. At a million tickets a month, a 2% error rate is 20,000 bad interactions, and the cost isn't per-incident drama but aggregate brand erosion. Here the smart move is to make the false positive visible and reversible: confidence scoring plus an easy "this didn't help, talk to a human" path turns most errors into recoverable ones. The vertical's whole value proposition rests on errors being cheap, so the engineering job is keeping them cheap as you scale.

Sales and Outbound: The Reputation Tax

Sales agents have a peculiar cost structure. A false negative, failing to reach out to a good lead, is an opportunity cost, invisible and easy to ignore. A false positive, the agent sends a confidently wrong, hallucinated, or wildly mistargeted message to a real prospect, carries a reputation tax that compounds. One viral screenshot of an AI agent emailing a prospect by the wrong name, citing a fake case study, or contradicting your own pricing can cost more goodwill than a hundred missed leads.

Because the false-negative cost is invisible and the false-positive cost is public, teams systematically under-weight the false positive until one blows up. The discipline here is to treat outbound false positives as the expensive error even though the spreadsheet suggests otherwise.

Code Generation: The Silent False Negative

Coding agents invert the usual visibility. A false positive, the agent writes code that's obviously broken, is cheap, because tests and compilers catch it immediately. The error announces itself.

The dangerous one is the false negative dressed as success: code that passes the tests you have but is wrong in a way you didn't test for. The agent confidently reports "done," the diff looks plausible, and the bug ships. This is the "did the wrong thing correctly" failure mode, and it's why eval suites for coding agents have to test for unstated requirements, not just the happy path. Here the recoverable error (visible breakage) is the safe one, and the expensive error hides behind a green checkmark.

How Error Asymmetry Should Reshape Your Threshold

Once you accept that the two errors cost different amounts, the engineering follows directly. Every agent that makes a decision has a threshold, explicit (a confidence cutoff) or implicit (how the prompt and tools bias it). Moving that threshold trades one error for the other. You can't reduce both at once past a point; you can only choose which to suffer.

The classic tool for visualizing this tradeoff is the ROC curve and its precision-recall cousin, which plot exactly how false positives rise as you suppress false negatives. But the curve doesn't tell you where to sit on it. That's a business decision, and it requires a number most teams never compute: the dollar cost of each error type in your specific vertical.

Do the arithmetic. Cost of a false positive times its rate, plus cost of a false negative times its rate, equals expected loss. Minimize that, not the error count. In fraud, that math pushes you toward fewer false positives on small transactions. In healthcare, toward near-zero false negatives at any false-positive cost. In support, toward whichever is cheaper to reverse. The threshold isn't a model property, it's an economic one, and it should be set deliberately rather than inherited from whatever the base model happened to do.

And it's not static. As McKinsey and others have noted in surveys of enterprise AI adoption and risk, the cost of an error shifts as deployment scales and as regulatory scrutiny rises. The threshold you set at launch is wrong by year two if you never revisit it. That's an argument for continuous evaluation, not a one-time pre-launch tuning pass.

What This Means for GaaS Pricing and Contracts

This is where error asymmetry stops being an ML detail and becomes a business model question, which is the whole point of the GaaS lens.

If you price per outcome, you're implicitly underwriting the cost of errors. A vendor charging per-resolved-ticket eats the cost of false positives that generate follow-up tickets, which aligns incentives nicely. But a vendor charging per-task who walks away from the consequences of a false negative has mispriced the contract in any vertical where the false negative is the expensive error. Outcome-based pricing only works when the vendor's definition of "outcome" captures the asymmetry, otherwise you've built a machine that optimizes the cheap metric while the expensive errors pile up on the customer's side.

Smart GaaS contracts are starting to encode this directly: different SLAs for different error directions, with healthcare and financial deals specifying false-negative ceilings separately from overall accuracy. Reliability SLAs that only promise an aggregate number are, frankly, the unsophisticated version. The asymmetry belongs in the contract, because that's where the cost actually lands.

The vendors who internalize this build a real moat. Tuning an agent to the correct error asymmetry for a specific vertical, and proving it with vertical-specific evals, is genuinely hard to copy, far harder than matching a capability demo. It's domain knowledge encoded as a threshold, and that's the kind of reliability advantage that compounds.

Insights Most People Overlook

The cheaper error to make is the one that's cheaper to reverse, not the one with the lower direct cost. Teams fixate on the headline loss of a single error and miss that recoverability dominates at scale. A $50 false decline that loses a customer for life is more expensive than a $500 fraud you can chargeback. Optimize for reversibility, not face value.

Invisible errors get systematically under-priced, which inverts the true risk ranking. False negatives in sales (the lead you never contacted) and false positives in code (the bug behind a green test) are dangerous precisely because they don't announce themselves. The error you can see, you'll fix. The error that hides is the one that ships. Any honest cost model has to add a "visibility penalty" to silent errors.

Error asymmetry is the real reason "99% accurate" is a meaningless claim, not because the number is too low, but because it doesn't say which 1% you're getting. Two agents at 99% can differ by 1000x in expected loss depending on error direction. A vendor who quotes accuracy without quoting the error mix is either naive or hiding the asymmetry.

The optimal threshold drifts, so a one-time tuning pass quietly decays into the wrong setting. As transaction sizes change, regulations tighten, or the model underneath gets swapped, the cost-minimizing threshold moves. Most teams set it once and forget it, which means by year two they're optimizing yesterday's economics. Asymmetry tuning is a continuous-evaluation problem, not a launch checklist item.

In multi-step agents, a single early false negative can be more expensive than dozens of false positives because it silently corrupts everything downstream. A false positive usually trips a check somewhere; a false negative that skips a needed tool call leaves no trace and lets the agent build confidently on a missing foundation. Chain length amplifies false-negative cost in a way single-decision cost models completely miss.

References

• Federal Trade Commission, Consumer Protection Data Spotlight
• U.S. Food and Drug Administration, Artificial Intelligence-Enabled Medical Devices
• scikit-learn, Model Evaluation: ROC, Precision and Recall
• McKinsey & Company, The State of AI