Optimize the Economics and Stay Portable

Koko: Here is the one number that ties an AI agent to enterprise value. Not cost per token. Not cost per task. Cost per accepted outcome. Everything else in this lesson hangs off that idea, so let's make sure it lands hard before we move.

Max: Okay, cost per accepted outcome. I've seen plenty of business cases quote cost per token, cost per API call. What's wrong with those?

Koko: They're sticker prices. And sticker prices lie. Here's the analogy I keep coming back to: the two-dollar flight.

Max: Nobody actually flies for two dollars.

Koko: Right. Add the bag fee, the seat upgrade so you're not in the middle row next to the engine, and the cab from the airport that's an hour outside the city — suddenly the cheap fare is the expensive one. Cost per accepted outcome is the all-in fare. It's the only number that tells you whether the trip was actually cheap.

Max: So what counts as the bag fee and the cab in the agent world?

Koko: We'll get there — and the list is longer than most teams expect. But first, let's be precise about the word 'accepted,' because it's doing a lot of work. An outcome is accepted only when it clears four bars, not one.

Max: Four. Okay, walk me through them.

Koko: Quality: the result is correct and actually usable. Latency: it arrived fast enough to matter. Safety: it did no harm and took no action it wasn't authorized to take. And control: the required approvals and audit trail were actually in place.

Max: So a result that's accurate but took six hours to come back — that's not an accepted outcome.

Koko: Near-miss. You still paid for it. And a result that's fast but skipped the approval step? Same thing. Near-miss. You paid for it and you can't count it.

Max: That's a tighter definition than most clients use when they're building the business case.

Koko: Which is exactly why you name the four thresholds up front. It stops a client from quietly moving the goalposts later to make the numbers look better. If you don't define 'accepted' precisely at the start, the definition drifts toward whatever makes the dashboard look good.

Max: That's a governance move as much as a cost move.

Koko: Completely. Now, to understand why this number is so different from what most teams quote, think of it as a ladder with four rungs. Each rung hides cost that the one below it ignores.

Max: Okay, what's rung one?

Koko: Cost per attempt. Every call the agent makes, including the ones that go nowhere. Rung two is cost per successful task — runs that finished. But finished isn't good enough to keep. Rung three is cost per accepted outcome — only results that pass all four thresholds and survive review. And rung four is finance-validated value: the dollars a controller or a deal team will actually sign their name to.

Max: And most business cases are quoting rung one or two and calling it rung four.

Koko: Every time. And the gap between them is where credibility dies — especially when the CFO starts asking questions.

Max: So what goes into the full cost at rung three? What's actually in that number?

Koko: Inference, tool and API calls, compute, retrieval, storage — that's the part everyone counts. Then human review and the rework when a result gets bounced back. Then the cost of failures — the occasional wrong action and what it takes to clean that up. And then controls, assurance, monitoring, and ongoing support.

Max: The last three feel like they could dwarf the first one in a lot of real deployments.

Koko: Usually do. Let me make it concrete. Picture an agent handling customer dispute resolution — call it Northwind. The model is cheap per call, so the naive dashboard looks great. But half the agent's proposed resolutions get bounced back by a reviewer. The rework, plus the occasional wrong refund that has to be recovered, dominates the actual bill.

Max: So the dashboard is showing you rung one cost and you think you're winning.

Koko: Until you divide the real loaded cost by the disputes that were actually accepted and closed. That's when you get the honest cost of one resolved dispute. Only then can you put it next to the value of a resolved dispute at scale and know whether this thing should ship.

Max: Okay, here's the temptation though. If the cheaper model passes basic evals, isn't the call obvious? Cheaper model, lower cost — straightforward, right?

Koko: That's the trap. And it's exactly what clients say out loud. It only wins if you pretend review, rework, and failures don't exist. And those are usually the bigger half of the bill.

Max: So you could optimize the sticker price and actually make the true cost per accepted outcome go up.

Koko: While the dashboard says you saved money. A cheaper model that needs heavy human review can easily cost more per accepted outcome than a pricier one that clears review the first time. The instinct to build in is this: divide total cost by accepted outcomes and optimize that ratio. Not the model's per-token price.

Max: And there's a gate on top of that too, right? You mentioned blocking scaling.

Koko: Hard gate. You do not scale until the evaluated value stays attractive once the controls, the failures, and the human work are all inside the number. Scale a leaky cost structure and you just get bigger losses faster.

Max: Let me bring this into my world for a second. Say I'm building a business case for a global manufacturer — finance shared services wants to pitch a dispute or deductions agent to their own CFO. How does this framework change what I put in the deck?

Koko: Finance will not accept a token price as the cost line. They're going to ask for the fully-loaded cost per accepted outcome, with the review hours, the exception handling, and the control overhead named explicitly. Give them that number and the case holds up in the room.

Max: But here's where I've seen teams go wrong — procurement negotiated the lowest per-unit model rate, so they feel like the cost line is locked in and they're done.

Koko: The model rate is one line on rung one. The CFO is underwriting rung four. Review-and-rework labor, not the model, is where the money is. Procurement did their job. Now you have to do yours — which is building the full picture from attempt all the way to finance-validated value.

Max: So the model rate is almost a distraction at that point.

Koko: A useful input. A dangerous headline. The number that survives a CFO's scrutiny — and honestly, the number that survives your own — is cost per accepted outcome. That's the one you optimize. That's the one you take into the room.

Koko: So once a team actually has cost per accepted outcome on the scoreboard, the very next thing they do is reach for the wrong lever.

Max: The prompt. They go straight for the prompt.

Koko: Almost every time. And I get it — the prompt is right there, it feels like work, you can see the tokens shrink. But here's the analogy I want you to hold onto. You don't lower a household's energy bill by unplugging a phone charger while the boiler runs all night. The charger is the prompt. The boiler is your review labor and your rework.

Max: So shaving a few hundred tokens barely moves the real number.

Koko: Barely. The discipline is to find the biggest meter first, then act on it. And before you touch anything, you have to understand what you're actually trading on — because this isn't one number in isolation. It's a frontier: quality, consistency, latency, and cost. You cannot max all four at once.

Max: Every lever buys you one and charges another.

Koko: Exactly. So the question is never just 'did the token count fall?' It's 'did cost per accepted outcome fall?' Those are not the same question.

Max: Okay, so if the prompt isn't the lever, what is? What actually moves the accepted-outcome number?

Koko: There's a short list worth naming. Model routing — send the easy, common cases down a smaller, cheaper path and keep the expensive path for the hard ones. Context discipline — send less, cleaner input instead of dumping everything into the prompt. Caching stable context, batching where you can, running things in parallel. And tuning your retry and human-review thresholds — not maxing them, tuning them.

Max: And the biggest one?

Koko: Moving work to deterministic code. Anything that follows a fixed rule should not be a model call at all. That lever removes three costs at once: the call itself, the human review of that call, and any chance of a failure that needs cleaning up later. A fixed rule run in code doesn't get bounced. It doesn't need a reviewer. Every case you take off the agent is a case that stops charging the accepted-outcome ratio entirely.

Max: So the cheapest outcome is the one the agent never touches.

Koko: That's the line to remember. Write it down.

Max: Alright, but routing to a cheaper model still sounds like a big win. Route more cases to the small model, token cost drops — done, right?

Koko: That's the seductive shortcut, and it's wrong. If the cheaper model fails review more often, more results get bounced, rework rises, and cost per accepted outcome can go up even as cost per call goes down. You optimized the phone charger and quietly turned up the boiler.

Max: So a cheaper call that fails more is actually more expensive.

Koko: Per accepted outcome, yes. Cost lives in rework and failures far more often than in the model line item. That's the trap.

Max: What about consistency? That doesn't sound like a cost number at first.

Koko: It is, though, and it's sneaky. A lever that makes the average case cheaper but the results more variable quietly loads cost onto review — because reviewers have to check more of them. Consistency deserves its own line when you're reading the scoreboard.

Max: And latency trades too, right? You mentioned batching.

Koko: Batching is cheaper per unit, but slower to first answer. That's completely fine for an overnight run processing a thousand disputes. It's wrong if a customer is waiting on the phone. Same lever, different context, completely different trade.

Max: So raising the review threshold — letting the agent handle more without a human check — that's a lever too?

Koko: Yes, and it's one of the better ones when you use it right. You save reviewer hours. But only where your evaluation evidence says the agent is actually safe to trust there. Not everywhere. Not optimistically. Where the evals prove it.

Max: So the instinct is: measure where the cost actually is before you touch anything.

Koko: That's half of it. The other half is that you scale only when the evaluated value stays attractive after you've accounted for controls, failure modes, and full human effort. Both halves together.

Max: Let me see if I can put it on a real example. The Northwind dispute-processing scenario from before — how do the levers line up there?

Koko: Cleanly, actually. The clean duplicate charges follow a fixed rule. Route those to deterministic automation and off the agent entirely — biggest lever first. Cache the stable policy context so you're not re-paying to resend it with every single dispute. And raise the review threshold only on the dispute types where the evals show the agent clears reliably. Move those three, and the resolved-dispute cost from the first module falls far enough that the scale decision flips.

Max: Because the numbers — not the demo — decide whether it ships.

Koko: The numbers decide. The demo makes you want to ship it. The numbers tell you whether you should.

Max: Okay. Let me bring this into my world, because there's a version of this mistake I see constantly in private-equity value-creation work. A pilot cuts cost per call sixty percent. Somebody puts the run-rate saving straight on the EBITDA bridge. That's wrong, isn't it.

Koko: That is the trap in a suit. Think about a PE-backed business-services roll-up standardizing an agent across its operating companies. Every lever's claimed saving has to survive as accepted outcomes, and then as finance-validated dollars, before it earns a bar on the EBITDA bridge. A per-call saving that quietly raised rework is not EBITDA.

Max: Because rework is a real cost that doesn't show up in the per-call line.

Koko: Right. Only the portion that clears the full-cost test and gets the controller's sign-off goes on the bridge. If you put the gross run-rate number up there and rework ate half of it, the investment committee is going to discount the whole thing — and they should.

Max: So the instinct for a deal team is the same as the instinct for a builder: don't report cost per call. Report cost per accepted outcome, finance-validated.

Koko: That's exactly the standard. And it's not just discipline for discipline's sake — it's what separates a real bar on the bridge from a number that gets haircut in the room.

Koko: So we've got the scoreboard — cost per accepted outcome — and we've got our hands on the right levers to move it. But here's the thing that keeps me up at night when I watch teams build agents: the economics can be perfect and you can still be trapped. Trapped inside one vendor.

Max: Trapped how? Like, the agent works great, it's hitting the numbers, but you can't move it?

Koko: Exactly. The design lives inside one platform's features. When that platform changes its pricing, changes its product, or your client just wants to run on a different stack — you're not rewiring, you're rebuilding. So the doctrine that protects everything we've built is this: keep one canonical, platform-neutral manifest of the agent, and treat each platform as an adapter that implements that manifest.

Max: Okay, manifest. What's actually in it?

Koko: It's the same seven things this whole course has been building. The fit and purpose — why an agent at all. The authority matrix — who decides and who approves. The redesigned workflow. The tool contracts. The controls and recovery model. The evaluation suite. And the unit economics from the first two modules. Those seven travel unchanged across any platform.

Max: So everything that took real thinking to get right.

Koko: Everything that took real thinking to get right. And what's an adapter? The mechanical stuff underneath: the runtime, the tool-calling syntax, the hosting, the vendor's particular configuration knobs. Those are swappable. Moving from one vendor's runtime to another should be re-wiring adapters against the same manifest — never re-deciding the business, the risk, and the control model.

Max: Give me an analogy, because I want to make sure I'm picturing this correctly.

Koko: Shipping container. The same sealed box moves by truck, by rail, by ship. The port never unpacks it and repacks it — it just runs a crane built to the standard. Your manifest is the container. Each platform is a different crane. Standardize the box and the whole world can lift it. Design a box that only one crane can grab and you've handed that port control over your cargo.

Max: That's a really clean image. So the technique is — describe the agent in words no vendor owns?

Koko: Exactly. Name capabilities neutrally: a loop, tools, memory, evaluations, tracing, controls — those words belong to no one. Then keep a thin translation layer, a separate lens, that says how each of those lands on a given platform this quarter. That lens is what gets rewritten when you switch. The manifest doesn't move.

Max: Okay, I want to test my instinct here, because I think a lot of practitioners would say — look, if we're building on a platform, build around its marquee capabilities. That's how you get the most out of it. Isn't that just being smart about the tools you have?

Koko: That's the tempting-wrong answer, and it sounds like sophistication. But bind the design to one vendor's product surface and when that product changes — and it will — your whole agent gets rebuilt. You've outsourced your control model to a roadmap you don't own.

Max: Outsourced the control model. That's a sharp way to put it.

Koko: Think about the Northwind example we've been running through the course. The manifest says: the agent proposes credits, a human approves anything over the standardized threshold, damaged-goods insurance claims escalate out of its lane entirely, and the evals prove the approval gate actually holds. None of that is a vendor feature. It's business logic and risk logic. Swap runtimes and the authority matrix, the controls, the accepted-outcome economics — all of it comes with you. Only the adapter is rewritten.

Max: Right, because if the authority matrix — who can bind the company — lived inside a vendor's feature, then switching vendors means reopening that question.

Koko: That's the instinct to reward. The business, risk, and control model live in the manifest, not in any product. If a platform move would force you to reopen who can approve a commitment or which action needs human sign-off, your control model was living in the vendor's features. That's the failure to design out.

Max: Now I want to bring this to the PE and Fortune-500 world, because I think portability looks different there. You've got a fund with a dozen portfolio companies on completely different stacks. Or a large enterprise where each business unit made its own platform choice. What does a portable manifest actually buy you in that situation?

Koko: It buys you scale without rework. One validated agent design — a dispute agent, a deductions agent — deploys across all of those companies as adapters. The fund or the enterprise isn't re-underwriting the control model for each stack. They're just swapping the crane. And when a platform contract comes up for renewal, they can walk. That's leverage.

Max: Okay, so here's my last trap, and I think this one actually sounds strategic. The real anti-lock-in move for a portfolio is to standardize everything on a single vendor — one platform, best price at scale, consistent tooling across companies. That's the smart play, right?

Koko: That is the lock-in itself. You've just renamed it. Standardizing the manifest is portability. Standardizing on one vendor hands them pricing power at every renewal because they know you can't leave without rebuilding.

Max: So portability isn't just a technical property — it's actually a negotiating position.

Koko: Portability is what keeps the price honest. If the vendor knows the switching cost is rewriting an adapter, they compete. If they know the switching cost is re-underwriting your entire control model, they don't have to.

Max: That changes how I'd advise a client on platform selection entirely.

Koko: Good. Let's pull all three modules together, because that's where it clicks. Cost per accepted outcome is the scoreboard — the only number that captures what the agent actually delivered after you account for the review, the rework, the failures, and the cost of the controls that make it trustworthy. The levers on the frontier are how you move that number: you pull the right one for the bottleneck, and you scale only when finance-validated value survives the full loaded cost. And the portable manifest is what keeps the whole design yours as platforms churn beneath it.

Max: Fix the number, move the right levers, own the manifest.

Koko: That's the whole thing. Design the container so any crane can lift it, and you've protected every decision that was hard to get right. Keep sharpening this — the guided journey and the labs are waiting for you at KokoAI Academy on koko knows dot A I. Go build something that holds up.