An architecture diagram with plant engineers and on-site ATLAS edge servers on the left, AWS Cloud services in the center including Amazon EKS running AURA workflows and a sandbox orchestrator, and Amazon Bedrock AgentCore code-interpreter sandboxes on the right.
Architecture figure from the AWS Machine Learning blog post on CrossnoKaye and Amazon Bedrock AgentCore., Amazon Web Services

要点

  • On 10 November 2026, an AWS Machine Learning blog post described how CrossnoKaye's agent system, AURA, uses Amazon Bedrock AgentCore on top of the company's ATLAS plant platform.
  • CrossnoKaye reports more than 100 industrial facilities, 13,000 controlled assets, more than 22 trillion stored machine data points, and more than 50 billion new readings a day.
  • The same post says more than 1,000 live advanced process control applications improve production throughput by 11 to 17 percent and cut total facility energy costs by an average of 21 percent. Those figures describe the control applications, not a before-and-after test of AgentCore.
  • A later results paragraph attributes a 34 percent drop in batch drying-time variation, 6 percent more product inside the yield specification, and more than 50,000 tons a year of recoverable quarry production to the combination of edge control, cloud optimization, and AURA.
  • The architectural claim is more specific: large language models can plan an investigation, but they cannot be trusted to compute statistics or physical balances over millions of readings inside a prompt, so AURA runs that math in AgentCore code-interpreter sandboxes and refuses to publish unverified numbers.

On 10 November 2026, Amazon's machine-learning blog published a long case study of CrossnoKaye, a company that sells software-defined automation to food plants, industrial refrigeration sites, aggregates quarries, and factories. The piece can be read as another customer success story for Amazon Bedrock AgentCore: more than 100 plants, 13,000 assets, higher throughput, lower energy bills, and investigations that finish in under four minutes. A closer reading splits those sentences. The throughput and energy numbers sit on advanced process control applications that already close the loop on ATLAS. AgentCore's job, as CrossnoKaye describes it, is to give the company's agent system a sealed place to run Python, so that answers about the plant are calculated rather than guessed.

[1]

What the post is actually about

ATLAS is CrossnoKaye's platform for writing, versioning, and running a plant's base control narratives: the state machines, sequences, operating bounds, interlocks, and alarm rules that used to live only inside vendor controllers. Those narratives download to on-premises edge clusters and keep running if the cloud link drops. The edge appliances open no inbound firewall ports. They stream telemetry out to AWS. CrossnoKaye reports more than 9,000 control-software deployments a year, more than 1 million run hours with zero safety incidents, and 650,000 closed-loop control actions a day.

AURA sits on top of that shared plant model. It can read equipment layout, deployed interlocks, physical and derived sensor readings, setting histories, alarms, optimization schedules, and plant documents. The post's quarry story is the clearest example of why that shared model matters. Operators saw a secondary crusher trip twice in a shift. In the historian timestamps, the secondary machine faulted seconds after the tertiary crusher, which made the secondary crusher look guilty. AURA also read the conveyor layout and the interlocks. A slipping recirculating belt under the tertiary crusher had tripped that machine's overload protection, which then halted the upstream secondary crusher so it would not bury a stopped machine in stone. The plant manager sent someone to inspect the belt.

That diagnosis depends on topology and control logic. It does not, by itself, require a large language model to add up millions of rows.

[1][2]

Which numbers belong to which layer

The opening inventory is about ATLAS as a installed base: more than 100 facilities, 13,000 controlled assets, more than 22 trillion stored points, more than 50 billion new readings a day, and more than 1,000 live advanced process control applications. The next clause says those applications improve production throughput by 11 to 17 percent and reduce total facility energy costs by an average of 21 percent. The grammar attaches the percentages to the control applications. A reader who skims the AgentCore headline can easily attach them to the new agent layer instead.

Further down, the authors report results from combining software-defined edge control, continuous cloud optimization, and AURA: batch drying-time standard deviation down 34 percent, with 6 percent more product finishing inside the target yield specification, and more than 50,000 tons a year of recoverable production identified in quarry operations. They also say more than 5,000 AI agents monitor more than 10,000 plant assets, and that investigations that once meant hours of exporting historian files now finish in under four minutes as cited briefs. The four-minute figure matches a worked example: a 2:00 a.m. routine caught suction-pressure drift on a chiller plant, ran a read-only sandbox analysis, checked every citation, and emailed a brief by 2:04 a.m. No control change was made automatically.

None of those later figures is isolated as "AgentCore minus AgentCore." They describe a stacked system.

[1][2]

How AURA uses the sandbox

The reason CrossnoKaye reached for AgentCore is stated plainly. Large language models are useful for reading engineering context and planning what to inspect next. They are not reliable at computing statistics or energy and mass balances over millions of sensor readings inside the prompt. Early on, the team let a model write free-form Python that printed JSON or text. The model would misname a column, drop part of a time window, or break a chart.

AURA now wraps every sandbox run in a contract. Before a session starts, the orchestrator checks the input list and can stage up to 50 datasets into the microVM, mixing raw I/O, derived readings, settings, alarms, and utility rates. It appends a verification harness to the model's script. Inside the sandbox, that harness checks that every promised output exists as a pandas DataFrame with the required columns and types, then writes the tables to Apache Parquet. If the script throws an error or omits a column, no number reaches the user. The workflow feeds the traceback back so the agent can fix the code and try again in a clean sandbox.

Interactive chats keep a warm sandbox for 15 minutes of idle time, because an engineer may filter 94 facilities, drop a noisy tank alarm, and then correlate compressor trips with wet-bulb temperature. Scheduled tasks and overnight routines get a fresh, single-use microVM that is shut down when the calculation ends. The sandboxes have no network path to plant equipment. Automated routines run read-only. A proposed setting change still needs explicit human approval, and the edge cluster continues to enforce interlocks that cloud software cannot bypass.

[1][2]

The fair case, and what is missing

The fair case is that this is what "grounding" should mean in a plant. You do not ground a model by pasting tags into the prompt. You ground it by giving it the same facility model the controller uses, and by forcing every quantitative claim through code that another program can check. The crusher story and the 94-facility alarm triage (103 repeating tank-level alarms at one site, versus 58 alarms spanning ammonia detection and evaporator faults within one second at another) are the right kind of example: the value is in the join between historian and interlock logic, plus arithmetic the model is not allowed to invent.

What is missing is an independent split of the benefit. AWS and CrossnoKaye do not publish a comparison of the same plants with AURA off and on, holding the advanced process control layer fixed. The 11 to 17 percent and 21 percent figures should not be cited as AgentCore outcomes. The 34 percent, 6 percent, and 50,000-ton figures are stacked. The four-minute investigation time is a compelling operational number, but it is reported by the vendor about its own deployment. Safety claims such as a million run hours without incidents belong to the base control layer, which is exactly where the post says they should belong.

[1][2]

Who should care, and what to watch

Industrial operators who have been offered a chatbot on top of a historian should care, because this architecture refuses that shortcut. Builders using AgentCore as a code interpreter should care, because the lesson is the verification harness, not the mere presence of a sandbox. Readers of cloud case studies should care, because the easiest sentence to quote is the one that attaches throughput to the newest brand name.

Over the next six months, watch whether CrossnoKaye or a customer publishes a plant-level comparison that holds the process-control applications constant and varies only AURA. Watch whether other vendors copy the pattern of schema-checked Parquet outputs and citation checks before a brief is sent. Watch whether any investigation brief is later withdrawn because a sandbox number was wrong.

[1][2]

Close

The interesting system here is not an agent that runs a factory. It is an agent that is forbidden to do the arithmetic that would send a crew to the wrong machine. If later public numbers separate AURA's effect from the control layer that already claims 11 to 17 percent more throughput, then AgentCore will have earned a narrower, more honest credit: it made those investigations checkable. If the stacked percentages remain the only figures on offer, then the sandbox will still be the right design, and the headline metrics will still belong to the controllers.

[1]