Let’s begin with the number sitting underneath the one in the headlines. According to the leaked draft, Anthropic has committed roughly $518 billion to compute over the coming years, and about $414 billion of that is non-cancelable, owed whether or not the company ever uses the capacity. Having spent more than a decade advising technology companies on their capital structure at J.P. Morgan, I can tell you that a commitment of that shape behaves far more like debt than like a flexible cost, and a company carrying it has only one way to service it, which is to pull the revenue through its customers. Anthropic, and OpenAI on broadly similar terms, now has to monetize those commitments, and that monetization lands on your invoice before it touches their margin.

The first consequence is that you should stop building budgets around the assumption that AI costs keep falling. The familiar story that inference gets cheaper every year is now running into several hundred billion dollars of fixed bills that have to be paid down over the decade, and the structural pressure that creates flows toward the buyer. I would model the AI line in your plan rising over the next few years and make whoever owns that forecast defend any assumption that it falls.

The second is that if you have standardized your workflows on a single model, you have taken on a counterparty whose solvency you ought to be underwriting the way you would any critical supplier. By outside estimates, Anthropic needs to reach around $134 billion in annual revenue by 2028 simply to break even against these obligations, and a dependency of that size belongs in your risk register and your board materials well before your engineering roadmap.

The third is the one I rarely hear discussed, and it is the closest to home. The same committed-spend structure that will make or break Anthropic has become standard in the AI and cloud contracts your own company is signing. I have been on both sides of these deals, structuring committed-use agreements while running the commercial side at AWS and signing them as an operator since, and the pattern holds every time. The discount that comes with a multi-year reserved commitment is genuine, and so is the obligation underneath it, which surfaces the moment your usage comes in below what you promised to buy. The discipline is to model that downside before you sign.

None of this is a verdict on Anthropic’s bet, which is Anthropic’s to win or lose. The questions that actually touch your P&L are how much of it you are now riding on, and how much of your own spending you have already committed on exactly the same terms.

The way I see it, the largest AI company in the world just partnered with two of the largest PE firms in the world to build a company whose entire purpose is making AI deliver what it promised. That is a public admission that the implementation gap is real, it is widespread, and nobody has cracked it yet.

Every conversation I have had with PE operating partners and portfolio CEOs over the last year circles back to the same pressure point: AI needs to move the return, not just the narrative. The dynamic I keep seeing in PE-backed software and services companies follows the same pattern every time. First, the GP announces an AI strategy. Then, the portfolio company CEO gets a mandate to deliver on it. And somewhere between those two things, the actual work of changing how the business operates gets lost. The timeline for AI to deliver results and the timeline for a PE exit are structurally misaligned. Quarterly targets, board updates, and IRR pressure do not accommodate the pace at which AI compounds.

Ode was built on the acquisition of Fractional AI, a team of former technical founders with hands-on AI engineering experience across financial services, healthcare, retail, and manufacturing. That profile, someone who can sit with a CEO, understand why their revenue is stalling or their support costs are rising, and then build something that changes it, is the rarest hire in enterprise AI. I have spent the last decade being exactly that person inside some of the world’s largest organizations. Ode is betting that industrializing that profile at scale is the answer to the implementation problem.

It might be. But the question the announcement does not answer is the one I would ask first: does embedding engineers inside a business change the accountability structure, or does it add another sophisticated layer on top of an already broken one?

In every organization I have worked in or with, the businesses that close the implementation gap share one thing. It is not the quality of the engineers. It is that someone inside the business, with real accountability for a revenue or cost outcome, owns the result before the first line of code is written. When that is in place, the implementation has a fighting chance. When it is not, the most talented team in the world produces work that nobody acts on.

Ode with Anthropic is the most serious structural bet the industry has made on solving this problem. Whether it works depends on something no external firm can install.

The conversation that followed is predictable. If one person can build a billion-dollar company with AI, imagine what a large enterprise with thousands of employees and billions in resources can do. Most commentators stopped there. I want to take it further, because I think the more interesting question is not whether enterprises can become Medvi, but whether there are pockets inside every large enterprise where the conditions that made Medvi possible already exist.

Renting the infrastructure

I would argue that Gallagher did not build anything new. He rented existing telehealth infrastructure that the rest of the industry spent a decade and hundreds of millions constructing, pharmacy networks, regulatory frameworks, payment rails, medical review systems, and fulfillment infrastructure. He then used AI to compress the customer-facing layer above it into something two people could operate. The product itself is a single repeatable transaction: a patient fills out a form, an AI-assisted triage process routes it to a doctor, a medication ships. No competing internal stakeholders, no legacy technology systems, no inconsistent data definitions, no workforce that needs to fundamentally change how it operates before any of this can work.

What made Medvi possible was not AI alone. It was the combination of AI and a set of conditions that eliminated the organizational complexity that makes scaling AI so hard everywhere else. It was built in a greenfield environment with a single homogenous transaction at scale using existing infrastructure to build on top of, rather than rebuild from scratch.

The enterprise version already exists

The conditions under which Medvi exists are not unique to startups. They are present inside almost every large organization, hiding in the segments that the core business has always considered too small or too fragmented to invest in properly.

The long tail of any large business, the thousands of small accounts, small merchants, small customers that generate individually modest revenue but collectively represent significant scale, almost always meets Medvi’s conditions. The transactions are homogenous and repeatable, and the infrastructure already exists. The problem has never been the complexity of serving these customers. It has been the unit economics of staffing human coverage at that volume. I have seen this work firsthand and wrote about it in a previous edition of this newsletter, which describes how I build and ran an AI agent to double revenue.

The takeaway from Medvi is not that large organizations should try to operate with fewer people. It is that the Medvi playbook, finding a homogenous high-volume process, building AI on top of existing infrastructure rather than rebuilding everything, and eliminating the organizational complexity that slows everything else down, is replicable inside the walls of any large enterprise if you know where to look.

The places to look share a few characteristics. They are typically high volume and low variability, meaning the same interaction happens thousands of times with minor differences each time. They sit on infrastructure that already exists and already works. And they have been chronically underserved not because the business does not want to serve them, but because the economics of human coverage never made sense at that scale.

One filter matters above all others before committing to any of these segments: the AI intervention has to connect directly to a revenue or margin outcome, not just an efficiency gain. This is where most enterprises make a costly detour. They apply the same Medvi-style logic to their customer service function, their internal helpdesk, their HR processes, and they generate real productivity improvements that never show up in the P&L. Those are legitimate uses of AI but they are not the Medvi play. Gallagher built a revenue machine, not a cost reduction exercise. The enterprise equivalent is finding the segment where AI does not just reduce the cost of serving customers but actively unlocks revenue that was previously out of reach because of the cost of scale. The small business segment I wrote about doubled not because it became cheaper to operate but because it finally became possible to reach customers the business had always wanted to serve but never could at that volume and margin.

PwC’s CEO Survey Snapshot, published this month and drawing on responses from CEOs across 95 countries, found that just 20% of companies are capturing 74% of all AI-driven value. That concentration is not random. The companies capturing disproportionate returns found their ‘Medvi’, the pockets of their business where the conditions were already right and deployed AI there first, rather than attempting enterprise-wide transformation simultaneously.

Subscribe now

There is a part of every large revenue organization that is structurally unprofitable to serve with humans. The long tail of customers. Thousands of small accounts, each generating modest revenue, each requiring the same onboarding, billing support, upsell conversations, and renewal management as the largest customers. The unit economics never work. The struggle is always between whether you underserve these accounts, or you overinvest in them, and either way the P&L suffers.

I spent years staring at this problem. At a large P&L I led, the small business segment represented an enormous number of accounts but the revenue per account made human coverage economically impossible to justify. I was leaving money on the table at scale, and I knew it. The segment was growing organically but not nearly at the rate it should have, given the size of the market opportunity sitting in front of me.

The decision to build an AI agent to manage that segment end to end was one of the most consequential revenue decisions I made. The agent handled onboarding, product recommendations, billing queries, basic troubleshooting, and proactive outreach when usage patterns signaled churn risk. What happened next was not what I expected. The segment did not just become more efficient to serve, it doubled. The agent materially reduced cost to serve, while surfacing a revenue opportunity that human coverage had structurally prevented me from capturing. The accounts were there, the demand was there, but I never had a scalable way to reach them.

That experience fundamentally changed how I think about where agents create value in a revenue organization. The right question is not where AI can automate tasks, it is where an AI agent can deliver revenue outcome because human coverage does not scale.

What needs to be in place before you build

Three things are non-negotiable before deploying a revenue-facing agent.

First, your product and pricing data must be current, accurate, and accessible to the agent in real time. A customer-facing agent quoting the wrong price or describing a product that was updated six months ago is not a technical failure you can quietly fix. It is a commercial and reputational problem that lands with your customer immediately. In my experience, most organizations significantly underestimate how much work it takes to keep the knowledge base an agent draws from, genuinely current. This is the piece I would invest in first and most heavily before anything else.

Second, you need documented workflows for the scenarios the agent will handle, and equally important, clear escalation paths for the scenarios it will not. The biggest risk is not the situations your agent handles well. It is the situations it has not been trained for, where without a defined escalation path, it will either hallucinate an answer or get stuck in a loop that frustrates the customer. Every revenue agent needs a human in the loop or, at minimum, a human audit layer for edge cases.

Third, access to billing and finance systems must be governed carefully before an agent touches them. The permissions question, what can the agent read, what can it write, what requires human approval, needs to be answered explicitly before deployment, not after the first error surfaces.

What I deprioritized at the start was perfection. The goal of the first deployment was not a flawless agent. It was a good enough agent that handled the highest volume scenarios reliably, learnt from real interactions, and earned the right to be expanded over time. I reasoned that an 80% accurate agent deployed today with a feedback loop would generate more value and more learning than a 95% accurate agent still in testing six months from now. And that bet paid off.

Managing risk when the agent faces your customer

A revenue-facing agent carries a different risk profile than an internal tool. When it gets something wrong, the customer experiences it directly and immediately.

The risks I have navigated most in practice are wrong pricing, outdated product information, hallucinated answers to questions outside the agent’s knowledge base, and inappropriate handling of billing disputes. None of these are inevitable but all of them require specific design decisions upfront.

I deliberately kept the agent’s scope narrow at launch. I defined precisely which customer interactions it owns and which it hands off. I built explicit triggers for human escalation: billing disputes above a certain value, complaints that include specific language, scenarios that fall outside documented workflows. And I built a monitoring layer from day one that flags interactions for human review systematically, based on signals that predict a poor outcome rather than random sampling.

Treat the first three months in production as an extended test. The real world will surface scenarios you did not anticipate. The organizations I have seen scale agents successfully invest as much in the feedback and correction loop as they do in the initial build.

One agent or many

My strong recommendation is to start with one. Multi-agent architectures, where several specialized agents hand off tasks between each other, are powerful but they almost always require changes to backend legacy systems that take months or years to complete. I have watched agent projects stall before they deliver anything because the team pursued a multi-agent design from day one.

A single well-scoped agent with clear ownership, a defined set of scenarios, and a human audit layer will teach you more in three months of production than a multi-agent design will teach you in twelve months of planning. Once the single agent is performing reliably and you have a clear picture of where its boundaries are, the case for a second agent, and what it should do, becomes obvious from the data rather than theoretical.

The goal at the start is not to build the most sophisticated architecture. It is to put something in front of real customers, learn fast, and earn organizational confidence before you scale. That is how a neglected revenue segment becomes the fastest growing one.