Better models. A more complicated business.

Someone is paying for all this growth

On October 28, Microsoft reported 48% Azure growth and $18.6 billion in company-wide free cash flow. Alphabet's Google Cloud revenue grew 103% to approximately $30.7 billion. Meanwhile, capital expenditure of roughly $51.4 billion exceeded operating cash flow of about $42.3 billion. Very strong demand and a very large bill can coexist in the same quarter. [1] [2] [3]

Those figures do not establish who has solved AI profitability. Cloud revenue includes other services; cash flow belongs to entire companies with established businesses generating cash. They do, however, underline the distinction between the economics of infrastructure suppliers, model and application providers, and customers. Growth in one layer does not guarantee profits in the layers above or below it.

An infrastructure provider can earn money while its customer is still searching for a business model. A software company can grow subscription revenue while discovering that its most active users consume more compute than its pricing anticipated. An enterprise can save employees time without changing output, service quality or its budget. All three can happen together. “Growth” conceals the differences.

The supplier wants more usage. The customer wants less work.

Under consumption pricing, a supplier earns more when the system performs more operations. A customer benefits when it achieves a useful outcome at a reasonable cost. Sometimes those interests align. Sometimes an agent cycling through tools, repeating tasks and generating further checks increases the bill faster than it improves the outcome. Moving from payment per user to payment per action also transfers risk: more uncertainty about how the work will unfold lands with the customer.

Consider an illustrative organization processing 10,000 documents a month. Assume model execution costs one shekel per document, and each receives three minutes of human review at a labor cost of 120 shekels an hour. The model bill is 10,000 shekels; review adds 60,000. Halving the model price saves 5,000 shekels. Cutting review from three minutes to one releases labor time valued at 40,000.

That calculation does not establish a budget saving. If employees remain and no additional work gets done, time has been released but spending has not changed. Turning it into value requires deciding how to use it: more cases handled, shorter queues, stronger quality control or avoiding another hire. Integration and support costs are also excluded from this example. A discussion limited to model pricing can leave the most expensive part of the process out of view.

Microsoft offered a related detail on its earnings call: better CPU and GPU fleet utilization supported some growth. Lower-than-expected investment also reflected delayed deliveries. [1] The first can be an operational improvement; the second concerns timing. For an infrastructure supplier, extracting more revenue from existing equipment can matter almost as much as buying more equipment. The enterprise equivalent is getting more completed outcomes from a process, rather than counting how many people opened a tool.

Who can afford to wait for returns?

Meta's financing plan adds another dimension. The approximately $97.5 billion comprises $25 billion in common stock through forward sale agreements, $12.5 billion in convertible securities and a prospective program of up to $60 billion. This is not money already received, and the future program remains subject to conditions. [4] [5]

To me, the strategic implication is that financing capacity determines how long a company can wait for an investment to mature. A competitor with a good product can struggle against one able to fund years of aggressive pricing, spare capacity and experimentation. A large capital raise does not confer immunity, however. It adds investors expecting a return and raises the cost of a mistaken decision.

There is also a timing problem: a data-center commitment comes well before anyone knows which models will run there or what customers will pay for them. Equipment can remain technically functional while losing its economic advantage to a new generation. The relevant question is how many of its operating years will earn an acceptable return under the competition it faces.

Enterprise customers need not run a semiconductor company to understand the implication. A long commitment at a discounted price transfers part of the demand risk to them. I would commit where usage is already established. Where the organization is still discovering what works, flexibility has real economic value, even if the price list makes it look more expensive.

The work becoming cheap, and the expensive work left behind

On October 28, Google introduced Gemini 4 Carbon with an emphasis on sustained engineering tasks and cybersecurity. The company reports investigations continuing for days; initial access is limited to selected cyber defenders. These are supplier reports, not a performance guarantee for every enterprise. What interests me is the economic possibility: investigations once difficult to justify could become routine work. [6]

Every large system has work waiting because none of it is quite urgent enough: understanding an old component, reproducing an intermittent fault, examining a dependency nobody remembers choosing. If investigation becomes cheaper, we may not need fewer investigations. We may finally undertake the ones we postponed. AI could expand the amount of work worth doing, as well as reduce the cost of existing work.

That is a substantial opportunity, but it changes how a team operates. As producing proposed fixes becomes faster, the attention of the person approving them becomes more scarce. That expert must establish whether the finding is real, whether the fix fits the system and whether this is the right time to introduce it. Model execution can accelerate dramatically while the rate of production releases barely changes.

What does the model need to know to work here?

Suppose an agent identifies a duplicate authorization check and proposes simplifying it. Looking only at the code, that may be an excellent suggestion. But the duplication might have originated in a past incident, a contractual obligation or a distinction between user groups. If the explanation lived only in the head of someone who left, the model sees the structure without its rationale. Strong coding ability does not reconstruct missing organizational history.

This connects directly to the idea of a Company Brain. A searchable document collection can help retrieve an answer. Independent work also requires knowing which answer is current, what was decided, where it applies and who can change it. Two conflicting instructions are more than a search problem. A person can make a phone call to resolve them. An agent acting thousands of times needs an established way to handle that conflict.

Investing in this context means more than uploading files. It means preserving relationships between decisions and components, business rules and their owners, changes and the tests that validate them. Some of this already exists in code, service and knowledge-management systems. The work is connecting it and keeping it current. That is less impressive in a demonstration than a model fixing a bug, but it can determine whether reviewing the next fix takes ten minutes or a day of investigation.

Another model might perform some review. That can help, particularly when it receives independent tests and evidence. But two models relying on the same outdated instruction can agree and still both be wrong. Agreement alone is not quality control. For a code fix, stronger evidence is a test that reproduces the defect, fails before the change and passes afterward, alongside checks on behavior that must remain intact.

This suggests a way to expand authority gradually. Begin with investigation and proposals, allow tests and changes in isolated environments, and automate execution for categories of work where sufficient evidence has accumulated. An internal interface bug and a change to eligibility calculations need not follow the same approval path. Autonomy can vary by action even when the same model performs both.

The expert's role shifts toward defining what constitutes a correct change, with less time spent writing every change personally. That requires deep knowledge of the system and the business. An organization measuring only how much code gets written may weaken the very people who make that code trustworthy.

I would want a pilot that reaches the end of the process: discovery, remediation, review, release and follow-up. If investigation time falls but review effort doubles, we have learned where the next investment belongs. If review effort also falls while service quality holds, there is a credible basis for expansion.

The interesting possibility is manufacturing experience

It is easy to look at Genie 4 and see another improvement in image quality. Google introduced it on October 27 as a model generating interactive environments in real time, with audio and natural-language scene changes. Access remains limited to selected testers. [7] To me, the more interesting promise is the ability to create far more situations in which people and systems can gain experience.

Real-world experience is expensive material. It requires locations, equipment, people and time. Dangerous or rare events are difficult, sometimes unacceptable, to reproduce. Cheaply generating varied environments could support richer employee training and environments for training agents and robots. That remains potential, rather than a demonstrated Genie 4 outcome, but its economic significance goes well beyond an impressive video people can explore.

The opportunity is to reduce the cost of another trial. Teams could rehearse variations of an incident, developers could examine behavior when surroundings change, and planners could illustrate alternatives before committing to construction. As the cost of experimentation falls, ideas previously rejected because preparation was too expensive become testable. As with code investigation, some value may come from newly feasible work.

Who checks the world that teaches the agent?

The difficulty runs deeper than graphical mistakes. An agent learning inside an AI-generated environment can learn that environment's errors. If it consistently presents unrealistic behavior, success within it may be consistent and convincing without transferring to reality. Adding more scenarios does not eliminate a bias shared by all of them.

Google identifies limitations in consistency over time, interactions among agents, reproduction of real places and sessions lasting only a few minutes. [8] In a film, a slightly displaced object can be a visual defect. In an exercise teaching navigation around an obstacle, the same displacement could teach the wrong behavior.

Required accuracy therefore depends on the purpose. Rehearsing a difficult customer conversation does not demand a physically precise model of the room. Training a robot to grip an object demands fidelity to entirely different details. Buying “intelligent simulation” as a general category skips the important decision: which ability should improve, and how will we establish that the improvement transfers into actual work?

A municipal example makes this tangible. An exercise involving a blocked street might help a team identify missing information and coordinate a response. Participant decisions and response times could be evaluated. Using the same environment to decide where to deploy crews requires validated street data, congestion assumptions and travel times. A shared visual presentation does not give both tasks equal reliability.

A plausible development path combines approaches: data and specialized models determine what must be accurate, while world generation adds variety, visualization and interaction. This is an architectural proposal, not an established product capability. It also requires checking that the visual layer does not contradict the calculation it presents.

If this direction matures, organizations with strong operational data gain another asset. They can use it to calibrate environments, select meaningful scenarios and test whether the learning helps in practice. A model may generate a world; knowledge of reality determines which world is worth generating. That is a business reason to invest in data quality and operational history beyond producing more accurate reports.

I would not begin by promising a digital twin of an entire organization. I would choose one recurring decision, build an environment to rehearse it, and compare subsequent performance against real cases excluded from training. Demonstrating improvement there would establish a product. Until then, there is highly interesting technology and further work to do.