AI Applications in Warehousing: How Intel and SAP Closed the Loop Between SAP EWM and Autonomous Robots in Chengdu
A warehouse system has always been able to tell people where to move things. The harder question for anyone evaluating AI applications is whether the same system can hand that instruction to a machine and still know, afterwards, what actually happened. At SAP TechEd, Intel and SAP answered that question with a proof of concept staged at Intel’s site in Chengdu, China: warehouse transport requests become robot missions, and task-status plus completion data travel back into the warehouse-management system that issued the work. The source image credit is Intel Corp.
For digital operations leads, product managers and solution architects, that closed loop — decision, execution, write-back — is the practical unit of measurement. Everything below unpacks what the demonstration covers, what the two vendors contribute, where the boundary of the evidence sits, and how to structure your own evaluation of Physical AI in a live warehouse.
Case snapshot: one transport request, one robot mission
The demonstration is deliberately narrow. It is about autonomous material transport and the reporting of results back into SAP Extended Warehouse Management (EWM), rather than a full end-to-end automation of a distribution centre. Read as an application case, it shows the minimum viable integration pattern: an enterprise system of record stays authoritative, an execution layer stays autonomous, and status information stays synchronized.
Step-by-step: the loop as the companies describe it
- SAP EWM initiates a warehouse transport request — the request is the trigger, not a robot-side vision event.
- The request is dispatched outward as a mission to autonomous robots.
- The robots move materials inside the facility.
- Task status and completion are reported back into the warehouse-management system, so the system governing the work reflects what the machine did.
- Exceptions are also returned to enterprise systems; Intel states the flow-back exists but does not detail the recovery process.
SAP supplies the business context, workflow governance and process rules. Intel contributes edge computing plus robotics hardware and software for autonomous material transport. SAP additionally identifies Anu Intelligence as a Physical AI ecosystem partner involved in the project. The companies say the proof of concept reduced transport distances and repetitive manual handling.
Division of labour: what each layer contributes
| Layer | Owner in the proof of concept | What it does | Why an application owner should care |
|---|---|---|---|
| Business context, workflow governance, process rules | SAP | Keeps the transport request inside governed warehouse processes and receives status, outcomes and exceptions back into enterprise systems | Automation that bypasses governance creates reconciliation work; this layer is where auditability lives |
| Edge AI and robotics hardware/software | Intel | Provides the on-site compute and the robotics stack that turns a request into physical movement | Determines latency, on-premises feasibility and how much intelligence sits close to the floor |
| Physical AI ecosystem partner | Anu Intelligence | Listed by SAP as a partner involved in the project | Signals that the stack is assembled from partners, not a single-vendor appliance |
John Healy, Vice President and General Manager, Industrial and Robotics at Intel, framed the objective as decision-to-motion: “Organizations want to connect AI directly to physical operations. By combining SAP’s enterprise context and orchestration with Intel’s edge AI and robotics technologies, we can help customers move Physical AI from business decision to real-world execution.”
Lukasz Ostrowski, Head of Physical AI and Robotics, SAP Research and Innovation for SAP SE, positioned the work as a systems problem: “Physical AI can reshape operations by connecting enterprise systems with operational technology. SAP and Intel are creating solutions to help customers integrate AI-driven automation into core processes while preserving flexibility across robotics platforms, deployment models and ecosystem partners across both hardware and software.”
Open architecture as a procurement question, not a marketing claim
Intel describes the architecture as open and robot-agnostic, intended to preserve customer choice across robot vendors, operating systems, AI models, and cloud or on-premises deployments. The stated aim is to turn the proof of concept into a repeatable approach that can be deployed across sites and robot platforms.
Two adjacent artefacts make that claim testable rather than rhetorical:
- Intel’s broader robotics portfolio includes OpenVINO Physical AI, Physical AI Studio and Robotics AI Suite; the public Robotics AI Suite repository provides applications, libraries, examples and benchmarking tools for autonomous mobile robots, stationary arms and humanoid systems, with ROS 2 integration and OpenVINO-optimized AI models.
- SAP’s separate warehouse Physical AI reference architecture describes a wider set of operations, including picking, placing, sorting and packing — a scope broader than the transport-and-feedback demo.
The practical significance is the seam itself: warehouse-management decisions connected to autonomous execution, with task outcomes reported back into the system governing the work. Everything else — portability, reusability, vendor leverage — is a question you can now ask concretely instead of theoretically.
Where the evidence stops
Evaluating an AI application means reading the gaps with the same attention as the claims. The announcements do not specify the interfaces or messaging protocols used in the proof of concept, do not identify its AI models, and do not explain how failed tasks are recovered or escalated. Intel says exceptions return to enterprise systems, but does not detail the recovery process.
| Dimension | Stated in the proof of concept | Not stated |
|---|---|---|
| Trigger | SAP EWM starts transport requests | Which request types or document categories are in scope beyond material transport |
| Execution | Autonomous robots move materials | Robot models and vendor lock-in at the mission layer |
| Feedback | Status, outcomes and exceptions flow back into enterprise systems | Interfaces and messaging protocols used |
| Intelligence | Edge AI and robotics technology from Intel | Which AI models are in the loop |
| Failure handling | Exceptions are returned | How failed tasks are recovered or escalated |
| Portability | Open, robot-agnostic architecture is the intent | Integration effort for another deployment and which components can be reused |
| Benefit | Companies report reduced transport distances and reduced repetitive manual handling | Whether the reported improvements hold up under production conditions |
Common misconceptions about this kind of deployment
- “A system talking to robots is a production solution.” This is a proof of concept demonstrated at a single site. The integration work, protocol layer and failure paths are not yet public.
- “Edge AI is the hard part.” The demo’s value is symmetrical: Intel’s edge AI and robotics plus SAP’s business context, workflow governance and process rules. Remove the governance layer and you get motion without an auditable record.
- “Robot-agnostic means plug and play.” The stated intent is choice across robot vendors, operating systems, AI models and deployment models; the open question for manufacturers is how much integration another deployment would require and which components can be reused.
- “Reported gains transfer automatically to our operation.” Reduced transport distances and less repetitive manual handling are the companies’ report from this demonstration, not evidence of performance under production conditions.
- “If a task fails, the system handles it.” Exceptions returning to enterprise systems is confirmed; the recovery and escalation process is not described.
FAQ: what readers ask first
What exactly was connected to what?
SAP Extended Warehouse Management was connected to autonomous robots. Transport requests leave EWM as robot missions; task-status and completion information return to SAP EWM.
Where and when was it shown?
The demonstration was carried out at Intel’s Chengdu site in China and presented at SAP TechEd.
Is this about picking and packing?
Not in this demo. The companies specifically describe autonomous material transport and feedback into SAP EWM. SAP’s separate warehouse Physical AI reference architecture covers a wider set of operations, including picking, placing, sorting and packing.
Who else is involved?
SAP identifies Anu Intelligence as a Physical AI ecosystem partner involved in the project.
What is the single most important missing detail?
For an integrator, the interfaces and messaging protocols, the AI models in use, and the failed-task recovery path — none of these are specified in the announcements.
Action checklist: how to run your own Physical AI evaluation
- Pick one closed loop. Choose a request your WMS or EWM-equivalent already governs, so decision and write-back can be measured on the same object.
- Name the governance layer first. Specify which system supplies business context, workflow governance and process rules before selecting robots.
- Define the feedback contract. Decide what status, outcome and exception data must return, and require the protocol documentation that vendors leave open in marketing material.
- Instrument a failure path. Assign human escalation owners for failed tasks before pilot go-live, because this is the least documented part of such projects.
- Baseline the two reported metrics. Transport distance and repetitive manual handling are the claimed improvements; measure both before and after in your own aisles.
- Test portability cheaply. Validate whether the architecture supports alternative robot vendors, operating systems, AI models and cloud or on-premises deployment, and inventory reusable components for a second site.
- Map the ecosystem. Record which partner supplies which layer — in this project, for example, Anu Intelligence is named by SAP as a Physical AI ecosystem partner.
Bottom line
Treat this proof of concept as a template for the connection, not as a finished product. The connection between warehouse-management decisions and autonomous execution is demonstrated and reported back into the governing system; the interface specification, the model inventory, the exception handling and the production-grade validation remain open questions for manufacturers to price into their own pilots. If you can define those four items for your site, you can evaluate Physical AI as an AI application with a testable scope instead of a technology promise.