What does an agent cost to run?
What the claims agent does, why only part of it needs an agentic loop, and an itemised daily bill from users and turns down to tokens, search, hosting and people. Change any input; every line recalculates.
1 · What the agent does
Contoso's customers contact the claims assistant through the support web app. Every message is sorted first, then handled by the cheapest path that can do the job safely. Only one path is an agent.
| Path | A customer says… | What happens | Tools and model |
|---|---|---|---|
| Fixed flow: status | "Where's my claim?" | The customer is already signed in, so the flow calls get_claim and fills a reply template: stage, next step, expected date. | get_claim + a reply template; no model writes the answer |
| Fixed flow: missing details | "Here are the photos and the plumber's invoice." | A form checks which required fields and documents are still missing and asks only for those. A small model pulls dates and amounts out of free text. | list_documents; gpt-5-nano for extraction |
| Fixed flow: payout | "Can you pay the €640 for the plumber?" | Rules check eligibility and the amount against the policy limit, then create a payout request that an adjuster approves in Teams. | issue_payout behind human approval; rules decide, no model |
| RAG workflow | "Am I covered if a pipe bursts while I'm on holiday?" | Search the policy wording (hybrid search plus semantic ranker), answer only from the retrieved clauses, and cite them. | AI Search; gpt-5-mini |
| Agent loop | "Why did you only pay part of my roof claim, and what do I need to send to get the rest?" | The next step depends on what each step finds; see the trace below. | get_claim, list_documents, policy search, hand-off; gpt-5-mini (gpt-5 if evaluations demand) |
2 · How the sorting step decides
The sorting step (also called an intent router or triage step) is a small piece of your application code that labels each customer message and sends it to a path. It isn't Foundry's model router: that picks which model answers; this picks which path handles the message. It tries the cheapest signal first, and the first confident layer wins.
Layer 1 · Signals, no model
- Show it before they ask: a signed-in customer with an open claim sees a status card first, so most "where is my claim" questions are never typed.
- Buttons: "Check my claim", "Upload documents", "Talk to someone" route directly.
- State: a form half filled → the next message continues the form; a payout awaiting approval → status questions go to the status flow.
- Patterns: a claim number plus "where" or "status" → status flow; "human", "complaint" → a person.
Layer 2 · A small model labels it
Only when Layer 1 can't decide. gpt-5-nano reads the message and the last few turns, with 2–3 examples per label, and must return a label from a fixed list (structured outputs):
{ "route": "status | provide_details | payout |
policy_question | complex | human | out_of_scope",
"confidence": 0.0-1.0,
"multiple_intents": true | false }| Layer 3 · When it's unsure | Route | Why |
|---|---|---|
| Confidence below about 0.7 | Agent, or one clarifying question | Better to over-serve than answer the wrong question |
| Several questions in one message | Agent | Mixed questions are exactly its job |
| Asks for a person, angry, or complaining | Human hand-off | Never trap a customer in automation |
| Off-topic | Polite fixed reply | Don't spend tokens |
| Medium confidence on a fixed-flow route | Confirm with buttons: "Do you want the status of claim CL-88213?" | One tap turns the model's guess into a deterministic step |
| Example message | Decided by | Route |
|---|---|---|
| Taps "Check my claim" | Layer 1: button | Fixed flow: status |
| "CL-88213 where is it now?" | Layer 1: pattern | Fixed flow: status |
| "Here's the plumber's invoice" (form in progress) | Layer 1: state | Fixed flow: details |
| "Am I covered if a pipe bursts while I'm away?" | Layer 2: policy_question, 0.93 | RAG workflow |
| "Why did you only pay part of my roof claim, and what do I send?" | Layer 2: complex, multiple intents | Agent loop |
| "This is the third time I've asked. I want to complain." | Layer 1: pattern | Human hand-off |
Prove it before launch: label about 500 real messages with the right route, measure accuracy per route and which routes get confused, and watch the expensive mistake above all. After launch, sample routed messages weekly; phrasing shifts, for example during a storm.
Where it runs: your application code (a few lines calling gpt-5-nano), or the first branching node of an Agent Framework workflow. Fixed flows are ordinary code; the agent is a Foundry prompt agent.
3 · How it helps the business
| Who | Before | With the assistant | Measure it with |
|---|---|---|---|
| Customers | Phone queues of 20+ minutes during storms; office hours only | Answers at any hour, in their language, with the policy clause quoted | Satisfaction score, time to first answer |
| Contact centre | Five times the calls during storms; temporary staff hired at short notice | Status and policy questions resolved without a person; peaks absorbed without hiring | Calls avoided, share resolved without a person |
| Claims handlers | Days of emails chasing missing documents | Missing details collected at the first contact; claims arrive complete | Time from first report to a handler's decision |
| Adjusters | Look-ups and explanations take time from decisions | Their time goes to approvals and real edge cases | Approvals per adjuster per day |
| Compliance | Explanations vary by agent and aren't recorded | Every coverage answer cites the clause and is traced | Complaints about wrong answers, audit sample pass rate |
| Finance | Cost per call from the contact centre | A few cents per conversation; see the calculator | Total cost per resolved conversation |
4 · Why the agentic loop is a must here, and only here
The question: "Why did you only pay part of my roof claim, and what do I need to send to get the rest?" Here's what the agent does, step by step.
- get_claim(CL-88213) → roof claim, €2,400 claimed, €900 paid. Exclusion code WR-3 applied to the rest. The agent now knows which clause matters, which it couldn't know before this call.
- Search policies for clause WR-3 → "Gradual deterioration and wear and tear are excluded, unless the damage was caused by a single sudden event, such as a storm, evidenced at the time." Now it knows what evidence would change the outcome.
- list_documents(CL-88213) → three photos (no dates in their data) and a roofer's quote that says "old flashing". No storm report, no dated photos. Now it knows exactly what's missing.
- Decide: the gap is evidence of a sudden event. The quote's wording supports the exclusion, so the agent mustn't promise anything. It explains clause WR-3 in plain words, quotes it, and asks for dated photos from the storm night or a roofer's statement that the damage was storm-related. It offers to hand the claim to a handler.
A different customer asking the same question would take a different path: a payout cap instead of an exclusion (search the limits clause, no documents needed), or a document already uploaded but unread (no request, hand straight to a handler). The steps can't be written down in advance, because each one depends on what the last one returned.
| Test (deterministic first) | Status question | Policy question | "Why partial, what do I send?" |
|---|---|---|---|
| Can you write the steps down in advance? | Yes → fixed flow | Yes: search, then answer → workflow | No: they depend on the claim |
| Does the next tool depend on the last result? | No | No | Yes: exclusion code → which clause → which evidence |
| Is the number of steps known? | Yes (1) | Yes (2) | No: 2 to 6 depending on the case |
| Would coding every path be practical? | Yes | Yes | No: about 40 exclusion codes × claim states × document states |
| Is the cost of a wrong step bounded? | — | — | Yes: read-only tools; payouts need an adjuster; max 8 steps; hand-off available |
| Verdict | Fixed flow | RAG workflow | Agent loop |
5 · Cost calculator
| # | Line item | How it's worked out | $/day |
|---|
Business value per day
| Line | How it's worked out | $/day |
|---|
Value is an illustration from your assumptions, not an industry benchmark. Measure the real numbers: resolution without a person, calls avoided, time to a handler's decision, and complaints about wrong answers.
One-time costs
| Item | How it's worked out | $ |
|---|
What moves the total
| If you… | Change per day |
|---|
Reading the bill
Most of this app isn't an agent
Claim status, forms and payouts are fixed flows; policy questions are a RAG workflow. Only mixed, multi-step questions, where the next step depends on what the last one found, need an agent. Hybrid cuts model cost and keeps money decisions away from a model. It also makes a stronger model affordable where it matters: with the agent on 20% of turns, moving it to gpt-5 costs far less than in the all-agent design.
At this volume, the model isn't the biggest cost
Fixed platform costs (Search, hosting, endpoints) are a large share of the Azure bill. Set conversations to 20,000 and the model takes over: fixed costs barely move.
Output and reasoning tokens dominate the model cost
There are far fewer of them than input tokens, yet they cost more. Lower reasoning_effort and ask for short answers before trimming input.
Most of the value comes from the simple paths
Storm-peak capacity, calls avoided and consistent cited answers come mainly from fixed flows and RAG. The agent adds value for the complex minority, and carries the most risk, so keep it narrow and evaluated.
What's checked and what's estimated
| Item | Status | Source |
|---|---|---|
| gpt-5-mini: $0.25 input, $0.025 cached, $2.00 output per million tokens | Checked 8 Oct 2026 | azurespeed |
| Other model prices in the list | List prices as last known; check before use | Azure OpenAI pricing |
| AI Search S1 $245 per search unit per month | Checked | Search cost playbook |
| Semantic ranker: first 1,000 queries a month free, then $1 per 1,000 | Checked | Microsoft Learn |
| Standard agent setup: Cosmos DB at 3,000 RU/s minimum if provisioned, or serverless | Checked | Microsoft Learn |
| No separate charge for the prompt-agent runtime; guardrails included with the model | Believed true; verify | Foundry pricing page |
| Layout extraction $10 per 1,000 pages; trace data $2.30 per GB; private endpoint ~$0.24 a day | Approximate list prices | Azure pricing pages |
| Traffic split, resolution rate, call cost | Your assumptions | Measure in a pilot |
Related: Choose the right model has the ranked cost levers and the prompt-caching comparison.