SAP's jam produced proposals, and that is the honest word

SAP's write-up of its first Embodied AI Jam, published on September 4, 2026, covers three days at the Swiss Smart Factory in Biel, Switzerland, in late August. Customers, robot manufacturers, system integrators, and SAP's embodied AI experts put a robodog, a small drone, and humanoids to work on warehouse automation, asset inspection tied to SAP Asset Performance Management, material handling, and humanoid support for processes in SAP Digital Manufacturing. Lukasz Ostrowski, who heads the embodied AI initiative at SAP, says this kind of development normally takes weeks and that "Three days of dedicated, focused time with customers changed that."

The post says the teams left with viable use cases and architectural proposals. Both nouns are fair. A use case and a proposal are what three days can produce. A process is what survives the following three months on a floor where the integrator has gone home. Our sibling pieces looked at the master data a robot inherits and what a warehouse task has to contain. This one is the test we'd run on any Biel proposal before it gets a pilot budget. It has five parts.

Write down the step that disappears

A business process already has a step list. Take drone inspection. Today a technician walks the tank farm with a route sheet, reads gauges, photographs the flanges that look wrong, and someone keys the results into a notification later that day. Put the drone in, then strike through the steps it removes and add the ones it introduces. Flight planning, battery swaps, image review, and the person who decides whether a blurred frame counts as a finding are all new steps.

If the list of new steps is longer than the list of struck ones, the use case is a demo of a drone. It may still earn its place on safety grounds, and that argument should be made as one. And if the technician still walks the route because the compliance file needs a signed sheet, nothing disappeared at all. The post gives no before and after for any of the four use cases, so this is the first page we'd ask the integrator to produce.

Count how often it happens on a Tuesday

A demo runs once, for an audience, with the interesting case loaded. A process runs at whatever volume the plant produces, mostly with the boring case. Take humanoid support in SAP Digital Manufacturing, for which the post gives no volume. The question for your floor is how many staging moves happen per shift, how many of them are identical, and how many are the awkward one where the box is on the wrong pallet.

If the use case is built around the awkward one, it is a capability demonstration and belongs in the robot maker's brochure. If it is built around the identical two hundred, ask for the run that matters. Have the integrator execute the same move twenty times in a row with no reset and no hands on the machine between runs. The first run is the demo. The twentieth is the process, and the number of times someone reached in between is your real integration backlog.

Find out who was standing behind the robot

SAP's post is clear about who was in the room. Robot manufacturers, system integrators, and SAP's own experts stood beside the customers for three days. Between runs, somebody adjusted a pick height, restated an instruction to Joule, or fixed a mapping in the connection to Digital Manufacturing. None of them will be on your floor at 05:30 on a Monday in February.

So ask for the intervention log. Every manual change made during the three days, who made it, and whether it was to the robot, to the integration, or to the SAP record. If the log does not exist, the process has not been observed yet, only the demo has. A use case whose success depended on a person the customer does not employ has not been tested.

Ask what runs on BTP when the jam is over

The post names Joule and the SAP Business AI Platform as the layer that gives robots business context, and says nothing about the architecture behind the Biel setups. An architectural proposal from a three-day format usually lives on an integrator's slide, and a slide has no subaccount, no owner, and no patch schedule.

Before a pilot, we'd want each proposal to name the tenant the integration runs in, which team on SAP BTP owns the flow between the robot vendor's fleet manager and the SAP record, and who is called when the vendor changes its SDK. Our piece on drawing the integration map before the roadmap covers software estates, and a robot fleet is one more box on that map with a heavier failure mode. A proposal that cannot be placed on the map is still a proposal.

Measure the current process before January 2027

SAP says SAP Switzerland becomes a member of the Swiss Smart Factory as of January 2027, so that it can host further embodied AI jams and discovery formats for customers. A standing venue works in your favour only if you arrive with the current process measured. The post does not say which customers took part, whether any Biel pilots continue, or what a robot fleet costs alongside an SAP contract. Those are questions for the account team rather than for a jam.

Our guide on running a vendor demo on your own terms has the method. Bring the real step list, the real per-shift count, and last quarter's cycle time. Then read SAP's write-up and pick the one use case on your floor that already passes the first two parts of this test. That is the only one worth flying to Biel for.