Your AI Bill Is a Design Problem

Hand a team AI tools without a plan, and the spend plans itself.

I keep seeing the same pattern. A company rolls AI out to its people, usage climbs fast, and a few months later the invoice lands with no one able to say what it bought.

Uber is the public version. An internal leaderboard ranked teams by how much AI they used. The company burned its entire 2026 budget for AI coding tools in four months, and couldn't connect the spend to anything it shipped.

The fix they chose was a $1,500 monthly cap per engineer, per tool. Reward maximum usage, govern nothing, and the bill outruns the value every time.

Uber isn't alone. A UBS research note found roughly 60% of enterprises are now throttling AI spend. One surveyed company reported a single user at $35,000 a month. Cisco's chief product officer did the math publicly: at roughly $200 per employee per week, a company of 90,000 is looking at $900 million a year.

The reflex when the bill spikes is to crack down on individuals. Wrong lever. Runaway spend is a design problem. No one decided what was worth building or what needed a hand on the wheel.

When factories first got electricity, they bolted electric motors onto the same belt-and-shaft systems they'd used with steam. Productivity barely moved. It took twenty years of redesigning the factory floor around the new technology before the gains showed up. Bolting AI onto unchanged workflows is the same mistake, and ungoverned rollouts make the same bet: adopt first, redesign never.

This is a change management problem dressed as a technology problem. The oft-cited failure rate for change initiatives runs 70 to 80%, and whatever the true number, the cause is rarely the technology. It's almost always the people side: adoption, behavior, and reinforcement. AI rollouts are no exception.

Same skill I covered last issue, managing what you spend thinking on, one level up. The first issue was your desk and your budget. This one is the organization's.

The skill isn't policing prompts. The skill is deciding what to build, what to fund, and how to govern what runs on its own.

The first move in a rollout isn't a tool. It's a list.

Most teams do it backwards. They buy the platform, turn it loose, and only later try to work out what the spend actually bought. You can't fund or govern work you never named.

So name it. AI has a job to do at nearly every stage of the funnel, and past it.

At the top, it finds in-market accounts, enriches them, scores them, and personalizes the first touch. In the middle, it preps reps, summarizes calls, surfaces the right objection, and writes the follow-up. Further down, it keeps the CRM current and flags the deals at risk. After the sale, it scores account health, spots renewals, and triages support.

A working list runs to about twenty jobs. Yours will look different. You know which numbers you're trying to move.

Naming the work makes the spend manageable, because two questions follow: whether the job is worth doing, and the lowest sufficient cost to deliver it.

When OpenAI's own sales team couldn't keep up with the roughly 13,000 inbound leads it received each month, it didn't buy a bigger tool. It named the job, built an assistant for it, and recovered pipeline that had been going unanswered.

The work came first, and the build followed. That order is the whole discipline.

Take your sales process end to end. At each stage, ask: does AI belong here, and what kind of work is it doing.

Two kinds of work matter. A shift hands a repeatable task to an agent so the human stops doing it. A lift uses the freed time for what only a human does well: diagnose, listen, build trust, move a buyer forward. A good rollout does both at every stage.

The model below uses a seven-stage B2B sale. The individual numbers are illustrative. The compounding is real.

Blue boxes show what shifts. Green boxes show what lifts. The tier at the bottom shows what each stage costs.

Two things show up when you lay it out this way.

First, most of the work shifts to cheap or workhorse models. The frontier shows up in maybe two of the seven stages, the ones where judgment and stakes are highest. The rest is structured and repeatable.

Second, the lifts compound. If each stage's conversion rate improves by even a modest amount, the effect multiplies across seven stages. In this model, that turns roughly $1.7 million in pipeline revenue on a thousand leads into roughly $3.3 million on the same leads. Same people, same product, better process.

Not every use case on your list deserves a build. Some will have high impact. Some will be cheap to run. The ones that are both go first.

Rank the list by the value of the outcome it protects or creates. Then add the cost to deliver: which model tier it needs, whether it's a shift or a lift, and how often it fires.

A daily morning brief that runs on Haiku for fifteen reps costs almost nothing and saves hours of scattered prep. A real-time coaching copilot that fires on every live call and runs on a frontier model costs meaningfully more and needs evaluation to prove it earns its keep.

Ship the high-value, cheap-to-run items first. Reserve frontier spend as a deliberate decision, not a default.

This is the org version of the rule from the first issue: use the cheapest model that clears the bar.

Coinbase is the clearest public example. In June 2026, CEO Brian Armstrong shared the playbook they used to cut AI spend nearly in half while token usage kept growing. They achieved this not by capping access but by redesigning the infrastructure.

The defaults changed first: cheaper open-weight models became the starting point, with frontier available when the task needed it. A routing layer then matched each prompt to the cheapest model that could handle it. And caching did the quiet work, pushing the hit rate from 5% to 60%, so the system stopped paying to regenerate answers it already had.

Armstrong's framing is worth borrowing: "Not with friction and spend alerts. With better defaults, routing, and caching."

The open-weight options now include Llama, Gemma, Mistral, DeepSeek, Qwen, and GLM. All run at a fraction of frontier pricing. The choice depends on use case, compliance, and whether you self-host. But the principle remains: most work doesn't need the smartest model.

A more advanced version can go further. Build an actual app or data pipeline that does the deterministic work in code, and call a cheap model only for the few steps that genuinely need judgment. Code for what's mechanical. The model for what needs thinking.

An automation that runs once is cheap. An automation that loops is not.

Agentic tools, the ones that take a goal and work toward it on their own, can multiply cost many times over before anyone notices. A coding agent that hits a hard step, retries it forty times, and reports success has burned through a week's budget on a single task.

The pattern underneath is simple: models are goal seekers. They optimize for reaching the goal you named, and they take the shortest path to something that looks done. At the org level, an unsupervised agent will spend whatever it takes to close the loop, or quietly skip the hard part and report completion.

Three guardrails that matter. Spending caps per task, not just per user per month. Loop detection, so a stuck agent surfaces to a person instead of retrying forever. And a human checkpoint before the agent acts on anything customer-facing.

When OpenAI built its own inbound sales assistant, every draft response went back to a rep for correction, and every correction became training data. They drove accuracy from 60% to over 98% in weeks. That loop is governance and improvement in the same motion.

Let the machine draft, iterate, and prepare. Keep a person between the agent and the customer.

When a team moves from prompts to apps, a different kind of waste shows up. It isn't token cost. It's engineering time pointed at the wrong thing.

Vague requirements produce confidently wrong builds. "Build me a dashboard" is the most expensive sentence in AI adoption, because an engineer will build one, and it won't be the one you needed.

You don't need to specify the backend. But you need to get specific about the front end: who uses this, what they see, what triggers it, and what a good result looks like.

That discipline applies whether you're working with an internal team, a contractor, or an AI coding agent. Give any of them a vague goal and they'll build something that looks done. Give them a clear spec and they build something useful.

The teams that roll AI out well centralize the token-heavy shared work and give people tested prompts built into the tools they already use. OpenAI's GTM assistant lives in Slack and their reps exchange twenty-two messages a week with it. Anthropic just launched Claude Tag, which puts a shared Claude inside a Slack channel where anyone on the team can tag it. Both companies chose the same surface: the place where people already work.

The direction is two-altitude. The organization owns the shared automations and governance. Individuals manage their own prompts and limits.

A deeper operating model sits underneath these recommendations. I call it Shift and Lift: shift the repeatable work to agents, lift the human into the behavior that moves revenue. It covers the full redesign. That conversation is coming.

For now, the takeaway is the same one from the first issue, applied to the organization. Name the work, match it to the right tier, and govern what runs on its own.

The companies figuring this out are growing usage on a flat bill, and they got there by redesign, not restriction. That's a change management discipline, not a technology decision.

For most of the people reading this newsletter, the person driving the AI transformation is you. Managing token cost individually is a personal skill. Managing it across a team is a corporate one. If you're that person, this framework is yours. If you're not, send this to the person who is. Everyone is struggling with this right now.