Cost-aware model routing for AI agents on AWS: an insurance claims walkthrough with Bedrock and SageMaker AI.

A chatbot makes one model call per conversation. An AI agent that processes an insurance claim makes nine, across a dozen steps and eighteen tool calls, before a person sees the result. If every one of those calls goes to a frontier model, you are paying frontier prices for work a lookup table could do.

This post walks through a single motor claim, step by step, and shows where a cost-aware router sends each piece of work: to deterministic code, to a small fine-tuned model on Amazon SageMaker AI, to a low-cost foundation model on Amazon Bedrock, to a strong reasoning model, or to a human adjuster. The claim is invented. The architecture is the one we build.

The architecture that burns money

A customer uploads photos of a damaged car and writes: “I had an accident yesterday. The rear bumper and tail light are damaged. I wasn't at fault. Can you process my claim?”

The first version of most claims agents looks like this:

It works. It also spends the same money on classifying a bumper as it does on reasoning about conflicting evidence in a suspected fraud. Several of those steps are trivial, one or two are hard, and the architecture cannot tell the difference. At a hundred thousand claims a month the bill for the trivial steps dominates.

The cost-aware architecture

The fix is a routing layer between the agent and the models. Before any step runs, the router scores the task and picks the cheapest path that can do it well.

Notice that the ladder has five rungs, not two. Most writing on model routing frames it as cheap model versus expensive model. In an enterprise agent the more important routes sit at the ends of the ladder.

One claim, step by step

Here is what the router does with our rear-bumper claim as it moves through the agent.

Step 1: classify the claim

The system has: rear bumper damaged, tail light broken, no bodily injury, another driver involved, police report available. The task is a classification with a small, known label set.

This is exactly the traffic to keep away from a frontier model. A classifier fine-tuned on a few thousand labelled claims will do it faster, cheaper and more consistently.

Step 2: extract the documents

The customer uploaded a driving licence, the police report, a repair estimate, the policy document and three photographs. The agent needs structured fields out of them.

Step 3: look up the policy

Is collision damage covered under policy IN-928331? This should not involve a language model at all.

Every fact a system of record can answer is a fact the model should never be asked to guess. It is cheaper, and it is the only way the answer is defensible later.

Step 4: reason about coverage

Now the agent has a repair estimate, a deductible, an active policy on the incident date, and photographs consistent with the description. It needs to combine them.

The model reasons; code checks the numbers. That pairing is the pattern for every medium-risk step: let the model do the synthesis, never let it be the last word on a figure.

Step 5: something unusual appears

The damage-analysis step notices that one photograph's metadata is three months old, another looks previously submitted, the repair estimate is well above benchmark, and a prior claim exists for similar damage. The reasoning requirement has changed completely.

Now spending more is justified. The strong model reads the claim statement, the policy conditions, previous claims, photo metadata, the repair estimate, vehicle history, fraud rules and the police report, and returns:

The expensive model ran once, at the one point where extra reasoning had economic value, and even then it did not decide. It recommended, and a person decides.

Why agents make this matter more than chatbots

A traditional chatbot makes one model call. Look at what one claim generates inside an agent:

Twelve operations. Without routing, eleven of them hit the premium model. With routing, seven go to a small model, two go to deterministic code, one goes to a medium model, and one goes to the strong model only when the fraud triage triggers it.

At a hundred thousand claims a month, that is nine hundred thousand inference calls.

At that volume a routing decision that moves one step from the strong tier to the small tier is not a rounding error. It is the difference between an agent the finance team approves and one it does not.

The router is a risk model, not a cost switch

For an insurer, easy-goes-small and hard-goes-big is not enough. Task complexity is one input among several, and some of the others matter more.

Two claims make the point.

The router is allocating intelligence according to risk, and cost falls out of that as a consequence. That framing also answers the governance question: the same score that sends a claim to the strong model is the score that sends it to a person.

Where SageMaker AI and Bedrock each fit

Having both services in one architecture is what makes the ladder real rather than theoretical.

• SageMaker AI is where the high-volume, narrow tasks live. A small model fine-tuned on the insurer's own claims handles claim type, document type, coverage category, severity, fraud indicators and the routing classification itself. These tasks run thousands of times a day, need consistency more than creativity, and do not need a general-purpose model. Training and evaluation run as SageMaker AI jobs against reviewer labels, so accuracy is measured rather than assumed. Our fine-tuning guide covers when a small trained model beats a prompt.
• Amazon Bedrock is where the generative and reasoning work lives: coverage reasoning, the customer email, the escalation explanation, and the rare complex fraud analysis. The router chooses the model tier per call, and Bedrock's model choice means the strong model can change as better ones arrive without touching the agent.
• Bedrock Intelligent Prompt Routing can already choose between models in a family based on predicted quality and cost. It is a good default for the generative steps. An insurer still wants its own routing layer on top, because claim value, regulatory exposure, fraud risk, confidence and workflow state are inputs a prompt-complexity router cannot see.

What stays with a person

The ladder only works if the top rung is real. In the architecture we build, three things are fixed regardless of how the router scores a claim.

• Anything that pays money, denies a claim, or touches a regulated decision waits for an adjuster. The model recommends; it does not decide.
• Every step is logged with the route taken, the model and prompt version, the evidence used, the output, and the person who approved it. That record is what makes the decision defensible in an audit.
• Confidence thresholds are tuned per claim type from real outcomes, and the approval log is what lets the insurer widen automation deliberately, on evidence, rather than on trust.

This is the same principle behind our enterprise AI work and the document and claims systems in our use cases: deterministic code handles facts, models handle synthesis, and people handle judgement.

Questions people ask about model routing