Deterministic AI Agents in Critical-Facility Engineering Workflows

Data center engineering is running into a wall that software engineering mostly hasn't had to face: physical irreversibility. A bad API call gets rolled back. A bad power calculation gets discovered six months later, when the switchgear is already on order and the energization date is already locked. That difference is what makes AI agents in this field a different category of risk than AI agents anywhere else, and it's the reason this piece exists.

Stochastic AI Behavior as a Structural Liability in Critical-Facility Engineering

Rack densities in GPU data centers built for AI training and inference have moved past what air-cooled design workflows were ever built to handle. The engineering decisions behind a modern AI-focused build, power distribution, cooling capacity, cable routing, are denser and more tangled together than they were even five years ago, and that makes them harder to inspect at every stage.

Lead times compound the problem. Medium-voltage switchgear can take years to procure. A single bad decision in a power or cooling calculation shifts the energization date by an entire procurement cycle, because the misordered component has to be reordered and the queue starts over. There's no patch release for a transformer.

The money at stake makes the margin for error smaller still. A delay in commissioning costs real revenue every month the facility sits unpowered, at a scale that rules out "catch it in QA" as a serious engineering posture. By the time quality assurance would catch the error, the facility is already late and already costing someone money.

Fragmentation, a workflow problem that has nothing to do with AI at all, splits the same project across disconnected tools: rack power draw lives in one, cooling capacity in another, cable routing in a third. Cooling capacity lives in another. Cable routing lives in a third. Teams reconstruct the same information by hand across these disconnected systems, and small inconsistencies creep into that reconstruction long before any AI agent touches the project. When an agent receives stale or inconsistent state and acts on it, the resulting error won't announce itself. It propagates quietly through the next several decisions before anyone notices something is wrong.

What makes an AI agent's output "undetectable as wrong" in power, cooling, and compliance logic

Large language models don't usually fail in safety-critical engineering work by producing an output that's obviously broken. They fail by producing an output that reads as completely reasonable, while quietly violating a physical limit or a code requirement in a way nobody catches until the project is much further along.

A paper on the Convergent AI Agent Framework, known as CAAF, puts a number on this. An explicit hint telling a frontier model to check its own work for constraint violations gets it partial credit on controlled engineering tasks where the correct answer is already known. Removing that hint drops accuracy to 0%. A later test revealed that the system's reliability came entirely from how the prompt was written.

The CAAF research names two specific ways this breaks down. The first is Context Rot: a model given a long prompt starts to deprioritize safety constraints that were stated early on, as if it simply forgets they were part of the brief. The second is Stochastic Oscillation: when a model is asked to satisfy several competing requirements at once, it can flip back and forth between different constraint violations instead of landing on an answer that respects all of them.

Power, cooling, and routing decisions in a data center are coupled to each other in ways most software decisions aren't. Changing one constraint, a power cap on a rack, a thermal limit on a manifold, ripples into decisions that were made earlier and assumed to be fixed. Those effects become visible only much later, and by then a local fix isn't enough to repair them.

The RFI process shows how expensive that lateness gets. An RFI that sits unresolved, or gets resolved incorrectly, can freeze a procurement order or force a crew to improvise a workaround in the field. That workaround becomes a visible problem only at commissioning, and by commissioning, the contractor's slot on site is gone, the lead-time window has closed, and whatever schedule buffer existed has been used up on something else.

The obvious response is to validate the AI's output before acting on it. That only works if the validation criteria live outside the model doing the reasoning. If the criteria used to check the output are themselves written in plain language and interpreted by the same kind of model that produced the output, nothing has actually been escaped. It's the same stochastic process checking its own homework. Real enforcement needs rules that are machine-readable and sit outside the model entirely, so the model can't talk its way around them.

The architectural answer: separating LLM decisions from deterministic state transitions

The fix that shows up repeatedly in production AI agent systems is a structural choice: keep the language model's reasoning and the system's state transitions in separate places.

The practice that follows from this, in agentic engineering generally, comes down to four habits: define strict contracts for what each tool is allowed to do, make state transitions deterministic, log every step at the trace level so it can be reviewed later, and run evaluation as part of continuous integration. The biggest jump in reliability comes from that separation of responsibilities, not from upgrading to a better model.

CAAF builds this separation directly into its design. Domain invariants, the hard rules that can never be broken, get written into what the framework calls Harness Registries: versioned, machine-readable constraint files. A deterministic Unified Assertion Interface enforces those files, and the language model has no way to override it. The model still does real reasoning, but only inside bounded sub-tasks. It never gets to decide which path the overall workflow takes.

The same pattern appears in an adjacent engineering field. Keysight's ADS 2027 deployment uses MCP servers to hand an agent documented skills and tools built specifically to carry out RF engineering work the same way every time, cutting down on the variability that comes from a model generating answers through statistical guesswork. The agent proposes a design, then Keysight's own simulation software checks whether that design actually works. The language model generates. The deterministic simulation validates. Those are two different jobs, done by two different kinds of system.

Research on what's called the "blueprint first" model, from Qiu and colleagues, describes the same split in more formal terms. An expert writes the actual workflow logic as source code, called an Execution Blueprint, ahead of time. The language model gets invoked only as a bounded tool inside that blueprint. It never decides which branch the workflow takes next. That decision was already made by a human engineer, in code, before the model ever ran.

Applied to data center design, this is the only shape an AI agent can take and still be safe to deploy. The rules that govern power caps, thermal limits, and clash detection need to live in a deterministic layer the model can't talk its way past. The language model's job is to reason, draft, and interpret inside the boundaries that layer sets, not to decide where those boundaries sit.

Power, Cooling, and Routing as Hard Constraint Domains

Electrical and power infrastructure makes up the largest share of total construction cost in a data center build. If it miscalculates load capacity, or lets a rack or outlet exceed its power cap, the result is a procurement order placed at the wrong spec, visible as a mistake only months after the equipment has already shipped.

Cooling adds another layer of coordination that has to be governed by fixed rules. As rack densities push past what air can handle, direct-to-chip and rack-level liquid cooling are moving from pilot projects into planned, facility-wide standard practice. Manifold routing, CDU placement, and the boundaries of each thermal zone all interact with the power layout sitting next to them. Getting that interaction right requires spatial rules that are fixed in advance, not a model's best guess at what should fit where.

Cable and fiber routing carries the same risk in a more physical, more visible form. Without proper coordination across mechanical, electrical, and plumbing systems, a project runs into on-site rerouting after installation has already started, delays caused by space conflicts nobody caught on paper, and cooling efficiency and airflow that suffer because a cable tray ended up somewhere it shouldn't have. An AI agent routing cable without deterministic clash detection and capacity limits built in can hand over a design that looks completely fine in the model and then fails the moment it meets the real building.

There's a useful test for deciding when a decision belongs to a fixed rule instead of to AI reasoning: is the decision deterministic, are the inputs already structured, does the outcome need to be reproducible every time, and is compliance or safety riding on the answer. When the answer to those questions is yes, as it is for power caps, thermal limits, and routing clearances, the decision belongs to a rule. AI reasoning still has a place around that decision, in the interpretation and adaptation work that surrounds it, just not in making the call itself.

A single rack relocation is a good way to see what's at stake. Moving one rack cascades automatically through power allocation, cooling capacity, cable paths, schedules, and drawing sheets. That cascade only stays safe if deterministic rules govern it end to end, catching anything that would push the new state past a physical limit. Handing that same cascade to a language model reasoning its way through each step adds variance at every step. By the end of the chain, those small variances have added up into something nobody specified and nobody caught.

Where AI Belongs: Tasks Bounded by Language and Judgment

None of this means AI has no place in critical-facility work. It means AI belongs where the real bottleneck is language, interpretation, or judgment, not where it's a physical rule that has to hold no matter what.

RFI interpretation is one clear example. Equipment lead times leave almost no room for delay, and an RFI that sits unresolved can freeze a procurement order or push a crew toward an improvised field fix. Figuring out what an RFI is actually asking, how urgent it is, and who on the project is the right person to answer it is a language task. An AI agent can speed that process up without ever making a binding decision about the physical system itself.

Pulling specs out of manufacturer PDFs is another strong fit. Nameplate data, thermal ratings, dimensional specs, all of it sits in documents as unstructured text that someone would otherwise retype by hand into a model or a validation tool. AI extraction turns that text into structured data that flows straight into the rules that govern it, without a person re-keying every field. The model does the reading. The deterministic rule still does the governing once the data is in.

Building-operations research points to where pure rule-based systems hit their limit. As requests get more complex, it stops being realistic to write a fixed rule for every possible workflow. A user might ask for repeated, nested changes across HVAC systems, distributed energy resource configurations, and control logic, all at once, and that combination is close to unbounded. The same thing happens early in data hall layout work, where design intent starts as a sentence someone writes, long before it becomes a fixed parameter a rule can check.

Design exploration is where AI genuinely expands what an engineering team can cover in the same amount of time. Keysight's description of ADS captures the idea well: agents take on the repetitive setup and simulation steps, so engineers get through more scenarios and land on better designs faster. The agent proposes more options. The deterministic simulation still decides which of those options actually hold up.

Recorded macros in ADS capture a method an experienced engineer already worked out, so colleagues, and now agents, can reuse it. The same idea applies directly to data center design. An AI agent can hold onto and surface institutional knowledge about why a past project made the choices it made, while the deterministic rules sitting alongside it apply that knowledge to the right situation.

Traceability as the operational requirement that determines whether an agent is deployable

An AI agent belongs in a critical-facility workflow only if every output it produces can be traced back to the specific rule, data source, or human decision that authorized it. Traceability is the mechanism that makes an agent's output something a person can actually audit, and if needed, undo.

The gap in how projects currently handle this is stated in the DCIM literature: as-built data needs to be written into the contract as a deliverable, with specific fields, specific formats, and specific acceptance criteria spelled out ahead of time. It can't be left as something the project happens to produce once construction is substantially done. An AI agent's output has to meet that same bar. Every action it takes needs to be logged at the level of the individual field it touched, not folded into a summary.

Turnover built around milestones, instead of one large data dump at closeout, spreads the work of checking that data across the whole project and catches mistakes while the contractors who made them are still on site to fix them. A deterministic-AI architecture that logs every state transition as it happens fits naturally into that kind of staged turnover. A purely generative system, one without that deterministic logging layer, has nothing to hand over at each milestone, because there was never a fixed record of what it decided or why.