Can we route by authority limit?

Your code picks the externalId, so the same authority matrix you already run decides who gets asked. A claim above one band calls decisions.ask() with the id of someone in the next, and the referral option in a select lets the first approver push it up without leaving the flow.

Does the claimant ever see Pushary?

No. Pushary carries the question to your approver and the answer back to your code. If you also want to reach policyholders directly, the same primitive does that under your own branding on the decide page, and they never see a Pushary login or bill.

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

It fails closed. The decision returns denied and your agent decides what that means, which for most carriers is referring the file rather than applying the model's proposal. The unanswered request stays in the ledger, which is itself useful when you are looking at where files stall.

Can the approver settle at a different number?

Use an input type and they type the amount, or a select with a referral option if you want the choices constrained. Either way the value they returned is on the decision object, so your code applies what the person actually decided rather than what the model proposed.

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 puts a named adjuster or underwriter in front of the decision your agent has prepared. Wrap the decline, the settlement, or the pricing exception in decisions.ask() and the agent holds until that person answers within their authority. Timeouts resolve denied rather than proceeding, and every decision is recorded with the person and the timestamp.

Where it stops

The calls that should not be automatic

declineClaim(claimId, reason): A decline is the decision a policyholder disputes, a regulator asks about, and a court eventually reads. Somebody has to own it by name.
settle(claimId, amount): Settlement authority is already defined in bands per role, and an agent has no band unless you give it one.
applyPricingException(quoteId, factor): Overriding a rating factor is exactly where an unexplained model output turns into a fairness problem you have to justify later.
requestIndependentMedicalExam(claimId): Escalating a claimant into an examination has a real cost to that person, which is a decision rather than a workflow step.

The integration

Two calls 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.

npm i @pushary/servertwo calls

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.answer === "Accept proposal") return applyOutcome(claim, assessment)
  return referOrAdjust(claim, decision.answer)
}

Who answers

The approver is usually not an engineer

The approver is an adjuster or an underwriter who already works inside a defined authority limit, and who spends the day on calls, site visits, and files rather than in one screen. Insurance is unusual in that the human oversight step is not something you have to argue for, because authority bands are how the business has always worked. The difficulty is that an agent assembling the recommendation has no authority of its own, so every case it prepares stops until somebody with a band looks at it. If that looking requires being at a desk, the automation you built moves the bottleneck rather than removing it. Pushary reaches the person by the id already on the claim.

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

By being able to show that a person with the right authority made the decision, what they were shown when they made it, and when. That is a records question more than a model question, and it is the part most teams leave until someone asks. Pushary writes each decision to a durable ledger holding the question exactly as the approver saw it, the option they chose, their identity, and the timestamp, and it exports. Whether your particular use falls under a high-risk classification and what that then requires of you is a matter for your own counsel, because insurance pricing and risk assessment sit inside the scope regulators have been most explicit about. We would rather point you at the regulation than summarise it for you.

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

$99/ month, Partner plan

Embed it in your product. Your users never see a Pushary login or bill.

FAQ

Questions, answered

Human-in-the-loop for other products

Human-in-the-loop API Embed it for your users 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 with one tap, ask a human with one call, and act on a fail-closed decision. Every decision is saved to a durable ledger you can audit.