On the industrial floor, a single incorrect number can send a maintenance crew to the wrong machine. In a technical blog post, CrossnoKaye describes this specific risk: large language models (LLMs) are good at interpreting engineering context and planning investigation steps, but they cannot reliably execute statistical calculations or physical balances over millions of sensor readings. If allowed to directly 'compute' results, an LLM might misname a data column, truncate a time window, or output data in a format that breaks downstream chart rendering.
CrossnoKaye's solution is to completely separate 'thinking' from 'calculating'. Its agentic system, AURA, uses large models to plan investigation paths—for example, 'first load critical alarms from 94 facilities over the past 24 hours, then group them by facility, rule, and inter-arrival time, and finally distinguish between rules triggering repeatedly versus multiple devices failing simultaneously'—but all actual numerical computations are executed inside isolated Python microVMs within Amazon Bedrock AgentCore. The model writes the code, the sandbox runs it, and a validator checks the output.
The verification mechanism operates in three steps. First, before allocating a sandbox, the Sandbox Orchestrator service validates input contracts, staging up to 50 datasets (physical I/O, synthetic readings, setpoint logs, alarm histories, and utility rate tables) into the microVM workspace. Second, a deterministic verifier is attached inside the sandbox to check that every output table declared by the model exists in memory as a pandas.DataFrame with matching required columns and types, serializing them directly into binary Apache Parquet files rather than parsing free-form standard output text. Third, if a script throws an exception or lacks required columns, no unverified numbers reach the user; Temporal workflows capture error messages as structured retry prompts, allowing the agent to correct its Python logic and recompute in a clean sandbox.
This design enables a concrete scenario: an operations director asks AURA to review all critical alarms across 94 facilities over the past 24 hours and identify primary mechanical risks. The agent loads alarm summaries in the sandbox, grouping activations by facility, rule, and inter-arrival time. Python analysis distinguishes one plant where 103 critical activations stemmed from two repeating tank-level rules from another plant where 58 activations spanned ammonia detection, evaporator faults, and hot-gas valves occurring densely within one second of each other—the latter pointing to cascading equipment failures requiring immediate safety team intervention.
However, verifiable computation alone is not enough. The article uses a quarry example to illustrate the other half of the problem: an aggregates quarry running primary, secondary, and tertiary rock crushers tripped twice in the second half of a shift. Operators in the control room saw a secondary crusher fault, cleared the alarm, restarted the line, and found it tripped again hours later. Looking only at historian timestamps, the secondary crusher faulted seconds after the tertiary crusher, making it appear to be a crusher issue. AURA provided the correct diagnosis because it read both the conveyor layout and the deployed base control interlock logic: a recirculating belt beneath the tertiary crusher was slipping, tripping the tertiary crusher’s overload interlock; the upstream safety interlock of that interlock then immediately stopped the secondary crusher to prevent burying a stopped downstream crusher in stone. Maintenance personnel inspected the belt, confirming and fixing the slip within minutes.