Software agents are supposed to be weightless. They exist as weights in a file, as tokens streaming across a wire, as abstractions layered on abstractions. And yet one of America’s oldest manufacturers now expects to double in size because of them, according to its CEO. Two facts sitting uncomfortably close: the most abstract technology we have built is currently the best business case for heavy industry.
That tension is the story I keep coming back to. I spend my time thinking about agent architecture — planning loops, tool use, memory, how many inference calls it takes before a system stops being a chatbot and starts being a worker. Almost none of that thinking involves land, water, or transformers. The reporting piling up right now suggests that omission is becoming a design flaw.
Agents are the most physical software ever written
Consider what changed architecturally in the last two years. A single-turn model call is cheap and bounded. An agent is not. An agent decides how much compute it needs, and it decides at runtime. It reasons, checks its work, calls a tool, reads the result, reasons again. The same user request might consume five inference passes or five hundred depending on how hard the problem turns out to be.
This is a genuinely different demand profile than the one data centers were built for. Traditional web serving is predictable, spiky in known ways, and cacheable. Agent workloads are long-running, stateful, and self-amplifying. The more capable we make the planning loop, the more compute it chooses to spend. We designed a system whose appetite scales with its own competence.
Multiply that across every enterprise that wants agents handling support tickets, code review, procurement, and research synthesis, and the abstraction stops being weightless. It becomes megawatts. CNET’s framing — that these facilities are coming for land, water, and power — reads less like a warning about future risk and more like a description of the current build cycle. Consumer Reports is already tracking what this does to electric bills.
Why the industrial base is the tell
When a manufacturer with more than a century of history sees a path to doubling, that is a signal about the shape of demand, not just its size. Doubling a factory is not a software decision. It means capital commitments, hiring, supply agreements, and multi-year bets. Nobody doubles a plant because of a trend they expect to fade in eighteen months.
Even more telling is the coal story. Frontieras North America is reworking coal specifically for the AI economy — a sentence that would have sounded like a category error a decade ago. The energy source most people assumed was in terminal decline is being reconsidered because inference demand does not care about our preferred narrative arc. This is what it looks like when a workload outruns the infrastructure available to serve it: everything gets reconsidered, including the things we had already written off.
Kai Williams’ charts on the AI boom capture the aggregate curve. What the industrial reporting adds is the texture underneath — who actually has to build the thing.
What this means for how we build agents
I think the practical consequence for practitioners is that efficiency stops being a nice-to-have and becomes a first-class architectural concern. Not efficiency as cost optimization after the fact, but efficiency as a property you design for from the first sketch.
- Bound your loops deliberately. An agent with no compute budget is an agent with an unlimited one. Step limits, confidence thresholds, and early exits are not just safety rails — they are energy policy expressed in code.
- Route by difficulty. Most requests do not need your largest model. Cascading from small to large, with a cheap classifier deciding, is a solid pattern that too few production systems actually implement.
- Cache aggressively at the reasoning layer. Agents repeat themselves constantly across users. Semantic caching of intermediate plans, not just final answers, is underexplored.
- Measure joules, not just latency. If your evaluation suite tracks accuracy and response time but not compute consumed per resolved task, you are optimizing half the problem.
There is a version of the next few years where agent capability improves mostly through brute expansion — more racks, more power, more water, more land. There is another version where a meaningful share of the gains come from better architecture: smarter routing, tighter loops, models that know when to stop thinking. Both paths reach similar capability. They have very different footprints.
The uncomfortable coupling
What strikes me most is how tightly our design choices are now coupled to physical outcomes we never see. A researcher who adds three extra reflection steps to a planning loop, ships it, and watches accuracy tick up two points has also, at scale, moved a number on somebody’s utility bill and contributed to a decision about a power plant.
That coupling used to be too diffuse to reason about. It is not anymore. The manufacturers doubling their capacity are, in a real sense, responding to the code we write. Worth remembering next time a design review treats compute as free.
🕒 Published: