SKIP TO CONTENT
AI Agents9 minAgents in Production / Ep. 7

What It Costs to Run 46 Agents in Production

Adam Boudjemaa
SHARE

KEY TAKEAWAYS

  • Inference is the smallest and most predictable line on an agent fleet bill. In the model below it is about 5% of the monthly cost of one agent.
  • The expensive lines are human review and engineering upkeep, and both scale with how much autonomy you granted, not with how many tokens you burned.
  • Burden per agent is not flat. It bends upward around the point where agents start sharing dependencies, because one upstream change stops being a local change.
  • The 46 agents were Integra internal operations. They are a different system from the 11-agent platform I shipped for a private-equity fund, and the two are never added together.
  • The cheapest agent in any fleet is the one you deleted. Retirement is a design feature, not an admission of failure.
~46
AGENTS I RAN
Integra internal ops, to Jun 2026
11
A DIFFERENT SYSTEM
the PE-fund platform, never summed
5
LINES ON THE BILL
only one of them is tokens

MODELLED, NOT MEASURED

The fleet size is real and so is the shape of the problem. Every dollar figure in this post is a model built from assumptions I state in full, priced at published list rates. It is an illustration of the ratio between the lines, not an invoice from any employer or client.

The bill nobody shows you

I deployed roughly 46 AI agents for internal operations at Integra, where I was CTO until June 2026. People ask what that cost. They mean the token bill, and the token bill is the least interesting answer I have.

Inference was the one line that behaved itself. Nothing else about running a fleet did.

The expensive part was everything that had to keep being true after launch. Nobody publishes that curve, so here it is, with the assumptions behind every number visible enough that you can disagree with them.

The bill people ask about

The token bill. It arrives monthly, it is metered to six decimal places, and you can cut it in an afternoon by routing to a smaller model. It was the cheapest and most predictable line I had.

The bill I actually paid

Everything that had to keep being true after launch. It is not metered, it does not arrive on a schedule, and no vendor dashboard tells you it went up. People carry it instead.

What the 46 actually were

First, the disambiguation, because these two numbers get merged constantly and I refuse to let it happen quietly.

The 46 agents were Integra internal operations: my own company, my own systems, past tense. They are not the 11 production agents on the GenAI platform I delivered for a confidential US real-estate private-equity fund with roughly $3B AUM. Different client, different codebase, different year. 46 and 11 do not add up to 57, and any page that sums them is wrong.

What I am not publishing is how those 46 split across functions. That was internal. What I will publish is the classification I used, because the tier an agent sits in is what actually sets its cost, far more than what it does.

The 11-agent build is documented separately in its own case study, and everything below is about the other fleet.

THE FLEET, BY AUTONOMY TIER
Layered stack diagram: 4 layers, top to bottomLayered stack diagram: 4 layers, top to bottom. Layer 1, TIER 0 · READS ONLY: Monitoring and alert triage, Log and metric digests, Internal knowledge lookup. Layer 2, TIER 1 · DRAFTS, A HUMAN SENDS: Recaps and status reports, Ticket triage and routing, Release notes. Layer 3, TIER 2 · ACTS IN A SANDBOX: Scheduled data pulls, Test and CI runs, Automation with a rollback path. Layer 4, TIER 3 · TOUCHES PRODUCTION: Human gate on every action, Full audit record, Never executes alone.TIER 0 · READS ONLYMonitoring and alert triageLog and metric digestsInternal knowledge lookupTIER 1 · DRAFTS, A HUMAN SENDSRecaps and status reportsTicket triage and routingRelease notesTIER 2 · ACTS IN A SANDBOXScheduled data pullsTest and CI runsAutomation with a rollback pathTIER 3 · TOUCHES PRODUCTIONHuman gate on every actionFull audit recordNever executes alone
Function tells you what an agent is for. Tier tells you what it costs. The same summarisation logic is nearly free at tier 0 and expensive at tier 3, because tier 3 buys a human into every action.

The five lines on an agent's monthly bill

An agent has five recurring costs. Four of them never appear in a vendor dashboard.

This is not a new observation, it is just an unfashionable one. The paper that named the problem for machine-learning systems said it plainly a decade ago.

Sculley and colleagues at Google put it like this in Hidden Technical Debt in Machine Learning Systems (NeurIPS 2015): it is common to incur massive ongoing maintenance costs in real-world machine-learning systems. Agents did not repeal that. They multiplied it by the number of agents.

WHAT AN AGENT COSTS EVERY MONTH
Layered stack diagram: 5 layers, top to bottomLayered stack diagram: 5 layers, top to bottom. Layer 1, 1 · INFERENCE: Input and output tokens, Retries and tool calls. Layer 2, 2 · PLATFORM: Orchestration and scheduling, Queues, storage, monitoring. Layer 3, 3 · DATA UPKEEP: Re-indexing, Schema and connector drift. Layer 4, 4 · HUMAN REVIEW: Reading escalations, Approving tier 3 actions. Layer 5, 5 · ENGINEERING UPKEEP: Prompt and eval maintenance, Dependency and model migrations.1 · INFERENCEInput and output tokensRetries and tool calls2 · PLATFORMOrchestration and schedulingQueues, storage, monitoring3 · DATA UPKEEPRe-indexingSchema and connector drift4 · HUMAN REVIEWReading escalationsApproving tier 3 actions5 · ENGINEERING UPKEEPPrompt and eval maintenanceDependency and model migrations
Five recurring lines. The one at the top is the one everybody budgets for, and the four below it are the ones that actually decide whether the fleet survives its second year.

A modelled bill, and every assumption in it

Here is one agent, modelled end to end. Every input is an assumption, and I am showing all of them so you can swap in yours.

The agent is a tier 1 internal-ops agent: it drafts, a person sends. It runs 2,000 times a month. Each run reads about 8,000 input tokens and writes about 1,000 output tokens. About 5% of runs escalate to a person, and each escalation takes 3 minutes to read and resolve. Loaded cost is $60 an hour for the reviewer and $80 an hour for the engineer, and the engineer spends 2 hours a month on this one agent. Platform and audit storage are the agent's share of shared infrastructure.

Token costs are priced at the published list rates for a small production model at the time of writing, $1 per million input tokens and $5 per million output tokens, per Anthropic's pricing page. Substitute your own provider and the ratio barely moves, because the token line is small either way.

Line
How it is derived
Modelled per month
Share
Inference
16M input tokens at $1/M, 2M output at $5/M
$26
5%
Platform share
Orchestration, queues, storage, monitoring
$25
5%
Data upkeep
Re-indexing and connector drift, amortised
$10
2%
Human review
100 escalations, 3 min each, at $60/h
$300
58%
Engineering upkeep
2 engineer-hours a month at $80/h
$160
31%
Total
Sum of the five lines above, shares rounded
$521
100%

Look at the two highlighted rows. A person reading escalations is 58% of this agent. Tokens are 5%. If you spend your optimisation budget on the model you are negotiating hard over a twentieth of the problem.

The lever that actually moves this bill is the escalation rate, and the escalation rate is a design decision, not a vendor choice. Set the abstention threshold too cautiously and you have quietly hired someone.

Where that threshold gets set, and what it is scored against before a release, is the job of the eval suite.

Why agent 40 costs more than agent 4

Burden per agent is not flat, and it is not linear either. It sits nearly flat for a while and then bends, and the bend is not caused by volume. It is caused by agents starting to share things.

These are the points where it bent for me. They are not a measured law, they are the shape I have watched repeat, and your inflections will land at different counts depending on how much you shared early.

THE BURDEN CURVE
1

Agents 1 to 3: upkeep is invisible

One person built them and still remembers every decision. Nothing is written down because nothing needs to be. The burden is real and unmeasured, which is why every fleet starts by underestimating it.

2

Around agent 6: you need a registry

Someone asks what an agent does, who owns it, and what happens if it stops. Nobody can answer from memory. The first fleet-level artifact appears, and it is not code, it is a list.

3

Around agent 15: shared dependencies bite

One retrieval index, one prompt template, one model id, one auth path, now shared. An upstream change stops being local. This is the inflection: the marginal agent is cheap to build and expensive to carry.

4

Around agent 30: the fleet is the job

Migrations, the shared eval suite, and the registry stop fitting into the gaps between features. Somebody now owns the fleet rather than any agent in it, whether or not that role has been given a name.

5

At about 46: you count owners, not agents

The useful question stops being how many agents run and becomes how many humans can be woken up for them. That is where I was when the role ended, and it is the number I would ask a team for first.

The burden curve, by inflection rather than by month. Each step is a thing that becomes impossible to do informally, and the bend at agent 15 is where sharing turns from a saving into a liability.

The migration line is not hypothetical. Model providers retire models on a schedule and give notice: Anthropic commits to at least 60 days before a public model is retired, and its own history shows several retirements landing in a single year. At 4 agents a retirement is an afternoon. At 40 that share a model id, it is a quarter of somebody.

The lifecycle nobody budgets for

The other thing missing from most cost estimates is that agents have a lifecycle, and most of it happens after the launch that everybody planned for.

Here is the loop as I actually ran it. Note where it does not end.

AGENT LIFECYCLE
Sequence diagram: 5 participants: Owner, Engineer, Agent, Reviewer, Fleet opsSequence diagram: 5 participants: Owner, Engineer, Agent, Reviewer, Fleet ops. Step 1: Owner to Engineer, Names a task worth automating and agrees to own the output.. Step 2: Engineer to Agent, Builds it, assigns an autonomy tier, and writes the evals that gate it.. Step 3: Agent to Reviewer, Runs, and escalates whatever it cannot support with evidence.. Step 4: Reviewer to Fleet ops, Flags the escalations that repeat, because a pattern is a bug not a workload.. Step 5: Fleet ops to Engineer, Raises a migration when a shared model, index or connector changes underneath.. Step 6: Engineer to Agent, Steps 3 to 5 repeat for the life of the agent.. Step 7: Owner to Fleet ops, Retires the agent when nobody has read its output in a month..OWNER > ENGINEERNames a task worth automating andagrees to own the output.No owner, no agent. This is the cheapestpossible refusal.ENGINEER > AGENTBuilds it, assigns an autonomy tier,and writes the evals that gate it.The tier is fixed here and is expensive toraise later.AGENT > REVIEWERRuns, and escalates whatever it cannotsupport with evidence.This is the recurring cost line, every month,forever.REVIEWER > FLEET OPSFlags the escalations that repeat,because a pattern is a bug not aworkload.Skipping this step is how review hours becomepermanent.FLEET OPS > ENGINEERRaises a migration when a sharedmodel, index or connector changesunderneath.Cost here scales with the number of agentssharing that dependency.ENGINEER > AGENTSteps 3 to 5 repeat for the life ofthe agent.OWNER > FLEET OPSRetires the agent when nobody has readits output in a month.The step nearly every fleet skips, and theonly one that reduces cost permanently.
The agent lifecycle as a loop, not a launch. Steps 3 to 5 repeat for the life of the agent, and the last step is the only exit.

The permission boundary that decides how much of step 3 a human has to touch is least privilege for agents that move money.

What I would cut first

If someone handed me a fleet bill tomorrow and asked me to halve it, I would not open the model routing config first. I would open the registry.

Here is the order I would actually work in.

THE ORDER
Decide: An agent costs more than it should. What do you do?Decision tree: An agent costs more than it should. What do you do? If nobody has read its output in 30 days, then Delete it. If the review line dominates, then Fix the escalation rate, or demote a tier. If the engineering line dominates, then Fix the shared dependency, not the agent. If the token line genuinely dominates, then Route it down, cache it, batch it.DECIDEAn agent costs more than it should.What do you do?IF nobody has read its output in 30daysDelete itThe cheapest agent is the one thatno longer exists. Retirement is adesign feature, and a fleet withoutone only grows.IF the review line dominatesFix the escalation rate, ordemote a tierEither the abstention threshold istoo cautious, or the agent is at atier it did not earn. Both aredesign changes, not model changes.IF the engineering line dominatesFix the shared dependency,not the agentRecurring upkeep on one agent isusually a platform problem wearingan agent costume. Fixing it oncepays across everything that sharesit.IF the token line genuinelydominatesRoute it down, cache it,batch itRare, and the easiest case. This isalso the only branch where a vendordashboard tells you what to do.
The order matters. Three of these four branches are design work, and the one everybody starts with is the one that pays least.

The uncomfortable version of this post is that a fleet of agents is mostly a staffing decision wearing an infrastructure costume. You are not buying tokens. You are buying the obligation to keep 46 things true.

That is fine, as long as you priced it. What kills fleets is discovering it in year two, from a person who quietly became a full-time reviewer without anyone deciding that they should.

For the wider picture of where this discipline is heading and who is being hired to do it, I keep a running read on the state of agent engineering.

And if the role itself is what you are trying to understand, what a forward-deployed AI engineer actually does is the wider picture this fleet work sits inside.

FAQ

Inference is the part everyone quotes and the part that matters least. In the model in this post, a single internal-ops agent costs about $26 a month in tokens and about $521 a month all in, because human review and engineering upkeep dominate. Those dollar figures are modelled from stated assumptions, not measured from an invoice. The useful takeaway is the ratio: tokens are roughly 5% of the line, and a person reading escalations is roughly 58%.

Because agents stop being independent. The first few share nothing, so upkeep is whatever their one owner remembers. Past roughly a dozen they share a retrieval index, a prompt template, a model id, an auth path. From then on an upstream change is not a local change, and a single model retirement means revalidating every agent that depended on it rather than fixing one.

No, and this matters. The 46 were internal operations at Integra, where I was CTO until June 2026. The 11 were a separate GenAI platform I delivered for a confidential US real-estate private-equity fund with roughly $3B AUM. Different clients, different systems, different years. They are never summed.

Delete agents. The second cheapest is to demote one a tier, so it drafts instead of acting and a human sends. Both beat model optimisation, because the review hours and the engineering upkeep are the lines carrying the cost, and an agent nobody reads costs the same as one everybody reads.

At small scale, no. The person who built them carries them and it is invisible. Somewhere past thirty the fleet itself becomes the work: the registry, the shared eval suite, the migration when a dependency retires. If nobody owns that, it does not stop happening, it just stops being done on purpose.

Agents in Production

Episode 7 · 10 published

Adam Boudjemaa

Adam Boudjemaa

Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.

Enjoyed this post?

Get more like it in your inbox every Tuesday.