Human-in-the-loop for insurance products

Someone owns the decline.

The adjuster or underwriter decides from their phone, inside their authority, and the record shows who it was.

How do insurance AI agents keep a human in the loop on claims decisions?

Pushary keeps a human in the loop on claims decisions made by insurance AI agents. It sends what the agent proposes to a named adjuster or underwriter. Put one Pushary call before the decline, the settlement or the pricing exception. The person answers on their phone, within their own authority. Your agent waits for that answer. If time runs out, the proposal does not run. Every answer is saved with the person and the time.

What needs a yes

The calls that should not be automatic

declineClaim(claimId, reason): A decline is what a policyholder disputes, a regulator asks about and a court may one day read. Somebody has to own it by name.
settle(claimId, amount): Settlement authority is already set in bands for each role. An agent has no band unless you give it one, and a settlement above the band is one nobody signed off.
applyPricingException(quoteId, factor): Overriding a rating factor is where an unexplained model output turns into a fairness problem you have to justify later.
requestIndependentMedicalExam(claimId): Sending a claimant to an examination has a real cost to that person. That makes it a decision rather than a workflow step.

The code

One call inside the step you already have

Wrap the action, not the whole agent. Everything the agent does that is safe keeps running without asking anyone.

bash

npm i @pushary/server

one call

import { createPusharyServer } from "@pushary/server"

const px = createPusharyServer({ apiKey: process.env.PUSHARY_API_KEY! })

async function decideClaim(claim: Claim, assessment: Assessment) {
  // Straightforward approvals inside authority settle without a person.
  if (assessment.outcome === "approve" && assessment.amount <= claim.autoLimit) {
    return settle(claim.id, assessment.amount)
  }

  const decision = await px.decisions.ask({
    externalId: claim.adjusterId,
    type: "select",
    question: `Claim ${claim.reference}: model proposes ${assessment.outcome} at ${assessment.amount}. ${assessment.topReason}`,
    options: ["Accept proposal", "Settle at a different amount", "Refer to senior adjuster"],
  })

  if (decision.value === "Accept proposal") return applyOutcome(claim, assessment)
  return referOrAdjust(claim, decision.value)
}

Who answers

The approver is not at a desk

The approver is an adjuster or underwriter who works inside an authority limit. Their day is calls, site visits and files. Nobody in insurance needs convincing: authority bands are how the business works. An agent has no authority, so every case it prepares waits for someone with a band. If that person must be at a desk, the bottleneck moves. Pushary reaches them by the id already on the claim.

How do we explain an AI-assisted decline to a regulator or a claimant?

Show that a person with the right authority made the decision, what they were shown, and when. That is a records question more than a model question, and most teams leave it until someone asks. Pushary saves each answer with the question exactly as the approver saw it, the option they chose, who they are and the time. You can export it. Whether your use counts as high-risk, and what that then requires of you, is a matter for your own counsel. Insurance pricing and risk assessment are where regulators have been most explicit. We would rather point you to the regulation than summarize it for you.

Worth reading: Regulation (EU) 2024/1689, the EU AI Act, on EUR-Lex.

$99/ month, Partner plan

Add it to your product. Your users never make a Pushary account or pay us.

What the Partner plan covers

FAQ

Questions, answered

Can we route by authority limit?

Yes. Your code picks the user id, so the authority matrix you already run decides who gets asked. A claim above one band goes to someone in the next band. A referral option in the list lets the first approver push it up without leaving the flow. The answer comes back under the name of whoever actually decided.

Does the claimant ever see Pushary?

Not when your adjusters are the ones answering. Pushary carries the question to your adjuster and the answer back to your code. You can also ask policyholders directly with the same call. They then install the free Pushary app and connect once with a link, with no account and no payment. The notification and the decision page carry your product's name.

What if the adjuster does not answer before an SLA runs out?

The model's proposal does not run. The answer counts as no, and your agent decides what that means. For most carriers, that means referring the file. Set the timeout inside your SLA, so the referral still happens in time. The unanswered request stays saved, which helps when you look at where files stall.

Can the approver settle at a different number?

Yes. Use the input type and they type the amount, or a list with a referral option if you want fixed choices. Either way, the value they return comes back to your code. You apply what the person decided, rather than what the model proposed.

Human-in-the-loop for other products

Human-in-the-loop API See the Partner plan travel and expense agents customer support agents AI SDR and outbound agents DevOps and SRE agents legal AI agents finance and accounting agents healthcare AI agents security and SOC agents

Put a person on the step that needs one.

Connect a user once, ask with one call, and run the action only on a yes. Every answer is saved.

Start free