ReadingResearchRadarInvestment framework
Sign in / Sign up
← Back to reading
NewsMaterial4 min readDisconfirmAI Editorial

Industrial Automation Company CrossnoKaye: Let Large Models Plan Investigations, Let Isolated Sandboxes Compute Verifiable Numbers

In an AWS blog post, CrossnoKaye details the core architectural decisions behind AURA, its industrial AI agent: large language models excel at understanding engineering context and planning investigation steps but cannot reliably perform statistical calculations on millions of sensor readings. AURA separates these functions—the model handles reasoning and planning, while Python code executes actual computations within an isolated microVM in AgentCore; outputs are schema-validated before delivery in Parquet format. Coupled with a four-layer defense-in-depth security strategy, this approach ensures every number produced by AI agents in industrial scenarios is traceable and verifiable.

2026-11-10 02:55 GMT+8

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.

Sign in / Sign up
ReadingResearchRadarInvestment framework

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.

CrossnoKaye emphasizes that this diagnostic capability relies on a prerequisite: equipment topology, base control logic, and sensor data must exist within the same system. If an agent can only see historian timestamps, it cannot trace the actual control logic chain. This is why the article lists 'unifying equipment models and control logic first, then adding AI' as its first lesson learned.

Regarding security, this architecture relies on four independent defense layers: Amazon Bedrock Guardrails evaluate every prompt and completion; AgentCore sandboxes run in isolated environments with no network routes, credentials, or API paths to factory equipment; base control narratives on edge Kubernetes clusters enforce deterministic state-machine guards, rate-of-change clamps, and interlocks that cannot be bypassed by cloud services or AI agents; the bottom layer consists of hardwired protections from physical machinery and field wiring. Automated routines run strictly in read-only mode, and any setpoint changes require explicit approval by operators under their corporate identity.

Self-reported results from CrossnoKaye include APC applications improving production throughput by 11–17% and reducing total facility energy costs by an average of 21%; batch drying time standard deviation reduced by 34%; and identifying over 50,000 tons of recoverable production gaps annually in quarry operations. These figures come from the company's own reports and have not been independently verified.

The applicability boundaries of this architecture are also clear: it requires enterprises to already possess a complete platform spanning from edge control to cloud optimization. CrossnoKaye's ATLAS manages equipment models, base control software, historians, and optimization applications simultaneously, so AURA natively accesses the full operational state of the factory within a single security boundary. For most industrial AI projects facing 'bolt-on' integration challenges—where control logic is locked in proprietary PLC code and systems use different naming conventions—unifying the equipment model itself is an engineering task taking years to complete, not a step that can be skipped by simply adding an AI agent.

Sources

  • aws.amazon.comAmazon Web Services↗
Continue researching →