Agentic AI is only interesting when it can be told no

Our AI claims adjuster tried to settle a claim at $58,000. His authority stops at $50,000. The claims system refused him, raised an approval to a supervisor who could sign it, and wrote down all three facts. That refusal is the most valuable record we keep.

It is also the one almost no agent platform stores, because almost no agent platform is built on the assumption that the agent might be wrong in a way that matters.

We run a specialty property and casualty carrier called Vsure whose staff are AI agents. They handle submissions, quotes, binds, endorsements, premium audits, renewals, first notice of loss, reserves, settlements, closures and reinsurance cessions. They work through the same APIs a human employee uses. It is a real book: 240 insureds, $243M of written premium, 775 claims.

We did not build it to show that agents can do insurance work. We built it to find out what happens when they try to do something they should not be allowed to do.

Autonomy without a refusal path is just an unguarded write

There is a comfortable story about agent safety that goes: put the rules in the system prompt, give the model good tools, and evaluate the outputs. It works right up until the agent can change something that costs money.

The problem is that a prompt is a suggestion. It is text, in the same channel as every other piece of text the model is weighing, competing with a user instruction, a retrieved document, a tool result and the model's own sense of what a helpful assistant would do. Models are good at following prompts. They are not guaranteed to follow prompts, and a guarantee is exactly what you need before you let something post a payment.

A prompt is a suggestion an agent can talk itself out of. A permission check is one it cannot.

So the rule we settled on is simple to state and surprisingly invasive to implement:

Concretely: when our adjuster wants to settle, he does not evaluate his own limit and proceed. He calls the settlement tool. The claims product looks up the actor, looks up the capability, finds the authority level required for a $58,000 settlement, compares it to the level this actor holds, and returns a refusal with a specific shape.

That downgrade_to field is the whole design in one line. The system does not just say no. It tells the agent what it may do instead, so the agent has a legitimate next move that is not "try again with different phrasing".

What actually happens in a run

Here is the sequence for the $58,000 settlement, exactly as it appears in the trace.

sequenceDiagram
    autonumber
    participant A as AI adjuster
CL-DOKAFOR (L2)
    participant H as Agent harness
    participant CW as Claims product
    participant P as Authority policy
    participant S as Supervisor (L3)
    participant L as InsightLense

    A->>H: Reviewed file. Settle at $58,000.
    H->>CW: settle_claim(claim, 58000)
    CW->>P: check_tool(actor, "settle_claim", 58000)
    P-->>CW: denied, required L3, held L2,
downgrade_to = escalate
    CW-->>H: refusal + escalation route
    H->>L: authority decision recorded
    H->>CW: raise_approval(claim, 58000, to=L3)
    CW->>S: approval queued
    S-->>CW: approved with note
    CW->>CW: settlement posted, reserve released
    CW->>L: business event: claim_settled
old 0 -> new 58000, by supervisor
    Note over L: Three records, one correlation id:
the run, the refusal, the money moving

Note what does not happen. The agent is not terminated. The run is not marked failed. No alert fires. Being refused is a normal outcome of doing the job, in exactly the way it is normal for a junior adjuster to need a signature.

He escalated on 11 of his 17 runs

That is the number that surprises people, and it is the number we are most pleased with.

An escalation rate of 65% would look like a failing agent on a conventional dashboard. Six in ten runs did not complete autonomously. If you were optimising for autonomy, you would tune the prompt, raise the limit, and celebrate the number coming down.

That would be exactly the wrong move, because the escalation rate is not measuring the agent. It is measuring the fit between the work and the authority. A high rate on a book of large commercial claims is correct — those claims genuinely need a supervisor. A high rate on small routine claims would tell you your limits are set too tight and you are wasting supervisor time. A rate of zero should worry you most of all, because it usually means the checks are not wired up.

Escalation rate is not a measure of how good your agent is. It is a measure of whether your authority model matches the work.

Three things you can only see if you keep refusals

Once refusals are first-class records rather than discarded errors, some questions become trivial that are otherwise unanswerable.

Where teams usually get this wrong

Three failure modes we have hit ourselves, in rough order of how often we see them elsewhere.

1. The limit lives in the prompt

"You are a claims adjuster with a settlement authority of $50,000. Never settle above this amount." This reads like a control and behaves like a preference. Worse, it is invisible to the audit trail: when the agent complies you have no record that a limit existed, and when it does not comply you have no record either.

2. The check exists but returns an exception

Better — the product does enforce. But raising PermissionError and letting it bubble into a generic error handler means the refusal is logged as a failure, buried in a stack trace, counted in your error rate, and thrown away at the next log rotation. We did this first. The fix was to make refusal a value the tool returns, not an exception the harness catches.

3. The check is computed and then ignored

The nastiest one, because everything looks correct. The code calculates the required authority, logs it, puts it on a dashboard, and then proceeds with the write regardless. We found one of these in our own underwriting product — a renewal control that produced exactly the right number and enforced nothing. It has its own post: the control that was computed but never enforced.

A checklist you can run this week

If you have agents in production that write to a system of record, these five questions are worth answering honestly.

• Can your agent be refused? Not "will the prompt stop it" — is there a code path in the product that returns a denial the agent cannot bypass?
• Is the refusal a record? Can you list every refusal from last month, with the actor, the capability, the authority held and the authority required?
• Does a refusal have a next move? An agent that is denied with no route forward will retry, rephrase, or pick a worse tool. Give it an escalation path.
• Is the approver in the same thread? If the escalation lands in a separate ticketing system, you have two half-records and no story.
• What is your escalation rate, per capability? If you cannot answer, you do not yet know whether your limits match your work.

What this looks like in InsightLense

Refusals are only valuable if they are queryable. In InsightLense every authority decision is a row — allowed, refused, escalated or downgraded — carrying the level held, the level required, and who the decision was raised to.

The escalation rate in the header is not decoration. It is the metric that tells you whether your authority model fits the work, and InsightLense computes it per actor and per capability so a rate that is too high on routine work is visible as a specific capability rather than as a vague sense that the agent asks too often.

The line we keep coming back to

Agentic AI gets sold on what an agent can do unsupervised. We have come to think that is the least interesting property of the system. Anything can act without supervision; a shell script acts without supervision.

What makes an agent trustworthy enough to put in front of a book of business is the opposite capability — that when it reaches for something beyond its authority, something outside of it says no, routes the decision to a person who can say yes, and writes down that the whole exchange happened.

Agentic AI is only trustworthy when it can be told no. And it is only auditable when that refusal was written down.