The post names warehouse automation and stops there

On September 4, 2026, SAP published its account of the first Embodied AI Jam, three days at the Swiss Smart Factory in Biel, Switzerland, with customers, robot makers, integrators, and SAP experts. Warehouse automation is one of the use cases on the list. Inspection drones get a named system in SAP Asset Performance Management and humanoids get one in SAP Digital Manufacturing. Warehouse automation gets no system, no task, and no description of what the robot read or wrote.

SAP describes embodied AI as agents that act in the physical world through robots, with business context supplied by Joule and the SAP Business AI Platform. Our sibling piece covers how to tell a robot demo from a viable process. This one is about what that business context has to contain before a warehouse shift lead would let a robot take a task off the wave.

The task already exists, and the robot needs little else

The warehouse task in Extended Warehouse Management, or in the stock room functions inside S/4HANA, already tells a human picker everything they see on a handheld. Source bin, destination bin, handling unit or quantity, product, and priority against the rest of the wave. That record is the context. The robot needs it in a form its controller can act on, and a signal when the record changes.

It does not need the sales order, the customer, or the credit status. Integrators tend to ask for a wide read of the ERP because it is easier to negotiate once. We'd hold the line at the task. Write the read set on a single page, name the field each item comes from, and hand it to whoever wires the robot into Joule. The argument for small integration contracts was written for middleware, and a robot consumes the same contract.

Current beats correct once the wave is replanned

The record can be correct at 06:00 and useless by 06:20. A customer order behind a pick gets cancelled, a batch goes on quality hold, a supervisor pulls a task forward because a truck arrived early. A robot that read the task once and drove off needs a way to be told, and the post does not say how the Biel setups handled a changed task.

Joule is the layer SAP names for the conversation, and our read is that it is where a shift lead asks which putaways are overdue. The answer has to come from the live task status rather than a copy the robot vendor's fleet manager took an hour ago. During the pilot, change a task's priority mid-run and time how long the robot takes to notice.

The confirmation is where stock moves

When a picker scans the destination bin, the task confirms and stock moves. When a robot sets a pallet down, something has to post that confirmation. If the post never lands, the pallet is physically right while the system still shows it in the old bin, and the next wave gets planned against stock that is not there.

So the second page to write is the write-back. Which system posts the confirmation, at what moment, and what the robot does when the post is rejected because the bin is blocked or somebody moved the handling unit by hand. Lukasz Ostrowski, who heads SAP's embodied AI initiative, says three focused days replaced weeks of distributed back-and-forth. The write-back is the detail a three-day format defers and a warehouse cannot go live without.

A short pick needs a person, and a path to reach one

Every warehouse has short picks, damaged cases, and bins holding something other than what the system says. A human picker calls the shift lead over. A robot has no shift lead unless someone builds the route to one, which means putting the task back, recording why, and sending a person. That exception has to land in SAP as a work item. A stopped robot in aisle 14 is a photo on someone's phone, and nobody replans a wave from a photo.

Before a pilot, pull the ten most common exception reasons from last quarter's task log and ask the integrator to show, for each one, where the robot stops and who gets told. The handoff between human and agent work needs the same design in a forklift aisle as it gets in a case queue.

Four parties can hold the task status, and one has to win

In production, the jam's cast of customers, robot makers, integrators, and SAP experts becomes four parties who could each hold a version of the task's status. The vendor's fleet manager, the integrator's middleware, whatever runs on SAP BTP, and the warehouse system all know something about whether the pallet moved. Only one of them can be the record, and the post does not say which one the Biel teams chose.

The question to settle before a pilot is which status wins when two of them disagree, and who gets paged at two in the morning when the robot says done and the warehouse system says open. Our architecture clinic on why the queue is not the owner covers the software version. The warehouse version has a pallet in the middle of it.

Homework before the next jam

SAP says SAP Switzerland becomes a member of the Swiss Smart Factory as of January 2027 to host further jams and discovery events. Alexander Finger, SAP Switzerland's CTO, frames the format as turning embodied AI into practical SAP-connected business value. For a warehouse team, the practical part starts now and needs no robot.

Export one week of real warehouse tasks with the exceptions left in and hand the file to the shift lead who reconciles the count when it drifts. Ask them to mark every task a robot could not have finished without asking someone. That marked-up list is the business context the post talks about, and it is the first thing we'd put on the table in Biel.