A demand spike, one question, and how Joule orchestrates the answer

Previously I wrote about how Joule Assistants orchestrate work behind the scenes, and I used a restaurant kitchen to explain it (here that post). The analogy did its job to explain how Joule Assistants orchestrate, but nothing better than showing it with a real world scenario. 

So this time, no analogy. Let me walk you through a real supply chain planning moment, exactly as it unfolds, and show you everything Joule does between a planner’s request and the answer that lands on their screen.

Picture a supply chain planner, in this case I'll call her Elena. She is responsible for inventory across EMEA. It’s early Q4, and the numbers in front of her don’t match the plan since the demand is spiking, and the usual year-end pressure is building up. She needs to protect service levels without blowing through her working capital target.

She has one question that matters more than anything else on her screen:

“I see a demand spike in Q4 for EMEA. Where should I invest inventory to maximize fill rate without exceeding my working capital target?”

One or more years ago, answering that would honestly have meant days of work: pulling demand signals, running allocation scenarios, checking which distribution centers could physically absorb more stock, and reconciling all of it against a capital ceiling, usually across three different teams and a dozen spreadsheets.

Elena types it into Joule instead. A few moments later, she has a specific, defensible recommendation: which SKUs, how much, which locations, and how it fits her budget. Here’s everything that happened in between:

When Elena hits enter, her request moves through four distinct layers before anything happens in a SAP system.

Figure 1: The four layers between a planner’s question and a system action

The first layer is the Joule Orchestrator. It reads her request, classifies the intent — supply chain planning, inventory optimization — confirms she’s authenticated and holds the right IBP access, and routes her to the best-matched Assistant, in this case the Supply Chain Planning Assistant. The Joule Orchestrator doesn’t do the planning itself. It just makes sure her question reaches the right expert.

The second layer is the Supply Chain Planning Assistant. This is where the orchestration happens. It doesn’t follow a predefined script — it reasons, leveraging an LLM, the way an experienced planning manager would think through a hard problem. It reads the request, works out what’s actually being asked, decides which specialists can help, dispatches them, evaluates what they return, and synthesizes everything into a recommendation.

The third layer is the specialist Agents. Each one is a narrow expert — one for demand trends, one for inventory investment allocation, one for the distribution footprint. They don’t own the broader decision. They answer their piece, pull from the relevant systems, and report back to the Assistant with structured findings.

The part I find most interesting is what the Supply Chain Planning Assistant does in its “head”, and here it is, filled in with Elena’s actual question.

Figure 2: The five-step reasoning loop every Domain Assistant runs

Step one is understanding the job. The Assistant frames the problem: the domain is inventory planning, the scope is Q4 and EMEA, the hard constraint is the working capital target, and the expected outcome is a specific recommendation — where to invest, how much, and which SKUs. Not a dashboard, but rather a decision.

Step two is assembling the team. The Assistant selects three agents: a Demand Trend Agent, an Inventory Investment Allocation Agent, and a Footprint Optimization Agent. These agents are deliberately chosen because they address the specific scope, need, constraints, and expected outcome based on the user request. Just as importantly, it excludes the ones that don’t fit the request. The request isn’t about explaining an existing plan or ranking orders; it’s about where to put inventory. Choosing the right team is half the job.

Step three is sequencing and dispatching. The Assistant recognizes these three questions are independent of each other – understanding the demand spike doesn’t depend on knowing warehouse capacity – so instead of running them one after another, it dispatches all three out in parallel. Three specialists working simultaneously, which is why Elena gets her answer in moments, not hours.

Step four is monitoring and replanning. As the agents report back, the Assistant checks whether the findings change the picture. The Footprint Agent flags that the distribution center in Milan is constrained while the Frankfurt and Rotterdam distribution centers have room. Does that force a rethink? No, it actually confirms Frankfurt and Rotterdam as the right homes for the extra stock, so no replanning is needed. (When the evidence does change the picture, this is exactly where the Assistant adapts; swapping agents mid-task, as I described in the last post.)

Step five is synthesis and governance. The Assistant pulls the three findings into one coherent recommendation: increase safety stock for SKUs A, B and C at Frankfurt and Rotterdam; hold SKU D, which isn’t worth the capital; total investment €2.1M, comfortably inside the €2.5M target. Then it makes a governance decision. Acting on this means pushing new targets to SAP IBP and updating MRP in S/4HANA — a change that touches multiple systems and needs an audit trail. So rather than firing off changes directly, the Assistant presents the recommendation to Elena for review and, on her approval, triggers a governed multi-system workflow.

What makes the recommendation trustworthy is that every line of it traces back to a specialist’s finding. Elena sees the evidence, not just the conclusion.

Figure 3: The three specialist agents and what each returned

The Demand Trend Agent confirms the spike is seasonal plus promotional, +35% above baseline, and that it normalizes in Q1, so this is a short-term investment, not a structural shift. The Inventory Investment Allocation Agent finds that SKUs A, B and C deliver the fill-rate improvement for €2.1M, while SKU D doesn’t justify the capital. The Footprint Optimization Agent confirms Frankfurt, at 72% utilization, and Rotterdam, at 68%, can absorb the additional stock, while Milan, at 94%, cannot. Three narrow experts, three focused answers, assembled into one decision.

A question I always get: how do these assistants and agents work together, especially when they might be built by different teams? The answer is a shared protocol. SAP has adopted the Agent-to-Agent (A2A) protocol (an open standard) so the Supply Chain Planning Assistant can discover an agent by reading its “digital business card”, delegate a structured task to it, and collaborate as the agent streams its results back. Alongside A2A, agents use MCP (Model Context Protocol) to reach the tools and data they need such as SAP IBP, S/4HANA, planning models, data products, APIs. If A2A is how agents talk to each other, MCP is how they reach the systems and tools they need.

At the end, Elena asked one question. She never had to know how the Joule Orchestrator classified her intent, nor that the Supply Chain Planning Assistant assembled a team of three specialists, nor that they ran against IBP and S/4HANA, or that the whole thing was reconciled against her capital target before it reached her. She just got an answer she could act on and the authority to approve it.

That’s the whole idea. The orchestration happens behind the scenes, and the planner is left with the one thing they actually needed: a n optimal, clear, auditable, and defensible decision. That is how Joule Assistants orchestrate – not in a kitchen this time, but in the middle of a real Q4.

Source link