CrossnoKaye 如何用 Amazon Bedrock AgentCore 落地物理 AI

Industrial operations present AI challenges that don’t show up in typical enterprise software. In most facilities, plant data and control logic are spread across separate systems from different vendors: programmable logic controllers (PLCs) and distributed control systems (DCS) run the equipment logic, historians record time-series tags under site-specific naming schemes, supervisory control and data acquisition (SCADA) systems drive operator screens, and standalone optimization tools or alarm loggers sit on the side. Bolting an external AI agent onto that stack rarely works well in practice. Each system uses its own naming conventions. The logic that actually governs how equipment behaves (the control sequences, state machines, and safety interlocks) is locked inside proprietary controller code that an external tool can’t inspect. Giving a bolt-on agent access across multiple operational technology (OT) systems also means distributing credentials across the plant network.

CrossnoKaye took a different approach to bring physical AI to heavy industry using Amazon Bedrock AgentCore. Its software-defined automation platform, ATLAS, connects live plant data and AI reasoning to closed-loop control of the equipment running food and beverage plants, industrial refrigeration facilities, aggregates quarries, and manufacturing sites. Across more than 100 industrial facilities and 13,000 controlled assets, CrossnoKaye stores over 22 trillion machine data points, ingests more than 50 billion new readings every day, and runs over 1,000 live advanced process control (APC) applications; CrossnoKaye reports that these applications improve production throughput by 11–17 percent while reducing total facility energy costs by an average of 21 percent. Because ATLAS already manages the facility model, the base control software, the historian, and the optimization applications in one platform on AWS, CrossnoKaye’s agentic intelligence system, AURA, has native access to the full operational state of the plant within a single security boundary.

Having the plant context is only half the problem, though. Large language models (LLMs) are good at interpreting engineering context and planning an investigation, but they cannot reliably compute statistics or physical balances over millions of sensor readings in a prompt. To back every numerical answer with real math, AURA uses the code interpreter capability in Amazon Bedrock AgentCore to write and run Python workloads at runtime inside isolated, AWS managed microVM sandboxes, alongside Amazon Bedrock Guardrails and local edge safety controls. This post covers how CrossnoKaye architected ATLAS and AURA on AWS, how AURA uses Amazon Bedrock AgentCore across interactive Chats, repeatable Tasks, and automated Routines, and what the team learned running physical AI in production.

Solution overview

ATLAS controls industrial processes across existing PLC and DCS infrastructure, from kilns, crushers, drying rooms, ovens, and spiral freezers to chillers, turbines, valves, and compressors, without requiring customers to rip and replace plant hardware. Figure 1 illustrates how on-premises ATLAS edge clusters, continuous cloud optimization, and AURA work together on AWS.

Figure 1: CrossnoKaye AURA and ATLAS physical AI architecture with Amazon Bedrock AgentCore

ATLAS and AURA are built around three core layers:

First, the plant is defined in software from the edge up. At each facility, an on-premises ATLAS control panel with redundant computers, power supplies, and network switches (so local control continues uninterrupted while a failed hardware component is replaced) runs a local Kubernetes cluster that uses contract-first microservices, extending the ATLAS cloud platform on AWS to the plant floor. In the cloud, ATLAS authors, validates, and versions the facility’s base control narratives (defining equipment state machines, sequences, operating bounds, interlocks, and alarm rules), which are downloaded to the edge appliances and run locally against existing equipment and controllers. CrossnoKaye reports over 9,000 control software deployments per year and more than 1 million run hours with zero safety incidents. Each edge appliance also acts as an outbound-only information technology/operational technology (IT/OT) gateway that opens zero inbound firewall ports inside the plant, streaming high-frequency telemetry to AWS through Amazon VPC Lattice and Amazon Managed Streaming for Apache Kafka (Amazon MSK). If cloud connectivity drops, the plant continues running safely on the base control narratives on the local edge cluster.

Second, derived engineering signals and closed-loop optimization applications run on top of base control using the same shared plant model. In the cloud, CrossnoKaye’s Scheduling system runs two continuous pipelines from versioned Python packages in Amazon Simple Storage Service (Amazon S3), operating on configurable per-instance cadences and event-driven triggers when plant settings change. Synthetic reading algorithms compute derived engineering metrics, such as heat-flow distributions, asset health indices, energy intensity, and mass-balance deviations, and write them back to the historian alongside physical I/O. Closed-loop optimization applications run on top of the base control layer, combining those derived synthetic readings with physics models, model predictive control (MPC), reinforcement learning, utility tariffs, and weather forecasts to compute optimal setpoint schedules. Amazon Simple Queue Service (Amazon SQS) FIFO queues order every schedule and state update by facility before dispatching setpoints to the local base control narrative on the edge cluster, which CrossnoKaye reports runs 650,000 closed-loop control actions per day.

Third, AURA runs inside the platform boundary on Amazon Elastic Kubernetes Service (Amazon EKS) as microservices and durable Temporal workflows. Under the caller’s enterprise permissions, AURA agents query the internal Atlas Data gateway to read the operational state of a facility or fleet in one consistent model: upstream and downstream equipment topology, the deployed base control narratives and interlocks, physical I/O and synthetic readings, setting change and alarm histories, active optimization schedules, and plant documentation indexed in Amazon Bedrock Knowledge Bases.

Having the equipment layout, the base control logic, and the sensor data in the same system makes a concrete difference when diagnosing plant issues. At an aggregates quarry running primary, secondary, and tertiary rock crushers, the back half of the plant tripped twice in a single shift. From the control room, operators saw the secondary crusher fault, cleared the alarm, and restarted the line, only for it to trip again hours later. In the historian timestamps alone, the secondary crusher faulted seconds after the tertiary crusher, which made it look like a crusher problem. Because AURA also reads the conveyor layout and the deployed base control interlocks, its investigation followed the actual control logic. A recirculating belt beneath the tertiary crusher was slipping, which tripped the tertiary crusher’s overload interlock. That interlock’s upstream safety interlock immediately halted the secondary crusher to prevent burying a stopped downstream crusher in stone. Instead of chasing a phantom crusher fault, the plant manager sent an operator to inspect the recirculating belt, confirming and fixing the slip in minutes.

The numbered flows in Figure 1 trace how an AURA investigation runs on AWS:

Client and edge ingress: Engineers and Model Context Protocol (MCP) clients connect through AWS WAF and a public Application Load Balancer, where the API gateway validates enterprise single sign-on (SSO) or MCP credentials. Edge telemetry and control schedules flow through Amazon VPC Lattice (authenticated with AWS Identity and Access Management (IAM) Signature Version 4 (SigV4)) and Amazon MSK.
Context retrieval and guarded inference: AURA workflows read plant state through the Atlas Data gateway and route prompts and organization-scoped Retrieval Augmented Generation (RAG) queries through the Model Gateway to foundation models, Amazon Bedrock Guardrails, and Amazon Bedrock Knowledge Bases.
Runtime computation dispatch: For statistical, thermodynamic, or multi-dataset math, the workflow streams input datasets over gRPC to AURA’s internal Sandbox Orchestrator service.
Session coordination and live streaming: In interactive sessions, the Sandbox Orchestrator tracks active sandbox session IDs and streams live progress through Amazon ElastiCache for Valkey.
Isolated Python execution: The Sandbox Orchestrator uses the AWS SDK to call the endpoint for the Amazon Bedrock AgentCore runtime, a capability of Amazon Bedrock AgentCore, staging datasets and running model-authored Python inside an isolated code interpreter microVM.
Artifact storage and Brief delivery: Verified Apache Parquet outputs, charts, and cited Briefs are saved to Amazon S3 over AWS PrivateLink, and Amazon Simple Email Service (Amazon SES) delivers automated Briefs to plant teams.

Walkthrough

AURA combines foundation models on Amazon Bedrock (for model availability by AWS Region, refer to Supported models by AWS Region in the Amazon Bedrock User Guide) with isolated Python sandboxes in Amazon Bedrock AgentCore Code Interpreter, a capability of Amazon Bedrock AgentCore, across three operational modes:

Chats: Interactive, multi-turn engineering conversations spanning a single unit, a process line, or a multi-site portfolio (up to 200 facilities in a single turn).
Tasks: Repeatable, parameterized investigations bound to immutable version snapshots that produce structured technical Briefs with cited evidence tables and charts.
Routines: Automated background watchers triggered by schedules, sensor thresholds, rate-of-change windows, alarms, or equipment mode transitions.

The following sections examine four architectural decisions behind these workflows.

Warm conversational sandboxes compared to clean single-run pipelines

Interactive debugging and automated plant reporting have different state requirements:

In an interactive Chat, an engineer explores hypotheses step by step: loading 24 hours of critical alarms across 94 facilities, filtering out chattering tank-level sensors at one site, and correlating compressor trips against ambient wet-bulb temperatures. Starting a cold sandbox on every turn would wipe in-memory tables and add latency. For Chats, the Sandbox Orchestrator binds one warm Amazon Bedrock AgentCore session to the conversation in Amazon ElastiCache for Valkey with a 15-minute sliding time to live (TTL), transparently provisioning a replacement session if an engineer returns after the idle timeout expires.
In a scheduled Task or a 2:00 AM Routine, reproducibility comes first. Every run must start in a clean environment with no leftover state from prior runs. For Tasks and Routines, the Sandbox Orchestrator provisions a fresh, single-use AgentCore microVM per run and stops the session with StopCodeInterpreterSession as soon as the calculation finishes, preventing both cross-run contamination and idle sandbox charges.

This warm-session design makes fleet-wide triage practical in a single conversation. When an operations director asks AURA to review all critical alarms across 94 facilities over the past 24 hours and identify the primary mechanical risks, the agent loads the fleet alarm summaries from the Atlas Data gateway into its AgentCore sandbox and groups activations by facility, rule, and inter-arrival time. Rather than ranking sites by raw alarm count, the Python analysis separates a plant where 103 critical activations came from two repeating dump-tank level rules from a plant where 58 activations spanned ammonia detection, evaporator faults, and hot-gas valves within one second of each other, pointing safety and maintenance teams directly to the facility with cascading equipment faults.

Verifiable computation instead of unverified model math

When an engineer asks AURA to analyze a process trend or audit shift performance, the numbers in the response must be exact. Early in AURA’s development, the team found that letting a model write free-form Python scripts that print JSON or text summaries to standard output was too brittle: a model would occasionally misname a column, drop part of a time window, or format output in a way that broke downstream chart rendering.

To make runtime computation verifiable, AURA enforces strict data contracts around every Amazon Bedrock AgentCore run:

Upfront contract validation and multi-source staging: Before allocating a sandbox session, the Sandbox Orchestrator validates the input contract and stages up to 50 datasets into the microVM workspace, combining physical I/O, derived synthetic readings, setting logs, alarm histories, and utility rate tables.
In-sandbox DataFrame schema verification: Rather than parsing free-form text from standard output, the service appends a deterministic verification harness to the model’s Python script. Inside the sandbox, the harness verifies that every declared output table exists in memory as a pandas.DataFrame with all required columns and types, and serializes the verified tables directly to binary Apache Parquet files.
Automated self-correction: If the script raises a Python exception or omits a required column, no unverified numbers reach the user. The Temporal workflow captures the traceback and schema mismatch as a structured retry prompt so the agent fixes its Python logic and re-runs the calculation in a clean sandbox before publishing any conclusion.

Automated night-shift Routines and cited Briefs through Amazon SES

Plant engineers cannot watch dashboards across 100 facilities around the clock, and many equipment issues start as slow drift on the night shift. AURA Routines run in the background, watching for specific process conditions (such as suction-pressure drift on a refrigeration stage, a batch drying curve falling behind specification, or an unscheduled manual setpoint override) and launching an investigation automatically when one triggers.

A night-shift catch on an industrial chiller plant shows how this works end to end:

Automated detection and sandboxed root-cause analysis (02:00–02:03 AM): At 2:00 AM, a Routine detects low-stage suction-pressure drift and launches its pinned Task in read-only mode. Inside an Amazon Bedrock AgentCore sandbox, the agent correlates condenser approach temperatures against low-stage suction pressure across physical and synthetic readings, rules out sensor drift and low refrigerant charge, and isolates condenser-side fouling.
Deterministic citation validation (02:04 AM): Before publishing the Brief, AURA parses every inline citation and verifies that each claim links to a saved telemetry window, setting change record, or sandbox output artifact in Amazon S3. No control change is made automatically.
Brief delivery through Amazon SES and one-click Chat handoff: Within four minutes of the trigger, AURA sends a formatted HTML Brief email through Amazon SES to the plant engineering team with the diagnosis, cited signal traces, and an “Investigate in AURA” button. When the lead engineer selects that button before the morning shift huddle, AURA verifies the engineer’s live facility permissions and opens an interactive Chat pre-loaded with the Brief’s evidence so the team can ask follow-up questions or issue a work order immediately.

Defense in depth industrial safety

In an industrial plant, operational safety cannot depend on an LLM following instructions in a prompt. Because ATLAS and AURA share the same platform from the cloud down to the edge Kubernetes cluster on the plant floor, CrossnoKaye enforces strict boundaries on what AI and optimization workloads can do across four independent layers:

Amazon Bedrock Guardrails and verifiable provenance (Observe): Every prompt and completion routed through AURA’s Model Gateway is evaluated by Amazon Bedrock Guardrails to enforce content, topic, and safety policies. Knowledge Base retrieval is isolated by organization, and every Brief requires verified inline citations, noting both which time windows were analyzed and any periods where sensor data was unavailable.
Air-gapped read-only sandboxes and human-approved proposals (Propose): Amazon Bedrock AgentCore Code Interpreter microVMs run in isolated, AWS managed environments with no network routes, credentials, or API paths to plant equipment. Automated Routines run strictly in read-only mode. When an engineer uses an interactive session to propose a setting change, the platform requires explicit human approval under the operator’s corporate identity and verifies the physical outcome in plant telemetry afterward.
Non-bypassable deterministic Level 1 base control at the edge (Bounded and Base Control): Cloud optimization applications don’t drive field hardware directly. They run on top of the platform’s base control layer by dispatching setpoint schedules within engineering-approved envelopes. On the plant floor, the edge Kubernetes cluster runs the downloaded base control narratives locally in real time, enforcing deterministic state-machine guards, rate-of-change clamps, operating bounds, and equipment interlocks that cannot be bypassed by cloud services, optimization applications, or AI agents.
Independent physical hardware protection: Beneath the ATLAS software-defined controller, the plant’s physical machinery and field wiring enforce independent, hardwired protection layers, including safety relays, local programmable trips, and mechanical pressure-relief and over-temperature devices.

Results and lessons learned

Across food processing, industrial refrigeration, aggregates and mining, and manufacturing sites, CrossnoKaye reports that combining software-defined edge control, continuous cloud optimization, and AURA has reduced batch drying-time standard deviation by 34 percent (with 6 percent more product finishing within target yield specification) and identified more than 50,000 tons per year of recoverable production gap in quarry operations. With over 5,000 AI agents monitoring more than 10,000 plant assets across customer facilities (including over 13,000 controlled devices and equipment units across the ATLAS fleet), investigations that previously required hours of exporting historian CSVs, cross-referencing PLC ladder logic, and building spreadsheets now complete in under four minutes, delivering cited technical Briefs through Amazon SES before the morning shift meeting.

Three lessons stood out from building and operating AURA across industrial facilities:

Unify the plant model and control logic before adding AI: An agent can only diagnose real physical root causes, like distinguishing a slipping downstream recirculating belt from a secondary crusher fault, when it can read the process topology, the deployed base control narratives and interlocks, the setting change history, and the optimizer state in one consistent model rather than stitching together six disconnected plant systems.
Deliver value inside the operator’s daily workflow, not as a separate tool to go use: Plant teams are busy running equipment. If an AI assistant is a separate destination where engineers must start from a blank prompt, day-to-day adoption stalls. Embedding AURA into the daily shift rhythm (where background Routines catch anomalies overnight, run the Python analysis in Amazon Bedrock AgentCore, and deliver a cited Brief to the engineer’s inbox with a one-click handoff into a pre-loaded Chat) means operators see the value in their normal routine without having to go use a separate product.
Enforce data, coverage, and safety contracts in code rather than prompts: In a plant, a missing hour of sensor data isn’t the same as an hour with no events, and an unverified calculation can send a maintenance crew to the wrong machine. Making data-coverage gaps explicit in tool contracts, verifying pandas.DataFrame schemas inside the AgentCore sandbox before extracting binary Apache Parquet outputs, and enforcing deterministic base control bounds on the edge Kubernetes cluster catch probabilistic model errors before they reach an operator or a piece of equipment.

Conclusion

Reliable physical AI in heavy industry requires grounding models in the actual equipment topology and control logic of the plant, and backing every quantitative claim with verifiable Python calculations. Together with Amazon Bedrock Guardrails and isolated Python sandboxes in Amazon Bedrock AgentCore, ATLAS and AURA allow agents to reason over live facility ontology, base control narratives, setting histories, physical I/O, optimization state, and synthetic readings, delivering checkable engineering answers and cited technical Briefs through Amazon SES while keeping deterministic safety controls firmly on the plant floor.

To learn more about building agents with isolated code execution, refer to the Amazon Bedrock AgentCore Developer Guide or visit CrossnoKaye to see how physical AI is transforming heavy industry.