Archetype C: Decision Support Agents

The shape of the problem

A human still has to decide. The agent's job is to prepare the case: gather evidence, synthesize it, attach a confidence score to a recommendation. Fraud review, claims adjudication, credit underwriting, prior authorization, contract risk review: this archetype shows up wherever an expensive analyst has to make a high-stakes call, and an AI system can make that analyst faster without making the call for them.

It's also the archetype where harness discipline matters most, because every recommendation has to be defensible. Every claim needs evidence behind it. Every decision could be challenged (by an auditor, a regulator, or a courtroom) months after it was made.

Here's the question worth asking honestly before anything else: what's actually being optimized? It's tempting to answer "AI recommendation accuracy." That's the wrong target. The target is whether the human-plus-AI system decides better and faster than the human alone did. As the override-rate framework below makes concrete, a system where the human agrees with the AI on nearly everything hasn't necessarily succeeded. It may have just trained the human not to look.

A confidence score is a legal promise

When this agent attaches 0.8 confidence to a recommendation, that number is a claim about the world: expect this recommendation to be correct roughly 80% of the time on cases that look like this one. If that claim doesn't hold up empirically, the entire trust model built on top of it breaks, quietly, and usually before anyone notices.

Calibration gets checked monthly, bucket by bucket:

This table is a constructed illustrative example, not a measured result from a real deployment — it demonstrates what an overconfidence signal looks like in the calibration format this lesson describes, not an audited finding from a named organization. Most of this table is fine. Predicted confidence and actual accuracy track within a few points. The 0.7–0.8 bucket is the alarm: the system claimed seventy-to-eighty-percent confidence and was actually right sixty-one percent of the time. That's not a rounding error, it's a structural overconfidence problem, and it has to be caught and corrected (retraining, prompt adjustment, a model change, an investigation into whether the underlying case mix shifted) before more cases process at that confidence level, not after. The harness detects this drift. You do not wait for analysts to complain that the AI has been "feeling off" lately.

This is the exact gap between a research demo and a system fit for production. Shipping "high / medium / low" labels with no probabilities behind them, no calibration check, and no monitoring is sloppy in a low-stakes setting and closer to malpractice in a regulated one. If a regulator asks what "high confidence" means and there's no number with a calibration history behind it, the system doesn't belong in production yet.

The check itself is deliberately boring: deterministic arithmetic against logged outcomes, not a model call, run monthly against every closed case:

def check_calibration(closed_cases: list[dict], drift_threshold: float = 0.1) -> list[str]:
    """closed_cases: [{"confidence": 0.75, "was_correct": True}, ...] for one bucket."""
    alerts = []
    buckets = {"0.9-1.0": [], "0.8-0.9": [], "0.7-0.8": [], "0.5-0.7": [], "<0.5": []}
    for case in closed_cases:
        buckets[bucket_for(case["confidence"])].append(case["was_correct"])

    for label, outcomes in buckets.items():
        if not outcomes:
            continue
        actual_rate = sum(outcomes) / len(outcomes)
        predicted_rate = midpoint_of(label)
        if abs(actual_rate - predicted_rate) > drift_threshold:
            alerts.append(f"{label}: predicted ~{predicted_rate:.0%}, actual {actual_rate:.0%} — recalibrate")
    return alerts

Nothing in this check is clever. That's the point. Calibration drift shouldn't depend on an analyst noticing the AI has been "feeling off." It should trip a threshold on a schedule, the same way the manifest verifier in the harness-engineering lesson trips on a missing source: deterministically, on every run, whether anyone is watching or not.

Where the human gate goes: mostly, everywhere

The cost-of-wrong-versus-cost-of-asking matrix from the previous lesson applies here directly:

Why the same two loop failures are worse here

Trajectory poisoning and the bullied agent were introduced in the harness-engineering lesson as shape-of-the-loop problems, not model problems. Here they're not just present. They're specifically more dangerous, and the reason is calibration and the audit trail.

In research and synthesis, a trajectory-poisoned agent produces bad research; you catch it in human review, and the damage stays contained to one deliverable. In decision support, the audit trail enters the legal record. A poisoned agent doesn't just produce bad work. It produces bad work that can be cited in a filing months later as evidence the system itself was unreliable.

The bullied agent is worse here for a sharper reason: it breaks calibration specifically. An analyst nudges the agent toward softer recommendations across enough cases, and the agent starts capitulating on positions the evidence actually supported. The confidence numbers keep getting reported, but they've quietly stopped meaning what they claim to mean. They've been optimized for analyst satisfaction instead of accuracy. That's not a visible failure. It's a silent one, until the calibration check catches it.

The defenses don't change from lesson four: fresh session per case, no exceptions, no "continue from where you left off"; priority labels on reviewer feedback, with the agent permitted to hold its position when the evidence supports it. But here they're non-negotiable rather than good practice. And calibration monitoring earns a second job in this archetype: it's the tripwire that catches a bullied agent before the regulator does. If the 0.8 confidence band suddenly starts producing 60% accuracy, that's not a model problem. It's a sign someone has been leaning on the agent, and the calibration check is what surfaces it before it becomes a compliance incident.

Evaluating whether this is working

Four metrics matter here, and the headline ones are not about the AI in isolation.

Override rate is the diagnostic that tells you whether the team is actually using the system, as opposed to just tolerating it. Below 5%, humans are rubber-stamping. The harness has failed to prevent automation bias, and the fix is showing more dissenting evidence, not congratulating the team on agreement. Above 40%, the AI's recommendations aren't useful enough to trust, and the fix is improving evidence gathering, not blaming the analysts. Between 10% and 30% is the healthy range: humans are thinking, the AI is helping, and that band is the actual target, not zero.

Cost reality

For a workload of 1,000 cases a day (roughly 50k input and 5k output tokens per case for evidence gathering, plus 10k input and 2k output for case-file synthesis), real Nebius EU pricing across three stacks:

These are Nebius EU prices captured at deck-authoring time, not a live or durable price list — re-check current rates before citing these exact figures.

What this worked example does illustrate honestly is the shape of the economics in this archetype: the unit costs are small relative to loaded analyst time, which is exactly why every bank, insurer, and large hospital network is exploring this archetype. The barrier isn't cost. It's the risk of a catastrophic, undefensible failure, which is precisely what the harness work above exists to prevent.

The same roughly six-times spread between premium and lean stacks that showed up in Archetype A shows up here too. Architecture, how the evidence-gathering and synthesis steps are split across models, matters more than which specific model gets picked for either step.

Failure modes at a glance

The liability-ambiguity row is what regulated industries care about most. The harness has to make one line absolutely clear in the audit trail: the AI gathered evidence and scored a recommendation; the human read it, considered it, and made the decision. The decision belongs to the human, full stop. A harness that blurs that line gives a legal team a reason to block the deployment outright. This is the AI-prepares, human-decides framing, and it has to be provable from the trace, not just asserted in a policy document.

Week one deliverable

By Friday of week one on a decision-support project, five things should exist: a decision-criteria document capturing the explicit criteria analysts use today, including what triggers dissent; an evidence inventory listing every signal or data source an analyst gathers and how to access it; a case-file schema defining the structured format the AI will produce; a baseline measurement (a time-and-motion study on roughly twenty cases done the current way); and a calibration plan describing how confidence numbers will be checked against reality once the system runs.

The baseline measurement is the one teams most often skip, and it's the one that makes the eventual results provable. Without a "before" number, there's no way to demonstrate the AI version actually improved anything. The project's value stays an assertion instead of a measurement. The eleven weeks after week one are building the system to do the same work several times faster than that baseline, with the evidence to prove it.