AI Economics
Revenue Ecology Zones
On Mount Washington in New Hampshire, you can walk from hardwood forest into spruce and fir. Higher up, the trees become stunted and grow close to the ground. Eventually you reach alpine tundra. Those conditions were there before you started climbing. As you move up the mountain, you enter places where different things can grow.[1]
I've been thinking about the AI boom in those terms. We look at a company's extraordinary revenue growth and project it forward five or ten times. But who will spend that money? What will they need to do with the product? And what has to change in their businesses before that spending makes sense?
Conceptual illustration. Revenue ecologies can coexist and overlap; they are not a universal revenue ladder.
Suppose a company grows from $1 billion to $10 billion in revenue. The temptation is to extend the curve toward $100 billion. We already have demand. We already have customers. We just need more capacity. Except the customers who can support the next $90 billion may need something very different from the customers who supported the first $10 billion. Before extending the curve, we have to understand who those customers are and what would make them spend that money.
You cannot take the present conditions and extrapolate them to a business five or ten times larger. I think of these different economic environments as Revenue Ecology Zones. Each is organized around work the customer needs to accomplish, the conditions under which they will pay, and the capabilities the supplier needs to deliver it. A company crosses into another ecology when growth requires serving a different set of those requirements.
The same customer can participate in several. Consider an enterprise using AI to help employees summarize documents. Now consider that same enterprise authorizing AI to approve and execute payments. The second use requires control over who can authorize a transaction, limits on what the system can do, and a way to investigate and correct mistakes. The customer is the same. The work and the responsibility have changed enough that a supplier could serve the first use well and be completely unprepared for the second.
AWS's early self-service model let developers obtain computing resources without buying and managing servers. A developer could start using the service and build something. APIs, documentation, and technical help were central to making that relationship work.
An enterprise considering a major migration had more to resolve. What would happen to its existing applications? Who would handle a failure? What would its security and legal teams require before the company could commit? Moving that business onto the cloud required AWS to develop capabilities beyond making compute available.
AWS hired Mike Clayville to build its enterprise sales organization. It developed deal-desk capabilities for complex transactions, legal processes for getting contracts completed, and training that helped sellers discuss business outcomes. It also brought in former CIOs who could work through the organizational questions with customer executives. Mark Schwartz, formerly CIO of U.S. Citizenship and Immigration Services, joined AWS in 2017 to work with enterprise technology leaders.[2]
A deal desk could structure a transaction that a self-service purchase could never accommodate. Legal processes could get the agreement through the customer's procurement system. A former CIO could discuss the difficulty of changing an IT organization with someone who was responsible for doing it. More servers alone would not have given AWS those capabilities. AWS had to build the organization that could earn the enterprise revenue, while continuing to serve developers through self-service.
There is also room to grow within an ecology a company already understands. Suppose a supplier helps a data engineering team ingest data faster. The next delay may be transformation, followed by the work needed to keep the data reliable. Understanding that sequence can reveal additional work the supplier could be paid to do. It has a reason to develop the next capability because it can see how that capability improves the customer's output. Growth can come from solving more of a customer's connected problems, without finding an entirely different kind of buyer.[3]
Before raising or spending capital, we can ask how much opportunity remains in the work we already understand. What would we have to build to serve another ecology? The missing capabilities, the cost of building them, and the revenue they could earn give us something concrete to compare.
For AI, the supplier and customer both have work to do. A company moving invoice processing onto AI has to connect the system to purchasing and accounting, decide which exceptions it can handle, and assign responsibility when something goes wrong. A supplier hoping to earn that company's operating budget needs the ability to help it make those changes. The next stage of revenue depends on completing work on both sides of the sale.
On October 2, Anthropic announced a $100 million commitment to train 10,000 Frontier Deployed Engineers by the end of 2027. The program includes a 12-week residency in which engineers lead a Claude project inside their own organizations. Accenture, Morgan Stanley, and Novo Nordisk are among the participants.[4] Anthropic is committing money to help customers build the capabilities needed to use its product at scale. The lab's next stage of growth depends in part on what those people can accomplish inside their companies.
And as customers learn how to use AI, they can also learn how to spend less on it. In my own operation, I put Tycho, my FINOPs agent, in charge of finding out where we could lower our AI costs. He ran on a frontier model. He helped us select a cheaper competing model, then figured out how to cache the same instructions we were sending millions of times. We were using expensive intelligence to reduce how much expensive intelligence we needed to buy.[5]
Think about what that does to the revenue forecast. Suppose the price of a job falls from $10 to $2. A customer can run five times as many jobs and spend exactly the same amount. The customer gets five times the work. The supplier gets the same revenue. To double revenue at that lower price, the supplier needs ten times the original volume.
The customers expected to support the next stage of growth are learning both how to do more work and how to pay less for it. Some will buy far more because it has become affordable. Some will substitute cheaper models for work that used to require a frontier model. Some will redesign the work so fewer calls are needed. We have to understand what they will buy after they have learned how to use the product well.
Meanwhile, the labs and cloud providers have to order capacity ahead of that customer spending. In July 2025, OpenAI and Oracle announced an agreement to develop another 4.5 gigawatts of Stargate capacity. OpenAI said the agreement and its Abilene site brought capacity under development to more than 5 gigawatts, intended to run more than two million chips.[6] Buildings, power systems, and hardware have to be ordered while the customers expected to use them are still working through their own changes.
Follow the money upstream. The chipmaker sells hardware into the construction program. The cloud provider commits capital against expected utilization and customer contracts. The lab reserves capacity against the revenue it expects to earn. Eventually, customers have to spend enough for that chain to sustain itself. A long-term contract can assign the bill to another company. It still leaves that company needing the revenue to pay it.
Each company can make a reasonable decision based on the business it sees today. A lab running out of compute reserves more. A cloud provider with a signed customer commitment builds another data center. Investors see revenue growing and finance the expansion. The spending needed to support those decisions may depend on customers who are still learning how to put AI to work. Their implementation delays become a financial problem for the companies that have already committed the capital.
If compute availability is preventing a paying customer from doing more work, additional capacity can address it. If the customer is stuck on integration or responsibility for errors, the supplier needs different capabilities. Hiring people who can solve those problems may make the next stage of revenue possible. Ordering another generation of GPUs leaves those problems unresolved.
Customers can redesign their processes, produce more, and save money while also learning to route ordinary work to cheaper models. To support the infrastructure built for it, that success has to produce enough supplier revenue, at a price and on a schedule that can pay the bills. The revenue forecast has to explain how the customers get there, and the investment plan has to explain what the supplier will build to help them.
Back on Mount Washington, forest and alpine tundra coexist. A hiker moves between them. A company can also serve several revenue ecologies at once, developing different capabilities for each. Before financing a business ten times larger, I want to know where the additional spending will come from, what those customers need to accomplish, and what we have to build to serve them. We can test those capabilities with customers before committing capital on the assumption that the revenue will arrive.
Sources and notes
The U.S. Forest Service documents elevation-related changes in tree size and species composition on Mount Washington in Forest vegetation related to elevation in the White Mountains of New Hampshire, and describes the mountain's tundra and stunted spruce-fir communities in Alpine Gardens. Revenue ecologies can coexist and overlap. They need not form a hierarchy or follow fixed revenue thresholds. A transition can involve more customers as well as more spending per customer. The revenue and price calculations in this essay are illustrative; the proposed framework remains a working theory. ↩︎
The organizational account draws on the AWS material in my working REZ notes. Public sources corroborate specific parts: Stripe's August 2020 announcement identifies Clayville's prior AWS role as Vice President, Worldwide Commercial Sales and Business Development; AWS's Mark Schwartz biography records his July 2017 arrival and prior CIO role. AWS's June 2012 support announcement documents enterprise support with a dedicated Technical Account Manager and a 15-minute response time. The account of the deal desk, internal contracting processes, and selling training comes from the working notes. No exact founding dates or causal revenue attribution for those internal changes are asserted here. ↩︎
The summarization/payment and data engineering examples are explanatory scenarios, rather than reports of named customer deployments. A new job title, feature, or additional service alone does not establish another ecology. The distinction concerns changes in the work, purchasing economics, responsibilities, and supplier capabilities. Serving connected tasks can expand an existing relationship; it can also expose a boundary requiring different capabilities. ↩︎
Anthropic, October 2, 2026, Anthropic invests $100 million to train 10,000 engineers and tackle the enterprise AI talent gap. These are an announced funding commitment and training target, rather than completed spending or 10,000 graduates. The interpretation of their significance for revenue growth is mine. ↩︎
See my earlier note, Using AI to Save on AI. Its cost comparisons were projections for the full workload based on smaller probes. This paragraph describes our operating experience, rather than a measured industry-wide rate of substitution or a claim that every company follows the same path. ↩︎
OpenAI, July 22, 2025, Stargate advances with 4.5 GW partnership with Oracle. Figures describe the announcement at that date. Capacity under development is distinct from completed, utilized capacity. The announcement does not establish an annual cash-payment schedule; the essay does not calculate one or treat the wider Stargate investment ambition as OpenAI's sole balance-sheet obligation. ↩︎