{"slug": "how-crossnokaye-grounds-physical-ai-with-amazon-bedrock-agentcore", "title": "How CrossnoKaye grounds physical AI with Amazon Bedrock AgentCore", "summary": "CrossnoKaye's ATLAS software-defined automation platform and its AURA agentic intelligence system run on Amazon Bedrock AgentCore, using its code interpreter to execute Python in isolated AWS-managed microVM sandboxes so numerical answers are backed by real computation rather than LLM estimates. 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 daily, and runs over 1,000 live advanced process control applications, which CrossnoKaye reports improve production throughput by 11–17 percent and cut total facility energy costs by an average of 21 percent. AURA pairs AgentCore with Amazon Bedrock Guardrails and local edge safety controls, giving the agent native access to full plant operational state within a single security boundary.", "body_md": "## [Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/)\n\n# How CrossnoKaye grounds physical AI with Amazon Bedrock AgentCore\n\nIndustrial 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.\n\n[CrossnoKaye](https://crossnokaye.com/) took a different approach to bring physical AI to heavy industry using [Amazon Bedrock AgentCore](https://aws.amazon.com/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.\n\nHaving 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](https://aws.amazon.com/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.\n\n## Solution overview\n\nATLAS 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.\n\nATLAS and AURA are built around three core layers:\n\nFirst, 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](https://aws.amazon.com/vpc/lattice/) and [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://aws.amazon.com/msk/). If cloud connectivity drops, the plant continues running safely on the base control narratives on the local edge cluster.\n\nSecond, 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)](https://aws.amazon.com/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)](https://aws.amazon.com/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.\n\nThird, AURA runs inside the platform boundary on [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) as microservices and durable [Temporal](https://temporal.io/) 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](https://aws.amazon.com/bedrock/knowledge-bases/).\n\nHaving 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.\n\nThe numbered flows in Figure 1 trace how an AURA investigation runs on AWS:\n\n1. Client and edge ingress: Engineers and Model Context Protocol (MCP) clients connect through [AWS WAF](https://aws.amazon.com/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.\n2. 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.\n3. Runtime computation dispatch: For statistical, thermodynamic, or multi-dataset math, the workflow streams input datasets over gRPC to AURA’s internal Sandbox Orchestrator service.\n4. Session coordination and live streaming: In interactive sessions, the Sandbox Orchestrator tracks active sandbox session IDs and streams live progress through [Amazon ElastiCache](https://aws.amazon.com/elasticache/) for Valkey.\n5. 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.\n6. Artifact storage and Brief delivery: Verified Apache Parquet outputs, charts, and cited Briefs are saved to Amazon S3 over [AWS PrivateLink](https://aws.amazon.com/privatelink/) , and[Amazon Simple Email Service (Amazon SES)](https://aws.amazon.com/ses/) delivers automated Briefs to plant teams.\n\n## Walkthrough\n\nAURA combines foundation models on [Amazon Bedrock](https://aws.amazon.com/bedrock/) (for model availability by AWS Region, refer to [Supported models by AWS Region](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html) 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:\n\n- 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).\n- Tasks: Repeatable, parameterized investigations bound to immutable version snapshots that produce structured technical Briefs with cited evidence tables and charts.\n- Routines: Automated background watchers triggered by schedules, sensor thresholds, rate-of-change windows, alarms, or equipment mode transitions.\n\nThe following sections examine four architectural decisions behind these workflows.\n\n### Warm conversational sandboxes compared to clean single-run pipelines\n\nInteractive debugging and automated plant reporting have different state requirements:\n\n- 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.\n- 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.\n\nThis 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.\n\n### Verifiable computation instead of unverified model math\n\nWhen 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.\n\nTo make runtime computation verifiable, AURA enforces strict data contracts around every Amazon Bedrock AgentCore run:\n\n1. 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.\n2. 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.\n3. 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.\n\n### Automated night-shift Routines and cited Briefs through Amazon SES\n\nPlant 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.\n\nA night-shift catch on an industrial chiller plant shows how this works end to end:\n\n1. 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.\n2. 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", "url": "https://wpnews.pro/news/how-crossnokaye-grounds-physical-ai-with-amazon-bedrock-agentcore", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/how-crossnokaye-grounds-physical-ai-with-amazon-bedrock-agentcore/", "published_at": "2026-11-09 18:55:43+00:00", "updated_at": "2026-11-09 19:22:39.726488+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure", "ai-tools", "mlops"], "entities": ["CrossnoKaye", "Amazon Bedrock AgentCore", "ATLAS", "AURA", "Amazon Web Services", "Amazon Bedrock Guardrails"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-crossnokaye-grounds-physical-ai-with-amazon-bedrock-agentcore", "markdown": "https://wpnews.pro/news/how-crossnokaye-grounds-physical-ai-with-amazon-bedrock-agentcore.md", "text": "https://wpnews.pro/news/how-crossnokaye-grounds-physical-ai-with-amazon-bedrock-agentcore.txt", "jsonld": "https://wpnews.pro/news/how-crossnokaye-grounds-physical-ai-with-amazon-bedrock-agentcore.jsonld"}}