Agent Economics: Pricing, Tokens, and Pods

Reading time ~12 min · Quiz at the end

Here is the industry's embarrassing secret, and if you've sat in a vendor pricing review in the last two years you've felt it: the same consulting firms that estimate a core-banking migration to two decimal places — story points, velocity charts, a Gantt chart with dependencies drawn to the day — cannot price an agent program within an order of magnitude. One vendor quotes $200,000 for a claims-triage agent. Another quotes $2.4 million for roughly the same scope. Both numbers came from a "proven estimation methodology." Neither vendor can tell you, with a straight face, why their number is right and the other is wrong.

This is not only a vendor competence problem. It is a category error: agent programs are priced with tools built for a different kind of work, and the mismatch produces numbers that are wrong in entirely predictable ways once you see the shape of the error.

Why phase-based estimation breaks for agents

Traditional software estimation — the kind that produces those two-decimal-place numbers — works because three things are usually true: requirements are stable enough to scope against, effort and delivered value correlate roughly linearly across thousands of prior projects, and the work proceeds through discrete milestones (design, build, test, deploy) marking real state changes. None of the three holds for a harness build the way they hold for a CRUD application or a data warehouse migration.

Requirements are not stable. You do not know how many edge cases your claims-adjudication eval set will surface until you build it, and it isn't stable until it's run against real production traffic for a few weeks — see lesson 12. A phase-gate that says "requirements sign-off, then build" assumes a scope you cannot pin down, because the real spec is discovered by running the system against messy inputs, not written down in advance.

Effort and value are weakly correlated. Two teams can spend the same three months on a support-ticket agent and produce wildly different outcomes — one resolves 40% of tickets end to end and is trusted by the org, the other is technically complete and trusted by no one because the eval bar was never defined. The delta wasn't hours worked; it was judgment about context, guardrails, and evals that a phase-based estimate has no line item for.

And the work is continuous, not milestone-delivered. A harness doesn't go from 0% to 100% done at a "go-live" milestone the way a migration does. It goes live at maybe 70% of its eventual reliability and improves every week through the loop in lesson 14 — new eval cases, retrieval fixes, guardrail tuning. Pricing this as a project that "completes" misrepresents what happens: the system keeps needing engineering attention indefinitely, at a lower but nonzero rate, for as long as it's in production.

Two paradigms, not one

The fix is not a better estimation formula. It's recognizing that agent work comes in two genuinely different economic shapes, and pricing each one on its own terms instead of forcing both through a single template.

PROJECT pricing treats the work as a scoped build with a defined outcome: build this agent, meeting this eval bar, integrated with these systems, for this price. Complexity — not hours — drives the estimate: how many integration points, how ambiguous the domain judgment is, how large the eval set needs to be to trust the result. The seller absorbs the effort risk. If it takes twice as long as estimated because the claims data was messier than anyone disclosed, that's the seller's margin problem, not the buyer's budget problem. This is the right shape for a bounded deliverable: a RAG-based knowledge assistant, a document-extraction pipeline, a first version of a triage agent.

CAPACITY pricing treats the work as a standing team — a pod — sold by composition, duration, and blended rate, not by deliverable. Team × seniority-blended rate × duration × an annual escalation factor. The buyer absorbs the scope risk: if priorities shift mid-engagement, or the eval bar turns out to require three times the guardrail work anyone expected, that's the buyer's call to make, because they're paying for capacity, not a fixed output. This is the right shape for anything that is genuinely ongoing: a multi-year platform build-out, an embedded team maintaining and extending a production harness, an agent program that will keep absorbing new workflows for years.

The doctrine here is simple and worth saying plainly: forcing a multi-year capacity engagement through a phase-based project template produces absurd numbers, and forcing a bounded three-month build through capacity pricing produces an open-ended bill for something that should have had a fixed price. Neither paradigm is superior. They answer different questions — "what will this cost to build" versus "what will it cost to staff" — and using the wrong one for the deal in front of you is where the order-of-magnitude pricing gaps come from.

A worked capacity example

Say a buyer needs a standing pod to build out and maintain an agent platform across claims, underwriting, and customer service over three years — new workflows keep getting added, so there's no fixed scope to price against. This is a textbook capacity deal. Here's how the math actually walks, using invented, round numbers for illustration.

Pod composition: 1 senior architect, 2 senior engineers, 7 mid-level engineers — 10 people total. Seniority-blended rate: the architect and seniors average $220/hour fully loaded, the mid-level engineers average $140/hour fully loaded. Blend across the pod: (3 × $220 + 7 × $140) / 10 = $164/hour blended average. At 1,800 billable hours per person per year (accounting for holidays, bench time, and non-billable overhead — a standard assumption, not a real timesheet), that's roughly $164 × 1,800 × 10 = $2.95M in year one before escalation.

Apply a 5% annual escalation — standard for a multi-year staffing commitment, covering wage inflation and retention costs — and the three years look like this:

Year 1: 10 people × 1,800 hrs × $164/hr blended           = $2,952,000
Year 2: same base × 1.05 escalation                        = $3,099,600
Year 3: same base × 1.05^2 escalation                       = $3,254,580
                                                    Total   ≈ $9,306,180

Depending on how you set the blended rate and utilization assumptions, a pod of this shape over three years lands in the $7M–$9M range — a wide but honest band, because it's driven by team composition and duration, not by a false precision about deliverables no one can specify three years out. That's the number a capacity-priced proposal should show, broken out by year, with the escalation assumption stated explicitly so the buyer can see exactly where the year-over-year growth comes from.

Now watch what happens if the same 10-person, 3-year ask gets run through a phase-based project template instead — what happens when procurement only knows how to evaluate "project" SOWs. The template decomposes the work into discovery (2 weeks), design (3 weeks), build (6 weeks), test (2 weeks), deploy (1 week), because that's the only shape it has. Someone estimates "build" at what a small team could plausibly ship in that window, and the whole exercise prices out at a 2-month, few-hundred-thousand-dollar engagement. Nobody lied. The template simply has no concept of a 10-person team sustained for 36 months — it assumes work terminates at a delivery milestone, and a standing pod has no such milestone by design. That's the absurdity the doctrine warns about: the wrong estimation tool applied to a shape of work it cannot represent.

Hybrid deals

Most real enterprise engagements aren't purely one paradigm. A common, sensible structure: a scoped RAG build — project-priced, fixed deliverable, tied to an eval gate — paired with a 4-person support pod, capacity-priced, that maintains and extends the system afterward. The project piece has a clear acceptance criterion (the eval suite from lesson 12 passes the readiness gate) and a fixed price the seller is accountable for. The support pod has no such gate, because "keep the system healthy and add workflows as the business needs them" isn't a deliverable you can fix a price to — it's the ongoing, discovery-driven work capacity pricing is built for.

Write these as two line items in one contract, not one blended number. Blending them recreates the confusion this lesson opened with: nobody can tell you what a single quarterly figure is actually paying for, because it smears a fixed-scope build and open-ended capacity into a number that answers neither "what will this cost to build" nor "what will it cost to staff."

The run-cost line

There's a third cost category that has nothing to do with labor and gets buried far too often: run-cost — the actual token spend of operating the agent, plus whatever caching infrastructure reduces it. Price this as its own line, separate from day rates or pod rates, for a reason buyers learn the hard way: per-conversation pricing compounds unpredictably. A vendor that quotes "$0.40 per resolved ticket" sounds precise, but that figure is a function of model-tier mix, prompt length, caching hit rate, and conversation length — all of which drift as scope grows and as the model provider changes pricing. Buyers who accepted per-conversation pricing as a simple abstraction have reported the same complaint industry-wide: the bill grows in ways that don't map to volume, because it's really three variables moving at once, disguised as one number.

Separate the run-cost line and make its levers explicit:

• Token costs — input and output tokens, priced per the model vendor's current rate card, with an explicit assumption for average conversation length and how many turns require full context reassembly versus incremental additions.
• Caching strategy — prompt caching on stable context (system instructions, tool schemas, retrieved policy documents that don't change turn to turn) can cut effective input-token cost substantially. State the assumed cache hit rate and where it comes from — a stable system prompt and static retrieved context cache well; per-user personalized context does not.
• Model-tier mix — see below; the split between cheap and frontier model calls is the single largest lever on run-cost, and it should be stated as a percentage split with the assumptions that justify it.

Escalate run-cost separately from labor too. Labor escalates at wage inflation (5% a year is a defensible planning number). Token pricing has, if anything, trended down as providers compete and efficiency improves — so a run-cost line escalated at the same rate as labor is not just imprecise, it's pricing the wrong direction on one of your two biggest cost categories.

Model-tier mix as a cost lever

The same discipline from lesson 3 — models are commodities, choose by task, not brand loyalty — becomes a direct line item here. Route the high-volume, well-specified slice of the workload (classify this ticket, extract these five fields, draft a first-pass summary) to a cheap, fast model. Reserve frontier-tier calls for the failure modes that are expensive to get wrong: ambiguous intent, novel phrasing, or the "plausible but wrong" pattern where a cheaper model produces a confident, well-formatted, incorrect answer that passes a shallow review.

A rough illustrative split for a mature claims-triage harness: 70% of calls on a low-cost tier for routine extraction and classification; 25% on a mid-tier model for cases the router flags as ambiguous; 5% on a frontier tier for cases that fail a confidence check or touch a high-stakes decision (claim denial, large payout, regulatory-flagged category). That mix, not any single model's sticker price, determines your real per-conversation run-cost, and you tune it over the system's life as eval data shows where cheaper models are safe.

That the opportunity is real and large is now measurable rather than asserted. Databricks (2026) instrumented its internal AI gateway and found that about a quarter of its engineers' real agent tasks were low-complexity and roughly sixty percent medium-complexity — yet engineers defaulted to the most expensive models for nearly all of it. That is the concrete size of the tier-routing prize: some eighty-five percent of the workload was, by the organization's own telemetry, a candidate to run on cheaper tiers, and almost none of it did. When you set the percentage split in your run-cost line, this is the empirical warrant for pushing the low- and medium-complexity slices down aggressively rather than leaving them on the frontier default out of habit.

Per-task cost, not per-token cost

The most expensive mistake in a run-cost model is to estimate it from the vendor's per-token rate card, because per-token price is a poor predictor of per-task cost. The two come apart whenever a cheaper-per-token model compensates by reading more and working longer. Databricks (2026) gives the canonical illustration: Sonnet 5 is about 1.7x cheaper per token than Opus 4.8, but on their real tasks Sonnet cost $2.09 per task against Opus's $1.94 — more expensive per finished task, while scoring six points lower on quality (81% versus 87%) — because Sonnet worked longer and consumed 1.9x more tokens end to end. A run-cost line built by multiplying a per-token rate by an assumed conversation length would have predicted the opposite ranking. The only way to see the real number is to benchmark candidate models at the task level, on a sample of your own workload distribution, exactly as the eval suite from lesson 12 lets you do.

The harness is a run-cost lever too

Most cost models stop at model choice and tier mix, and in doing so they miss a lever that moves cost as hard as the model does: the harness itself. This is the run-cost analogue of the argument the rest of this course makes about capability — the harness, not just the model, determines the outcome. Databricks (2026) ran the same model at the same thinking effort through different harnesses and saw cost per task differ by more than 2x with quality unchanged. The driver was how much context each harness fed per turn: a leaner harness sent roughly 3x less context per turn, kept a tighter working set, and finished in fewer turns. Same model, same quality, half the bill — decided entirely by the scaffolding. When you audit a run-cost line, the tier mix is the first lever but not the last; how the harness manages context per turn belongs in the same conversation, because a wasteful harness can quietly double your token spend while the pricing page and the model choice both look correct.

Unit economics for the buyer

None of this pricing exercise matters if the buyer can't answer the only question that determines whether the program is worth running: cost per resolved ticket, or per processed claim, measured against the human baseline — not against zero.

A vendor proposal that says "$0.60 per ticket resolved by the agent" sounds cheap until you ask what it's compared to. If a human resolves the same ticket at a fully loaded cost of $4.50, the agent wins clearly even after the run-cost line, amortized pod cost, and residual human review. If the human baseline is actually $0.80 because the ticket type is already automated with simple rules, the agent program may not clear its own cost, no matter how elegant the harness.

Build this comparison into every proposal and every quarterly review. It's the only number that answers "was this worth it," and it forces the run-cost and pod-cost lines to be stated honestly, since they have to sum to something comparable against a real baseline instead of floating as an abstract cost center.

A buyer's checklist

Whatever the vendor's slide deck says, demand these five things be explicit in any agent proposal before you sign:

• Pricing paradigm named. Is this PROJECT (fixed deliverable, seller absorbs effort risk) or CAPACITY (team and duration, buyer absorbs scope risk)? If the proposal won't say, it's probably hiding a mismatch between the deal's real shape and its pricing structure.
• Run-cost separated. Token cost, caching assumptions, and model-tier mix broken out as their own line, with their own escalation assumption — not buried inside a day rate or a per-conversation number you can't audit.
• Eval gate defined. What specific, numeric bar (from lesson 12) does the system have to clear before it's considered "done" (for a project) or before scope expands (for a capacity engagement)?
• Rollback priced. What does it cost, in time and money, to disable the agent and revert to the human process if it fails to meet the eval bar in production? If the proposal has no answer, the vendor hasn't planned for failure, which means you're the one who'll improvise it.
• Telemetry ownership stated. Who owns the logs, the eval results, and the cost data after the engagement ends? If the vendor owns the telemetry, you cannot audit your own system's performance without going back to them — which is a lock-in risk dressed up as a convenience.