You built a personal routing policy, your spend got predictable, and life was good. Then you hired. Now there are five people, each with their own habits, and at least three of them default to the flagship at max effort because that’s what “good” feels like. Your careful discipline lived in one head, and it doesn’t scale to five.

This is where AI spend quietly becomes a real line item. A single disciplined dev is cheap. Five undisciplined ones, each burning premium tokens on boilerplate, is a budget bonfire nobody notices until finance asks about it. The good news: everything you learned as a solo builder still applies. It just needs a governance layer on top so the discipline survives contact with a team.

This is the last article in the series, and it’s about turning a personal habit into an organisational one.

The evergreen idea: individual discipline doesn’t scale — systems do

A routing policy in your head works because you’re the only one who has to follow it. Add people and that breaks in predictable ways: everyone has different defaults, nobody sees the aggregate spend until the bill lands, and juniors — reasonably — reach for the most powerful model because no one told them not to. None of that is a character flaw. It’s the absence of a system.

The fix is four layers, and they sit on top of the same routing policy from the last article — you’re not replacing the individual discipline, you’re making it shared, funded, visible, and enforced:

  1. Shared policy — the routing table, checked into the repo, so everyone inherits the same defaults instead of inventing their own.
  2. Budgets — a number per project and per seat, so cost is a plan rather than a hope.
  3. Visibility — spend dashboards and alerts, so surprises get caught early instead of on the invoice.
  4. Guardrails — safe defaults and a light rule that escalating to the flagship needs a reason.

Same policy underneath. The team layer is just what keeps five people spending the way one disciplined person would.

From a personal routing policy to team governance: four layers added on top of the same policy 4 · Guardrails Safe defaults; escalation to flagship needs a reason; juniors default to the workhorse 3 · Visibility Spend dashboards & alerts per person / project — surprises caught early, not on the invoice 2 · Budgets A number per project and per seat, so cost is a plan, not a hope 1 · Shared policy (checked into the repo) One routing policy everyone inherits — same conventions, same defaults, any model Underneath it all: the same task → model → effort routing policy from Part 6 The individual discipline doesn't change. The team just makes it shared, funded, visible, and enforced.

The current state (as of 19 July 2026)

Team plans are structured differently from individual ones, and the specifics move, so confirm current terms before you architect around them.

As of 2026-07-19:

  • Seats and shared pools: team/enterprise tiers from Anthropic and OpenAI bill per seat and often share an org-level pool. The meter underneath is the same one you learned as an individual — compute-hours or messages — just aggregated across the team. Confirm your plan’s exact pooling and per-seat caps; they’re not always obvious and they change.
  • Governance tooling: admin dashboards, per-seat and per-project spend views, and usage exports are increasingly standard on team tiers. Where the vendor doesn’t provide them, an API-gateway or proxy in front of your calls gives you the same visibility.
  • The models are unchanged: Fable/Opus/Sonnet/Haiku and Sol/Terra/Luna behave the same on a team plan. What changes is who can reach for the expensive ones and whether anyone’s watching.

Treat the plan mechanics as directional and verify against your admin console — team billing terms are among the fastest-moving things in this market.

The practices that make it stick

  • Check the routing policy into the repo. Not a wiki page people forget — a file next to the code (a README, a ROUTING.md, an agent-instructions file). This is the same move as building an agent-agnostic repo: shared, version-controlled behaviour that every person and every model inherits automatically.
  • Give every project a budget. A number, agreed upfront, tracked. It turns “how much did AI cost us?” from a year-end shock into a running metric you steer.
  • Make spend visible weekly. A simple dashboard or a Friday number. People spend more carefully when they can see the aggregate — not from pressure, just from awareness.
  • Set junior-safe defaults. New team members should land on the workhorse at medium effort by default, with escalation as an explicit, blessed step. Don’t make “reach for the flagship” the path of least resistance.
  • Review escalations lightly. Not a bureaucracy — just enough visibility that habitual max-effort-flagship use gets a gentle “did that need Opus?” It self-corrects fast.

Where the challengers fit for teams

Teams have a natural home for the challenger models: the automated, unattended lanes. CI checks, bulk migrations, test generation, batch transforms — high-volume work that runs without a human waiting on it — is exactly where a GLM or DeepSeek model, driven by a clear script, cuts cost dramatically with acceptable risk. Routing your team’s machine work to the cheap lane, while keeping human-interactive work on the majors, is one of the biggest team-level savings available, and the shared policy is where you write that rule down once for everyone.

The playbook

  • One shared policy, checked in. The routing table lives in version control, not in five heads.
  • Budgets per project and per seat. Cost becomes a number you plan to, not a surprise you absorb.
  • Weekly visibility. Dashboards or a shared figure; awareness does most of the work.
  • Junior-safe defaults, blessed escalation. Workhorse by default; flagship as a deliberate, visible step.
  • Route unattended work to the cheap lane. CI and batch to challengers; human work to the majors.
  • Re-check team plan terms. Pooling, per-seat caps, and admin tooling change; confirm against your console regularly.

The Khula Take

When AI spend starts to sting, the reflex — pushed hard by every vendor — is to buy more: bigger plans, more seats, a higher tier. We think that’s treating the symptom. Overspend on a team is almost never a capacity problem; it’s a governance problem. Five people with no shared policy will burn through any plan you buy them, and a bigger plan just raises the ceiling on the waste.

For a South African business, this is where real operating advantage hides. The competitor’s answer to AI cost pain is a fatter invoice. Yours can be a system: a shared policy, a budget, a dashboard, sane defaults — cheap to set up, and it turns AI from an unpredictable expense into a governed, plannable input. A disciplined team of five ships more per rand than an undisciplined team of ten, and that ratio compounds into margin you can reinvest, prices you can beat, and projects you can quote with confidence. Applied AI that grows a business isn’t the team with the biggest plan — it’s the team that governs the one it has. That’s the whole Token Economy, scaled: spend on judgement, save on everything else, and make the discipline something the organisation owns rather than something one careful person remembers.

Where this is heading

Enforcing a shared policy by hand — nudging escalations, watching dashboards, reminding juniors — is real management overhead, and it’s the last thing the Token Economy harness is built to absorb. The vision is a background router that applies the org’s policy automatically for every developer and every model, reports spend against each project’s budget in real time, and needs no one to police it. The Build-Estimator prices the work before it starts; the harness governs it while it runs; the policy is the shared brain behind both.

That’s the series. From “stop paying flagship prices for cheap work” to a governed team that routes every task correctly by default — done by hand today, automated tomorrow. Start with the shared policy in your repo, and verify the current team-plan terms against your admin console before you build governance around them; in this market, the fine print outruns the article.

Sources (July 2026): - Anthropic & OpenAI plan structures and admin tooling — platform.claude.com/docs, OpenAI Help Center - Team/usage limits (community/aggregator) — IntuitionLabs - Challenger pricing for automated lanes — docs.z.ai, api-docs.deepseek.com

Team plan terms, pooling, and admin tooling change frequently. Confirm against your admin console before architecting governance around any figure here.