Production-ready agents, Part 13.5: What does an agent cost to own? Pricing across the architecture choices

The question I am asked right after “does it work?” is “what will it cost?”. It is a fair question, and the honest answer has more lines than people expect. The model is usually the biggest variable cost, but it is not the only one, and several of the choices this series has made (code routing, narrow tools, A2A between teams, Gemini Enterprise as the front door) move the bill more than the choice of framework does.

This part puts the numbers together. Part 11 measured the model cost of one question; Part 11.5 capped it; Part 13 compared models. Here we add everything else, estimate a month of Acme’s system at list prices, and then go through the architecture choices from earlier parts one at a time, asking what each does to the total.

Where are we in the architecture?

This part adds no new box. It prices every box in the picture: model tokens, runtime, state, data, gateway, front door and people, and what each architecture choice does to the bill. Part 1.25 walks through the whole picture, layer by layer.

where Part 13.5 sits in the Acme architecture: highlighted boxes are the subject of this part, solid boxes come from earlier parts, faded boxes arrive later

What do I need to know first?

Total cost of ownership (TCO). Everything you pay to run a system over its life: the cloud bill, licences, and the people who build and run it. Not only the price of a model call.
Variable vs fixed cost. A variable cost grows with use (tokens per question). A fixed cost is paid whether anyone asks a question or not (a server that is always on, a licence per seat).
Idle cost. What a component costs while nobody is using it. Two hosting services with the same hourly rate can differ hugely here, depending on whether idle time is billed.
Unit cost. The cost of one unit of value. This series uses cost per resolved question: total cost divided by the questions the system answered correctly (Part 11).
List price. The public price on a vendor’s page. Committed-use and enterprise discounts can be much lower, so every figure in this part is a list price, dated, and illustrative.

Where does the money go?

An agent’s bill has eight lines, and the model is only one of them: it is the biggest line the cloud bill shows, but licences and people, which the cloud bill does not show, are usually bigger.

Think of a small restaurant. The ingredients grow with every plate served. The kitchen (ovens, fridges) costs money whether or not anyone orders. The pantry keeps what was bought yesterday. The suppliers charge per delivery. The health inspector and the till receipts are how you know what happened. The front door and the dining room are where customers sit. And the staff who cook, serve and clean are, for most restaurants, the biggest cost of all. A new owner who prices the menu on ingredients alone goes bust, even if every plate is cheap to make.

Mapped to an agent: ingredients are model tokens (they grow with every question), the kitchen is runtime compute, the pantry is state, the suppliers are data queries, the inspector and the receipts are the gateway checks and observability, the dining room is the front door, and the staff are the people who build and run the system.

How does this apply to Acme? Here are the same eight lines with Acme’s illustrative monthly numbers, which the next sections work out:

the eight lines of an agent's bill, with Acme's illustrative monthly estimate at list prices: model tokens about USD 2,255, runtime compute about USD 22, state and gateway about USD 1; data and observability must be measured; front-door licences and people sit outside the cloud bill and are often the largest

Every agent system has the same eight lines on its bill. For Acme they are:

Model tokens. Every model call: input, cached input, output and thinking (Part 11’s call_cost).
Runtime compute. The servers the agents run on: Agent Runtime in this series.
State. Sessions and Memory Bank storage and operations (Part 8).
Data. The queries the tools run: BigQuery for marketing, a Databricks SQL warehouse for supply.
Gateway and security calls. Agent Gateway’s outbound checks (Part 12) and Model Armor screens (Part 9).
Observability and evals. Logs, traces, the BigQuery analytics dataset, and the eval runs that gate each release (Parts 10 and 11).
The front door. Gemini Enterprise licences for the people who use it (Part 12).
People. The engineers who build, test, run and improve the system. For most teams this is the largest line of all, and the one architecture choices affect most.

The misconception to name: “the agent costs what the model costs”. Part 11 measured one question’s model cost, USD 0.0537, and it is tempting to multiply that by the traffic and stop. That number is line 1 only. It is the right place to start, because it is the biggest line you can see on the cloud bill, but it is not the total.

How do I work out token cost from first principles?

The bill is two multiplications and one scale-up: tokens times price per call, times calls per task, times tasks per day. Everything else in this section is about which of those numbers you can shrink.

Think of a taxi. The fare is a pick-up charge plus a rate per mile, and the monthly bill is the fare times the number of trips. Mapped to an agent: the input tokens are the pick-up charge (everything the model must read before it can start), the output tokens are the miles (everything it writes, at a higher rate), and the trips are the model calls. A cheap fare taken a million times is not cheap.

Where people get tripped up is the price list. A rate of USD 1.50 per million tokens sounds like nothing, so they stop there. The trap is that agents read a lot and call the model many times per task, and both multiply.

The formula, one step at a time:

cost per call  = input tokens x input price + output tokens x output price   (prices per million)
cost per task  = cost per call x calls per task
cost per day   = cost per task x tasks per day

A worked example. Take an agent (not Acme’s; a busier, hypothetical one) that reads 20,000 tokens of context and writes 1,000 tokens per call, makes five calls per task and handles 10,000 tasks a day, priced at the Gemini 3.5 Flash list prices Part 11 checked (1.50 input, 0.15 cached input, 9.00 output, US dollars per million tokens):

Input tokens a day    20,000 x 5 calls x 10,000 tasks = 1,000,000,000   (1 billion)
Output tokens a day    1,000 x 5 calls x 10,000 tasks =    50,000,000   (50 million)

Input cost            1,000 million x USD 1.50 = USD 1,500 a day
Output cost              50 million x USD 9.00 = USD   450 a day
Total                                            USD 1,950 a day  (USD 0.195 a task, USD 58,500 a 30-day month)

Notice that input is three quarters of the bill even though output costs six times more per token. That is normal for agents: they read far more than they write. It is why the first levers below all attack input.

Which levers cut it, and in what order?

Pull the levers that shrink what the model reads first, then the ones that change which model reads it, and keep limits for the runaway task. In the example below, the first lever alone halves the bill.

Where people get tripped up is reaching for a cheaper model first, because it is the most visible choice. In the example, input is three quarters of the bill and most of that input is the same on every call, so caching it saves slightly more than moving three of the five calls to Flash-Lite would on its own (USD 1,012.50 a day against USD 975), and it does not change which model writes the answer.

Most of these levers already have a home in the series, so here is the order to pull them in and what each does to the example, with links for the detail. The shares (how much is cached, how many calls are simple) are illustrative assumptions; measure your own.

Lever (in order)                         Assumption                                   USD a day
Start: every call on Flash               none                                          1,950.00
1. Cache the stable context              15,000 of 20,000 input tokens cached at 0.15    937.50
2. Smaller model for simple steps        3 of 5 calls on Flash-Lite (0.25/0.025/1.50)    468.75
3. Smaller tool results                  fresh input per call from 5,000 to 2,000        356.25
4. Batch for anything not interactive    30% of tasks run as batch at half price         302.81
5. Step and token limits per task        caps the worst task, not the average            (tail)

Levers 1 to 4: about 84% less, from USD 58,500 to about USD 9,084 a 30-day month

Caching (Part 11 shows the arithmetic with cached_tokens). The system prompt, skills and tool list are the same on every call, so pay for them at a tenth of the price.
A smaller model for simple steps (Part 13). Routing and extraction rarely need the model that writes the answer; Acme goes further and routes in code with no model at all (Part 5).
Fewer, better tool results (Part 2 caps the rows a tool returns; Part 15 shows what happens when you do not). Return the ten rows that answer the question, not the table.
Batch for anything not interactive. This is the one lever the series has not covered yet, so it gets its own explanation below.
Step and token limits (Part 11.5 counts model calls and tokens per turn). These do not lower the average; they stop the one task that loops. In the example a normal task is five calls at USD 0.039 each; a task stuck in a 200-call loop costs USD 7.80, the price of 40 normal tasks.

the same agent workload, 1 billion input and 50 million output tokens a day, priced at Gemini 3.5 Flash list prices and then with each lever applied in order: caching, a smaller model for simple steps, smaller tool results and batch for work that is not interactive take it from about USD 1,950 to about USD 303 a day; step and token limits cap the worst task rather than the average (illustrative shares)

What does batch buy, and what does it cost you?

Batch trades speed for price: you submit many requests as one job, get the answers later, and pay half. Google Cloud’s batch inference page says, as of November 2026, that “batch processing is offered at a 50% discounted rate compared to real-time inference”, and that for Gemini 3 and later models “the cache and batch discounts stack, providing a 95% total discount on cached input tokens compared to standard input tokens”. The pricing page shows it in the rates: Gemini 3.1 Pro Preview is USD 2.00 input and 12.00 output per million tokens on standard, and USD 1.00 and 6.00 with Flex/Batch.

The price of that discount is time. The same page says batch jobs “are not designed for real-time applications”, that “most jobs complete within 24 hours after it starts running (not counting the queue time)”, that a job may wait in the queue “for up to 72 hours before it expires” when capacity is busy, and that “after 24 hours, incomplete jobs are cancelled, and you’ll only be charged for completed requests”. A single job can hold up to 200,000 requests.

A post office is the everyday version: first class or second class. Second class costs less because you accept that the letter arrives in a few days, not tomorrow. Nobody sends a reply to a live conversation second class.

Why it wins. At Acme, this is how it would work: every Monday, an overnight job summarises last week’s campaign results for each of Acme Pure, Verde and Harvest Row across 300 campaigns, so the summaries are waiting when Maria logs in. Nobody is waiting on any single answer, so half price for “ready by morning” is a good deal.
Why it fails. Maria asking the router a question in Gemini Enterprise. She is waiting for the answer, and “within 24 hours, after up to 72 hours in a queue” is not an answer. Interactive work stays on standard calls, or on provisioned throughput if it needs guaranteed capacity (Part 13).

The litmus test, cheapest question first: is anyone waiting for this answer right now? If not, can the result arrive tomorrow without harm? Only then move it to batch, and keep the step and token limits on, because a batch job runs many tasks with nobody watching.

What does a month of Acme cost at list prices?

About USD 2,280 a month in cloud services, or about six cents per resolved question, and almost all of it is model tokens. Data, observability, licences and people come on top and have to be measured or quoted separately.

Before the real numbers, the method on something everyone has budgeted: the monthly cost of a car. Start from usage (say 1,000 miles a month), multiply by the rate for each line that grows with use (fuel per mile), add the lines that do not (insurance, a parking permit), and write “measure it” next to the lines you cannot know in advance (repairs). The result is an estimate you can defend line by line, and you can see at once which line to attack: if fuel is 80% of it, a cheaper parking permit will not help.

How does this apply to Acme? The same method: traffic first, then a rate for each line that grows with questions, then the lines that must be measured or sit outside the cloud bill.

A worked estimate, with every assumption stated. It is illustrative: the traffic and the seconds per question are assumptions, and the prices are list prices as of the dates given.

Assumptions   200 analysts x 10 questions per working day x 21 days = 42,000 questions a month
              90% resolved (Part 11's toy week)                      = 37,800 resolved

1. Model tokens        42,000 x USD 0.0537 (Part 11's measured example)          USD 2,255
2. Runtime compute     router 8 s + two specialists 5 s each = 18 active vCPU-seconds a question
                       42,000 x 18 s = 210 vCPU-hours x USD 0.085                   USD    18
                       210 hours x 2 GiB = 420 GiB-hours x USD 0.009                USD     4
3. State               2 GiB stored x USD 0.30 per GiB-month                       USD  0.60
                       840,000 reads (3M per vCPU-hour) + 420,000 writes (1M)       USD  0.06
4. Data                BigQuery bytes scanned and Databricks warehouse time        measure it
5. Gateway             42,000 x 3 outbound calls = 126,000 / 15,000 per vCPU-hour  USD  0.71
6. Observability       logs, traces, eval runs                                     measure it
7. Front door          Gemini Enterprise licences for 200 users                    per edition
8. People              build, run, improve                                         usually largest

Cloud services estimated (lines 1 to 3 and 5)                                      about USD 2,280
Per resolved question  2,280 / 37,800                                              about USD 0.060

The Agent Platform rates come from Google’s pricing page: Agent Compute at “$0.085/vCPU-h”, Agent Memory at “$0.009/GiB-h”, Agent Storage for Sessions and Memory Bank at “$0.30/GiB-month”, one vCPU-hour “for every 3 million read operations” and “for every 1 million write operations”, and one vCPU-hour per “15,000 API calls or Authorization requests processed via Agent Gateway”. The page also says that for Runtime, “idle time spent waiting for the next prompt between turns is not billed”. Model rates are the ones Part 11 checked on 19 October 2026.

Three things stand out. Model tokens are about 99% of the cloud services estimated, so every cost lever from Parts 11, 11.5 and 13 (Flash for small steps, caching, thinking levels, capped rows) matters far more than the hosting bill. The lines left as “measure it” can be large: a careless query that scans a whole table, or a warehouse left running, can cost more than a month of tokens (Part 15). And licences and people are outside the cloud bill, but they are often bigger than everything on it.

What does the choice of framework cost?

Nothing directly. ADK is published “on GitHub under the Apache 2.0 licence” and LangGraph under MIT (Part 1.75), so neither charges for the library. The framework is free; the design you build with it, and where you run it, are not.

Think of two free recipe books. Neither costs anything to open, and the meal costs the same whichever book you used if the recipe is the same. What changes the bill is the recipe you pick (a five-course menu uses more ingredients than one dish), the kitchen you cook in (your own, or a hired one by the hour), and whether your cook already knows the book. Mapped to agents: the book is the framework, the recipe is the agent design (how many model calls per question), the kitchen is the hosting, and the cook is your team.

The misconception to name: “switching frameworks will cut the bill”. It rarely does on its own; the same design costs the same tokens in either.

How does this apply to Acme? The same three things are where the two frameworks differ:

Where it nudges you to host. ADK deploys to Agent Runtime, Cloud Run or GKE. LangGraph’s managed home is LangSmith Deployment, which LangChain’s pricing page lists at “$39 / seat per month” on the Plus plan, with deployments “charged based on resources consumed”: “Runtime Compute · 0.0675 LSU / vCPU-hr” and “Runtime Memory · 0.0090 LSU / GiB-hr”, plus trace volume above the plan’s included “10k base traces / mo”. You can also run LangGraph on your own containers, as you can ADK.
How many model calls the design makes. This is where the real money is, and it depends on how you use the framework, not which one. Acme’s router chooses the specialist in code (Part 5). Had it used a coordinator model, every question would add one more Flash call. At an illustrative 2,000 input, 50 output and 200 thinking tokens, that is (2,000 x 1.50 + 250 x 9.00) / 1,000,000 = USD 0.0053 a question, about 10% on top of Part 11’s 0.0537, or roughly USD 220 a month at Acme’s traffic.
People. A team that already knows one framework will build and fix things faster in it. Over a year, that usually outweighs every difference above.

The litmus test, cheapest question first: which framework does your team already know? Does the design add model calls that code could make instead (Part 5)? Where will it run, and is that billed per use or per hour? Only then compare the frameworks’ features, because in my experience that is usually the smallest of the four effects on the bill.

What do MCP, UTCP and A2A cost?

The protocols are free; what they cost is tokens, servers and extra agents. A tool costs the words that describe it on every call; a second agent costs a second set of model calls.

Think of an office worker answering a question. Looking a figure up in a shared spreadsheet is quick and cheap, but every spreadsheet on their desk is one more thing to scan before they find the right one. Phoning a colleague in another department is slower and costs that colleague’s time, but the colleague knows rules and data the caller does not, and is allowed to say no. Mapped to agents: the spreadsheets are tools (an MCP server or a UTCP description), the clutter on the desk is the tool definitions the model reads on every call, and the phone call is A2A, a delegation to another agent that thinks for itself.

How does this apply to Acme? One question for each protocol:

MCP: what do the tool definitions cost? Every tool the model can see is sent with every request. The unfiltered BigQuery MCP server exposes five tools; filtered to execute_sql_readonly, it exposes one (Part 1.9). If the four extra definitions add an illustrative 1,200 tokens to each of the marketing agent’s two calls, that is 2,400 x 1.50 / 1,000,000 = USD 0.0036 a question uncached, about USD 150 a month, or about USD 15 if the stable tool list is cached at 0.15. The bigger cost is behaviour: an unfiltered agent may make four exploration calls instead of one. A managed MCP server, such as BigQuery’s, costs nothing to run yourself, but the queries it runs are still billed by the data platform; an MCP server you host yourself adds its own hosting.
UTCP: what does skipping the wrapper save? A server you no longer build, host and maintain. On Cloud Run with request-based billing, “Cloud Run only charges for the CPU and memory allocated to an instance” while it handles work, so a small wrapper’s hosting bill is often tiny; the real saving is the engineering time. The tool definitions still cost the same tokens.
A2A: what does a second agent cost? A delegated question runs another agent with its own model calls. In Part 11’s measured example, the marketing specialist’s two calls were USD 0.0189 of the question’s 0.0537, about 35%. If a question only needs a lookup with no reasoning on the other side, a tool is cheaper. Acme pays the A2A price on purpose, because each team’s agent enforces its own data and rules (Parts 6 and 7): it is the cost of governance, and worth naming as such.

The misconception to name: “A2A is just another tool call”. On the wire it looks like one, but on the bill it is a whole agent turn, with its own prompt, thinking and answer.

A decision guide, cheapest first:

Scenario                                          Right choice                 Why
A lookup with a fixed shape, one data source      a narrow tool (Part 2)       one definition, no extra model calls
A vendor already runs a managed MCP server        MCP, filtered to the tools   no server to host; fewer definitions
                                                  you need (Part 1.9)          means fewer tokens and fewer detours
An existing HTTP API you would otherwise wrap     UTCP                         no wrapper to build, host or maintain
Another team owns the data and the rules          A2A (Parts 6 and 7)          pay a second agent's calls for governance

What does the hosting platform cost?

The biggest difference between platforms is idle cost: whether you pay while nobody is asking. Pay-per-use hosting wins when traffic is spiky; always-on hosting can win when it is busy around the clock, or when it sits next to the data.

Think of getting to work. A taxi charges only for the journeys you take; a leased car costs the same each month whether it moves or sits in the drive. If you travel twice a week, the taxi is cheaper. If you drive all day, every day, the lease wins. Mapped to hosting: the taxi is pay-per-use (billed for active time), the lease is provisioned capacity (billed per hour while running), and the hours the car sits in the drive are the idle cost.

How does this apply to Acme? Acme’s questions arrive in office hours, in bursts, so the drive is full of parked hours. Here is how each platform bills them:

Agent Runtime bills Agent Compute and Agent Memory for the resources an agent uses, and “idle time spent waiting for the next prompt between turns is not billed”. At Acme’s traffic, that is the USD 22 in the estimate above.
Cloud Run bills by request by default: “Cloud Run only charges for the CPU and memory allocated to an instance” while it is starting, shutting down, or processing at least one request, unless you opt into instance-based billing or keep minimum instances (billed at an idle rate).
Databricks Agent Bricks runs agents on Databricks Apps (Part 1.75), and Databricks’ documentation says “Apps are billed per hour of compute time while running, based on provisioned capacity”. The compute sizes are Medium (up to 2 vCPUs, 6 GB) at 0.5 DBU an hour, Large (up to 4 vCPUs, 12 GB) at 1 DBU, and XLarge at 3 DBU. A Medium app left running for a 730-hour month is 365 DBU, whatever the traffic; three agents are 1,095 DBU. Multiply by your DBU rate from Databricks’ pricing, which varies by cloud, tier and contract. Model calls through Databricks Model Serving and the SQL warehouse are billed on top.

So for spiky, office-hours traffic like Acme’s, pay-per-use hosting is cheaper; for an agent that is busy around the clock, an always-on app can be competitive. And there is a second factor that is not on any price list: where the data lives. If the agent’s data is in Databricks, hosting the agent there can avoid cross-cloud data movement and keep Unity Catalog’s permissions in one place, which may be worth more than the compute difference.

To see the size of the idle effect with Acme’s own numbers: the estimate above has 210 active vCPU-hours a month across all three agents, against 730 hours in a month for each app that is always on. Three always-on apps are billed for 2,190 app-hours while doing about 210 hours of work, so roughly nine in every ten billed hours are idle (illustrative, because an app and a vCPU-hour are not the same unit).

The litmus test, cheapest first:

Is traffic spiky or confined to office hours? Then use pay-per-use hosting (Agent Runtime, or Cloud Run with request-based billing).
Is the agent busy most hours of the day? Then price an always-on option against it at your real rates.
Finally, where do the agent’s data and its permissions live? If it is one platform, weigh that against the compute price before deciding, because it may be worth more than the difference.

What does the UI choice cost?

The choice is between paying per seat for a front door that already exists and paying people to build and run your own. The hosting bill is small either way.

Think of selling at a market. Renting a stall in an established market costs a fee per stall, but the roof, the lighting, the security and the customers are already there. Building your own shop has no stall fee, but you pay for the building, the locks, the cleaning and the staff, and you must bring the customers yourself. Mapped to agent UIs: the market is Gemini Enterprise (rendering A2UI cards), the stall fee is the licence per user, your own shop is a custom app speaking AG-UI, and the locks and cleaning are sign-in, sessions, sharing and accessibility.

How does this apply to Acme? Acme’s front door is Gemini Enterprise (Part 12), so Acme rents the stall. The three options:

A2UI in Gemini Enterprise. No extra hosting: Gemini Enterprise renders the cards (Part 12.75). The cost is the Gemini Enterprise licence for each user, which also buys the Gemini agent, connectors and everything else in the app; the editions are listed on Google’s editions page, including a pay-as-you-go edition.
AG-UI in your own app. No per-seat licence, but you build, host and secure the app yourself: sign-in, sessions, sharing and accessibility. Hosting on Cloud Run is cheap; the people cost is not.
MCP Apps. The HTML ships with an MCP server and renders in hosts that support it, so the cost is building and maintaining those pages, plus hosting the server if it is yours.

The misconception to name: “our own app is free because there is no licence”. The licence is replaced by an engineering team’s time, every month, for as long as the app exists.

The litmus test, cheapest first: do your users already have a front door that can host the agent? Use it. Do they need a few rich views inside hosts they already use? Consider MCP Apps. Only then build your own app with AG-UI, when the experience must live inside a product of yours.

Which choices move the bill most?

The choices that change how many tokens each question uses move the bill most; the choices of framework and protocol barely move it. Here is every lever from this part in one place, with Acme’s illustrative effect:

Choice                                    Effect on cost (Acme's numbers, illustrative)
Route in code, not with a model           saves about USD 0.005 a question (about 10%)
Flash for small steps, Pro only to write  the largest token lever (Part 13)
Cache stable prompts and tool lists       cuts cached input by 90% (0.15 vs 1.50)
Set thinking per step                     thinking can be over a third of a question (Part 11)
Filter MCP tools                          fewer tokens and fewer exploration calls
A2A only where ownership demands it       a specialist was about 35% of a question
Pay-per-use hosting for spiky traffic     no idle cost (Agent Runtime, Cloud Run)
Cap rows and scanned bytes                stops one query costing more than a month (Part 15)
Batch what nobody is waiting for          half price; most jobs done within 24 hours of starting
Reuse a front door people already have    avoids building and running your own app

My view: price the system per resolved question, not per call, and decide architecture on governance and quality first. Acme’s most expensive choices (A2A between teams, a Pro writer, a number check that throws answers away) are the ones that make its answers trustworthy. The savings come from making each of those steps lean, not from removing them.

Is it worth it? Compare with what the task costs today

A token price is not a business case; cost per task against what the same task costs today is. The question a budget holder asks is not “how cheap is a model call?” but “is the agent’s cost per task, including the people around it, lower than the way we do it now?”

Think of a shop deciding whether to install self-checkouts. Nobody compares the machine’s electricity bill with nothing. They compare the cost per sale at a staffed till (a cashier’s minutes) with the cost per sale at the machine (its running cost) plus the assistant who clears the “unexpected item” alerts, plus the sales that still go to a till because the machine cannot handle them. Mapped to an agent: the cashier’s minutes are the person who does the task today, the machine’s running cost is the tokens and hosting, the assistant is the human review, and the sales sent to a till are the questions the agent fails and a person answers anyway.

The misconception to name: teams quote the model cost (Acme’s USD 0.060 per resolved question) next to a salary and declare a saving of 99.9%. The review time, the failures and the fixed cost of running the system are all missing, and together they are far bigger than the tokens.

Here is Acme’s case, step by step. Every number except the cloud cost is illustrative:

Today: Maria asks Sam's supply team a cross-team question ("why did Verde's spend not turn into sales?")
  An analyst pulls supply_service in Databricks, joins it with campaign spend    45 minutes
  At an illustrative fully loaded USD 60 an hour                                  USD 45.00 a question
  Plus Maria waits a day or two for the answer                                    (not priced)

With the agent, per question asked:
  Cloud services (this part's estimate: USD 2,280 / 42,000 questions)             USD  0.054
  Maria checks the answer and its numbers, 3 minutes at USD 60 an hour            USD  3.00
  10% unresolved still go to an analyst: 0.10 x USD 45                            USD  4.50
  Licences and the people who run it, say USD 21,000 a month / 42,000 questions   USD  0.50
  Total                                                                           USD  8.05 a question

The tokens are under 1% of the agent’s real cost per question; Maria’s review and the fallback to an analyst are over 90%. That changes which levers matter: a better answer that Maria can check in one minute instead of three is worth more than any model discount, and raising the resolution rate from 90% to 95% saves USD 2.25 a question, about 40 times the whole cloud bill per question.

Why it wins. A question that is asked often, follows a pattern and takes a person real time today. If analysts answer an illustrative 3,000 such questions a month, that is 3,000 x USD 45 = USD 135,000 of their time; at USD 8.05 each the agent’s share is about USD 24,000, and the answers arrive in seconds instead of days.
Why it fails. A question asked twice a quarter, or one so subtle that checking the agent’s answer takes as long as doing the work. The fixed cost of building and running the agent is then spread over almost nothing, and review saves no time.

The hidden trap in the “wins” case: do not multiply the saving by the 42,000 questions the agent answers, only by the questions people were actually doing before. Many of the 42,000 are new questions nobody would have asked an analyst. They may be valuable (faster decisions), but they are new value, not saved cost, and a business case that mixes the two will not survive a finance review.

The litmus test, cheapest first:

What does one task cost today, in minutes times a loaded rate, and how long does the requester wait?
How many of those tasks are done today? That, not the agent’s traffic, is the multiplier for savings.
What does the agent cost per task once you add review time, failures that fall back to a person, and fixed costs divided by volume?
Only then compare, and report new questions answered as a separate line of value.

Lock it in
Term                     What it is                                             Everyday version
Cost per task today      minutes x loaded rate, plus waiting time               the cashier's minutes per sale
Agent cost per task      tokens + hosting + review + fallback + fixed / volume  machine + assistant + till fallback
Business case            the two compared, on tasks people actually do today    staffed till vs self-checkout
New value                tasks that only happen because the agent is cheap      sales you would not have made

My view: lead the business case with cost per task against today, and put the token maths in the appendix. In every estimate I have seen, the human time around the agent, and how often it gets the answer right first time, decide the case; the model price only decides whether you pull the levers above.

Where is the rest of the production checklist covered?

Cost is one of five things a production agent needs to get right. The other four each have a home in the series:

Concern         What it means                                        Where it is covered
Latency         time to first token, total time, showing progress    Part 11 (time to first answer token, traces)
                                                                     Part 13 (smaller models for fast steps)
                                                                     Part 12.75 (streaming progress to the user)
Reliability     rate limits, retries with back-off, timeouts,        Part 11.5 (retries, fallback ladder, idempotent
                fallbacks, idempotent tools                          tools, budgets)
                                                                     Part 13 (provisioned throughput for capacity)
Observability   trace every request: prompts, tools, tokens,         Part 11 (OpenTelemetry traces, usage ledger,
                latency, cost, user and outcome                      cost per resolved question)
Rollout         shadow, pilot group, gradual expansion,              Part 12 (shadow, 5% pilot, half, everyone)
                eval and monitoring as the gate                      Part 10 (the eval gate), Part 16 (what goes
                                                                     wrong when you skip a stage)

What can go wrong

Quoting model cost as total cost. Tokens are one line. Add data, licences and people before you quote a number to anyone.
Ignoring idle cost. An always-on app or warehouse costs the same at 3am as at 3pm.
Comparing list prices only. Discounts and committed-use agreements change the comparison; ask for both.
Counting per call, not per resolved question. A cheap model that fails more often can cost more per useful answer (Part 13).
Forgetting the data bill. A query that scans a whole table can outspend the model; cap bytes and rows (Parts 3 and 15).
Quoting token prices as the business case. Compare cost per task, including review and fallback to a person, with what the task costs today, and count only tasks people actually do now.
Letting prices go stale. Keep rates in one file with a date, as Part 11’s pricing.json does, and check them before every estimate.

What code did we write in this part?

Every part ends with the same map of Acme’s build: which files exist so far, and the code this part added, explained line by line. The map grows with each part.

This part adds no code to Acme’s build. It estimates a month of Acme’s cost at list prices and compares what each architecture choice does to the bill; the only blocks are worked sums and a comparison list, not code.

Where does it live?

router/                                             the router agent: extract, route, write
  app/agent.py                                      P5,8        workflow; extract reads memory; App with compaction and resumability
  app/app_utils/services.py                         P8          picks the session, artifact and memory services
  app/fast_api_app.py                               P8          Runner with session, artifact and memory services
  app/remote.py                                     P6,7        A2A client over mTLS; metadata carries Sam's token
  app/writer.py                                     P5,8        writer reads memories and saves the conversation to Memory Bank
  scripts/create_memory_bank.py                     P8          creates the Memory Bank and its topics, once
  tests/eval/acb_metrics.py                         P10         code metrics: route_correct, grounded, golden_numbers
  tests/eval/build_datasets.py                      P10         splits source cases into golden and held-out, seed 42
  tests/eval/calibrate.py                           P10         compares judge scores with human labels (kappa)
  tests/eval/datasets/golden_marketing.json         P10         golden cases with expected route, target and numbers
  tests/eval/eval_config.yaml                       P10         eval metrics, including the faithfulness judge
  tests/eval/gate.py                                P10         thresholds per metric; exits 1 when one fails
  tests/unit/test_router.py                         P10         unit tests; routing checked with one row per question type
marketing/                                          the marketing specialist, on BigQuery
  app/agent.py                                      P1,2,3,4    marketing agent with its skill in a SkillToolset
  app/app_utils/a2a.py                              P6          A2A endpoint and agent card (1.0 and 0.3) for marketing
  app/skills/marketing-kpis/SKILL.md                P4          marketing know-how: which tool, definitions, story checks
  app/skills/marketing-kpis/references/tables.md    P4          tables, grain, measures and the join rule, read on demand
  app/tools.py                                      P1,2        three narrow tools: measures, unserved demand, SQL fallback
  tests/unit/test_marketing.py                      P2          unit tests for the tools, with a fake context and database
supply/                                             the supply specialist, on Databricks
  app/agent.py                                      P3,7,8,9    supply agent and App with the confirmed replan tool
  app/app_utils/a2a.py                              P6          A2A endpoint and agent card (1.0 and 0.3) for supply
  app/skills/supply-catalog/SKILL.md                P4          supply know-how, given only to the supply agent
  app/tools.py                                      P3,7,9      supply tools; the replan tool asks a human first
shared/                                             code all three services share
  adk_common.py                                     P3,6,9,11   plugins and redacted JSON logs, now with the usage ledger
  auth_manager.py                                   P7          auth manager callback: token or consent (off by default)
  engines.py                                        P3,7        run_databricks connects as the signed-in user
  factcheck.py                                      P5          ungrounded_numbers: finds figures not in the findings
  registry.py                                       P2          reads semantic.yaml: measure names, computable measures
  routing.py                                        P1          classify: picks the specialist in code, no model
  safety.py                                         P9          per-user token bucket and injection pattern scan
  semantic.yaml                                     P1,2        registry of measures, owners and published formulas
  skill_source.py                                   P4          loads a skill from disk or a pinned registry revision
  sqlguard.py                                       P3          guard_sql read-only allow-list; redact for log lines
  tests/test_cost_report.py                         P11         unit tests for the cost maths
ops/                                                build, deploy and evaluation tooling
  .cloudbuild/eval_gate.yaml                        P10         after staging: eval run, then gate.py
  .cloudbuild/pr_checks.yaml                        P10,11      offline PR checks, cheapest first, ending with the mutants
  env.sh.example                                    P11         settings for every engine: ids, models, plugin switches, OTEL; no secrets
  infra/gateway/setup_gateway.sh                    P12         egress gateway, endpoint registry and IAP rules, in dry-run
  tools/cost_report.py                              P11         prices the ledger and reports cost per resolved question
  tools/mutants/acb_mutate.py                       P10         pytest plugin that injects each mutant's fault
  tools/pricing.json                                P11         list prices per model, kept out of the code
  tools/run_mutants.py                              P10         runs the offline suites once per mutant

+ added in this part   ~ changed in this part   Pn = the parts that touched the file

What did we learn?

An agent’s bill has eight lines: tokens, runtime, state, data, gateway, observability, front door and people.
At Acme’s illustrative traffic, model tokens are about 99% of the estimated cloud services, so model choices are the biggest cloud lever.
Frameworks are free; what costs money is how many model calls the design makes, where you host, and your team’s time.
Protocols are free; tool definitions cost tokens, wrapper servers cost hosting and time, and A2A costs a second agent’s calls.
Pay-per-use hosting (Agent Runtime, Cloud Run) has no idle cost; Databricks Apps bill per hour while running; where the data lives can outweigh both.
Token cost is tokens times price, times calls per task, times tasks per day: 20,000 in and 1,000 out, five calls, 10,000 tasks a day is 1 billion input and 50 million output tokens, about USD 1,950 a day on Flash; caching, a smaller model, smaller tool results and batch cut that example by about 84%.
Batch is half price on Agent Platform as of November 2026 (95% off cached input on Gemini 3 and later) but answers arrive within hours, not seconds, so it is only for work nobody is waiting on.
The business case is cost per task against today’s cost of doing it; for Acme the tokens are under 1% of the agent’s real cost per question, and review time and resolution rate decide the case.

What comes next?

With models and their cost settled, the series turns to knowledge in Production-ready agents, Part 14: Knowledge: RAG, long context, fine-tuning and the infrastructure behind them.

Sources

Opinions are my own. Every fact in this post comes from the public documentation linked above. Acme Consumer Brands and its data are fictional.