On the Microfauna of Megaprojects

In February I argued that the biggest machines of the next decade will need AI built into them as a control plane. I still think that's right, but the picture was too tidy. A control plane implies a clean hierarchy, with the machine at the bottom, a layer of intelligence above it, and people at the top. The systems I have in mind will be messier than that. A utility-scale quantum computer, an autonomous lab, an advanced chip fab, or a large robot fleet will end up inhabited by something closer to microfauna: large populations of small, specialized machine intelligences living inside the project and feeding on its telemetry, schedules, fault logs, work orders, and simulations.

Each one does a narrow job, usually a dull one, and the machine depends on all of them: watching one subsystem for drift, routing work, reconciling two sensors that disagree, sorting incoming faults, or trading off throughput against risk.

My own work on scientific agents is part of why I've grown impatient with the word copilot, which suggests something that sits next to a person and waits to be asked. These machines need operators that live inside the system and run all the time, and quantum computing is already heading that way. IBM's fault-tolerance plan is modular and adaptive. Decoded measurements come back in real time and can change the instructions that follow, the decoder is designed to be compact enough for an FPGA or ASIC, and the target for 2029 is 200 logical qubits running 100 million gates.¹ On Willow, Google's error correction works well enough that decoder latency has become a first-order systems problem, with delays of 50 to 100 microseconds already affecting performance.² PsiQuantum now talks in the vocabulary of manufacturing: tier-1 foundries, thousands of wafers, cryogenic cabinets designed to support hundreds of chips, and machines with a million qubits.³

The small agents arrive first

The same thing is happening outside quantum computing. Applied Materials describes chipmaking as a continuous chain of models, from atomic-scale materials simulation up to digital twins of the whole fab, running on millions of measurements and thousands of process variables, and says virtual studies that used to take weeks now come back the same day.⁴ The Commerce Department has funded a digital-twin institute for semiconductors whose stated goals are cutting development and manufacturing costs by more than 40 percent and cycle times by 35 percent.⁵ BMW is rolling digital twins out across more than 30 production sites, expects planning costs to drop by up to 30 percent, and says it's adding generative and agentic AI assistants to the system.⁶ Amazon has deployed its millionth robot, along with a foundation model called DeepFleet that it says should make the fleet's travel 10 percent more efficient.⁷

NVIDIA publishes blueprints for digital twins of robot fleets and of AI factories, with agents for power, cooling, networking, and operations wired together.⁸ Siemens and NVIDIA describe an industrial AI operating system and blueprints for fully AI-driven adaptive manufacturing starting in 2026, and PepsiCo is already using its new twins to catch potential facility problems before any physical changes are made.⁹

In science, recent Nature papers describe mobile robots doing exploratory chemistry and LLM-based systems that design, plan, and run experiments through tool use, and there's growing interest in treating self-driving labs as shared network infrastructure.¹⁰¹¹

I expect autonomy to arrive in all of these the same way, one role at a time. The roles are local and narrow, and they don't end; nobody finishes watching for drift. Take a fault-tolerant quantum computer. It needs agents that watch syndrome statistics, decide which qubits to recalibrate first, catch creeping thermal or RF problems, choose when to move work off a module, and turn application demand into actual resource commitments. A self-driving lab wants an experiment proposer, an instrument translator, a literature scavenger, and a safety clerk.

The project as an ecosystem

The agents that matter most will mostly look like janitors, dispatchers, inspectors, bookkeepers, and mechanics. One notices that a particular syndrome pattern in a quantum module is the early smell of a calibration slip. A second holds a process step because a metrology tool has started to drift. When someone moves a rack, a third reroutes the robot traffic. A fourth turns down an experiment plan because the solvent cabinet, the glovebox schedule, and the waste stream are all close to their limits.

The hard problem is keeping local order in a system that never stops moving, so I expect the winning pattern to be a society of narrow models with limited authority, shared state, and explicit law. Central planners are useful, but the combinations pile up faster than any single loop can absorb them. I find it helps to think of a megaproject as a habitat, with an immune system, a circulatory system, and a bookkeeping layer. An ecology like that can do a lot if the data model is clean and the rules are tight, and it goes feral quickly if they aren't.

It changes the shape of the organization, too. Project management stops being mostly meetings and starts to look like a live inference problem, with the schedule serving as the current best estimate of what the plant can actually do this week. Change control moves out of PDF procedures and into rules a machine can read. And the permission graph, the record of who or what is allowed to sense, decide, and act, starts to matter more than the org chart.

My aggressive bet is that by the early 2030s, the decisive moat in many of these systems will sit less in the headline hardware than in the ecology living around it. Two teams can have comparable robot cells, process tools, or qubits, even the same foundation models, and look about the same from outside. If one has years of replayable telemetry, shadow agents, simulator traces, policy history, and incident memory, its system will keep improving, while the other team's, running on dashboards, tickets, heroics, and tribal knowledge, will only be as good as whoever's on call.

Predictions

Some dated predictions, so I can be checked:

2027

Every credible fault-tolerant quantum effort runs agents in shadow mode for calibration prioritization, decoder tuning, workload admission, and failure diagnosis.

2028

At least one major fab, robot-heavy factory, or network of autonomous labs requires a live digital twin before it will commission a system.

2029

Large industrial systems start budgeting for inference, simulation, and policy infrastructure the way they budget for power, cooling, and cleanroom utilities. I'd also expect the first utility-scale quantum programs to find that their bottleneck is coordination: keeping the whole stack inside its useful envelope.

2030

"Operator headcount" needs an asterisk. Most consequential decisions inside a frontier lab, fab, or robot fleet have already been made, filtered, or scheduled by machine intelligence before a person sees them. People still set objectives, own the risk, sign off on escalations, and step in when something new happens, but they sit above the runtime, as its constitutional layer.

2032

Procurement, finance, and regulation catch up. Equipment that can't report structured state, accept commands through a policy layer, or take part in a replayable twin starts to look obsolete, and insurers and auditors ask for incident lineage, action traces, uncertainty thresholds, and proof that rollback works. By then the microfauna are part of the official operating model.

What to do now

Start with the data, and instrument the system on the assumption that it will host machine operators. High-rate telemetry, calibration histories, maintenance records, operator notes, work orders, simulator output, and control actions should all land in a shared event model, with stable identifiers and real timestamps. You can't grow useful microfauna in a swamp of screenshots, spreadsheets, and PDF procedures.

Stop treating digital twins as presentationware. Build them for replay, counterfactuals, and running agents in shadow. Every meaningful intervention should be testable against a twin, or at least a surrogate model, before it touches live hardware. Incidents should become training material, and near misses should be reproducible enough that an agent can learn from them without anyone rerunning the failure in the plant.

Write a machine constitution first. Most of the engineering here is permissions, and very little of it is prompt craft: what each agent may observe, propose, execute, defer, cancel, or escalate; how certain it has to be before acting; which invariants it may never cross; how its actions get rolled back when the model is wrong; and when a person has to sign. If a megaproject skips this step, its microfauna will grow by accident.

Then seed the ecology with a few narrow residents. Give one agent calibration prioritization and another maintenance triage, and give a third robot traffic, or experiment ranking, or reconciling metrology against throughput. Run them in shadow mode, compare them against the people doing those jobs now, and keep what they're allowed to touch small until they've earned more. At this stage you're trying to find out which organisms are useful, and under what constraints.

Finally, staff it like core infrastructure. The right team is a joint operating group of controls engineers, software engineers, domain scientists, reliability engineers, and whoever is accountable when the machine goes down.

By the end of the decade I expect megaprojects to be full of constrained machine operators, each doing a small share of the metabolic work that keeps the system alive. Early versions already exist. Whether they keep a project coherent or grow feral will depend mostly on whether anyone cultivates their habitat on purpose.