The Agentic Supply Chain Control Tower: Architecture That Ships

A supplier ASN slips. A line goes down for an unplanned changeover. A promotion lands harder than the forecast expected. Individually, none of these is a crisis. Together, at 2am, they quietly push a key customer order below its on-time-in-full commitment — and nobody sees it until the morning stand-up, by which point the expedite options that were cheap at 2am have become expensive at 9am.

This is the real cost of a supply chain that runs on stale reports. The data exists. The problem was visible in five different systems. What was missing was someone to join those five signals, weigh them against the contract, and act inside the window where acting was still cheap. That someone is expensive, does not work nights, and cannot hold the whole picture in their head across demand, inventory, production, logistics and the customer relationship at the same time.

The pitch for an "agentic supply chain" is that software can do that joining and weighing. The pitch is right. Most of what gets demonstrated under that banner is not.

Two failure modes dominate the agentic demos I see. The first does nothing real: a chat window over a dashboard that answers questions but cannot touch a system of record. It is a better search box, not a control tower. The second does too much: an agent wired to auto-commit — raising purchase orders, rescheduling production, emailing customers — with no human between the model and the money. That one demos beautifully and is uninsurable in a real business.

The architecture that ships sits between the two, and the distinction that makes it work is boringly precise. There are four kinds of thing in it, and keeping them separate is most of the design:

An agent is a reasoning layer. It interprets the situation, decides what matters, and delegates. A tool is a read — it retrieves stock, a lead time, a schedule, a contract term. It changes nothing. A flow is a deterministic write — a Power Automate agent flow that raises a PO or books a dispatch, doing exactly the same thing every time it runs. And a gate is a human approval: a person in Microsoft Teams who says yes before a flow that commits spend or contacts a customer is allowed to fire.

Get those four confused and you get one of the two failure modes. Keep them separate and you get a system that reasons like an analyst, acts like a workflow, and stops like a control process.

The first thing that makes this a control tower rather than an assistant is that no human starts it. The trigger is autonomous, and it fires off the data foundation itself.

Fabric Activator watches the gold layer of the semantic model. A rule sits on it in plain terms: when projected order fill drops below the OTIF service level — say, below 98% for a committed order — fire. That rule is evaluated continuously against live data, not run as a nightly batch. When it trips, Activator calls a Power Automate flow, which executes an agent action and hands over an order-context payload: which order, which customer, which SKUs, how far below the line, and why the projection moved.

That payload wakes the Control Tower agent. The chain is short and every link is a real Microsoft primitive: Fabric Activator detects, Power Automate carries the context, the agent event trigger receives the payload and starts the orchestrator. The business meaning is the important part — the system noticed a problem and went to work before anyone asked it to. The 2am miss now has something looking at it at 2am.

The Control Tower agent is a generative orchestrator built in Microsoft Copilot Studio. Its job is not to know everything. Its job is to delegate to specialists, aggregate what they find, resolve what it can inside policy, and escalate the rest. This is multi-agent orchestration in the literal sense — one agent coordinating a team of narrower agents, each expert in one domain and blind to the others.

The important nuance is that the five specialists are not functions the parent calls. Each is itself an agent running its own orchestration over its own tools and flows. The parent hands a specialist a problem, not a procedure; the specialist decides which of its tools to read, which of its flows to run, and what to hand back. That is what makes the system extensible — you add a sixth domain by adding a sixth agent, not by rewiring the first five.

There are five specialists, and each is a small, honest bundle of tools it can read and flows it can run:

Demand and Allocation reads the order book, forecast and current allocation through a Fabric Data Agent, and runs a risk-driver classifier prompt to work out why the fill is at risk. Its re-allocate flow reserves available finished goods to the at-risk order in SAP S/4HANA, adjusts the downstream allocations that shift as a result, and logs the change. Inventory and Procurement reads live raw-material stock, reorder points and days of inventory outstanding from the ERP, and looks up supplier lead times; its raise-expedited-PO flow creates the purchase order, flags it as an expedite, and holds it at a buyer approval gate, while its check-supplier-ASN flow confirms the inbound ETA. Production and Scheduling reads the MES for line availability, the current schedule and OEE and runs a capacity check; its reschedule flow proposes the insertion and holds at a planner approval gate before it commits any schedule change. Logistics and Fulfilment reads the WMS for pick readiness and the TMS for carrier rates and slots; its book-dispatch flow reserves a carrier slot aligned to the revised production finish, generates the dispatch instruction and notifies the warehouse. Commercial and Customer reads the CRM for the customer, the contract SLA and the credit position, and its prompt tool drafts the customer note; its notify-customer flow sends that note only after a mandatory account-manager gate, because it is external, and its escalate flow raises a case to the S&OP lead with the trade-off options when the exception cannot be resolved in policy.

The orchestrator fans the problem out across all five, then pulls the findings back together in sequence — because they depend on each other. A stock re-allocation in the demand domain changes what the logistics agent needs to book; an expedited PO fixes the material ETA the production agent has to schedule around; the revised production finish fixes the carrier slot logistics can reserve. Coordinating that dependency chain by hand, across five teams, is the work that takes a supply chain a day. The orchestrator compresses it to minutes — and then, at every point that commits money or touches the customer, it stops and writes to a person.

The full picture is easier to hold as one diagram than as prose. It reads top to bottom: the autonomous trigger off the Fabric gold model, into the Control Tower orchestrator, out across the five specialist agents, each reading from and writing back to a system of record, all sitting on a single Microsoft Fabric and OneLake foundation — with the amber gates marking every point a human has to approve before money moves or a customer is contacted.

The teal flows are the deterministic writes. The amber gates are where the system deliberately stops. Notice how few things auto-commit, and which ones: re-allocating your own stock and booking a dispatch run without a gate, because they are reversible and internal; raising an expedited PO, rescheduling a run, notifying a customer and escalating an exception all stop at a gate, because they spend money or touch the relationship.

The architecture is easier to trust once you follow one order through it. Here is a single run, with the numbers a real one would carry.

A Fabric event fires. The projected fill on order #4471 has dropped to 82% against a 98% OTIF commitment, six days before dispatch. The Control Tower agent wakes — no human asked it to, and no human was watching at the moment it mattered.

It delegates first to Demand and Allocation. That agent's Fabric Data Agent reads the order, the forecast and the current allocation; its classifier prompt names the driver — a shortage on component Y, not a demand spike or a data error. That finding returns to the Control Tower, which now knows this is a procurement problem, not an allocation one.

So it routes to Inventory and Procurement. That agent reads raw-material stock and finds it short by 3,000 units against a five-day supplier lead time — too slow for a dispatch in six days. It decides an expedite is warranted and its raise-expedited-PO flow fires, then pauses at the buyer approval gate in Teams. A human approves the premium. Money committed means a human gate, always.

In parallel, Production and Scheduling reads the line schedule and OEE, and finds the only viable slot for the expedited material requires moving a lower-priority run. Its reschedule flow proposes the swap and holds for the planner to approve, rather than quietly resequencing the floor. Once the material ETA and the production slot are both fixed, Logistics and Fulfilment checks WMS pick readiness and TMS availability and its book-dispatch flow reserves a carrier slot aligned to the new finish time.

Then Commercial and Customer reads the contract SLA, its prompt tool drafts a proactive note — the order will ship in full on the revised date — and the notify-customer flow sends it only after the account manager approves the wording. The Control Tower summarises the whole resolution into one briefing for the supply-chain lead: risk detected, driver, the actions taken across all five domains, the approvals still pending, the residual risk, and the new projected OTIF back at 98%. The full trail is logged for audit.

And if a gate is rejected, or the ETA still misses even with the expedite, the escalate flow raises it to the S&OP lead with the priced trade-offs laid out — partial ship now versus air-freight the shortfall versus a revised date the customer has agreed. A person makes that call with the numbers in front of them, not a guess at 9am when the options have already narrowed.

The instinct, when you first see this, is to treat the gates as scaffolding to remove later — training wheels until the agents are trusted enough to run unattended. That instinct is wrong, and it is the single most important thing to understand about making agentic operations real.

The gate is not there because the agent is not clever enough yet. It is there because some decisions are priced, and priced decisions belong to an accountable person. Committing an expedite premium, changing a production sequence that affects other customers, sending a message that sets an expectation with an account — these are commercial acts. Automating the analysis behind them is a gift. Automating the act itself removes the accountability that makes the business insurable, auditable and trusted by its own customers.

So the design principle is deliberate: the agents compress the coordination; the human keeps the priced decision. And the gate goes to the person who actually owns that decision — the expedite premium stops at the buyer, the production resequence stops at the planner, the customer note stops at the account manager. Each sees the full picture the orchestrator assembled — the risk, the driver, the option, the cost, the downstream effect — and approves or declines in seconds rather than assembling it themselves over hours. That is not a slower process with a human bolted on. It is a faster decision with the accountability left exactly where it should be.

When the orchestrator finishes, it does not just act. It writes a control-tower briefing to the S&OP lead: the risk and its driver, the actions it took across all five domains, the approvals still pending, the residual risk, and the revised projected OTIF. And when a case cannot be resolved in policy — a gate is declined, or the expedite still will not make the date — it does not stall. It escalates to the S&OP lead with the trade-offs already priced: partial ship now, air-freight the shortfall, or a revised date the customer will accept. One person reads one briefing and makes one call with the numbers in front of them, on a situation that used to require five phone calls to even understand.

Every agent in this design is only as good as the numbers underneath it, and this is where most agentic projects quietly fail. If the demand agent and the inventory agent are reading different versions of the same stock figure, the orchestrator is coordinating a disagreement. The reasoning layer cannot fix a foundation problem — it inherits it, at speed.

That is why the whole thing sits on Microsoft Fabric and OneLake as a single source of truth. Source systems — SAP S/4HANA, the MES, the WMS, the TMS, the CRM — land in OneLake through a medallion architecture, bronze to silver to gold, with a governed semantic model on top. The Fabric Data Agents the specialists use are published over that gold model, so every agent reasons from the same governed numbers rather than querying five systems that quietly disagree. Direct Lake keeps that read fast enough to act on. And row-level security is honoured by every agent, so an agent can never surface data the requesting user is not entitled to see.

This is the "Unify" in unify, predict, act — and it is not optional groundwork you rush past to get to the agents. It is the reason the agents can be trusted at all. We diagnose the state of that foundation before we design a single agent, every time, because an agentic layer on an ungoverned data estate is a faster way to be confidently wrong.

This architecture is real and it ships, but it is not magic, and pretending otherwise helps nobody. There are three places it strains, and you should size an engagement around them honestly.

The first is write-back. Reading from SAP S/4HANA, an MES or a WMS is well-trodden. Writing back to them — raising a real PO, committing a real reschedule — crosses into transactional territory with its own validation, authorisation and audit requirements. The flows have to respect every rule the ERP would enforce for a human, and building that correctly is most of the delivery effort. An agent that can read everything and safely write nothing is common; the value is in the writes, and the writes are where the work is.

The second is the classifier. The orchestrator is only as useful as its ability to correctly identify why a fill is at risk. A misclassified driver sends the right action to the wrong problem — expediting stock when the real issue was a production sequence. This is tunable and it improves with feedback, but early on it needs a human reading the briefings and correcting the reasoning, which is exactly why the gates matter more, not less, in the first months.

The third is scope creep disguised as ambition. Every operations leader who sees this wants a sixth agent, then a seventh. The discipline is to ship one trigger and five tight specialists that resolve one real class of exception end to end, prove the coordination saving, and then expand. A control tower that tries to model the entire supply chain on day one models none of it well.

Strip out the architecture and the question for an operations or supply chain director is simple: what changes on the floor? Three things.

The exception gets worked in the window where working it is cheap, because the trigger fires on the data at 2am rather than on a human noticing at 9am. The coordination that used to take a day of phone calls across five functions happens in minutes, because one orchestrator fans the problem out and pulls it back together. And the accountability does not move — the person who owns the customer relationship still approves the note that goes to the customer, the person who owns the budget still approves the expedite. You get the speed of automation and keep the control of a human process.

This is the "Act" layer of a control tower done properly, and it only earns its place on top of a "Unify" foundation you can trust and a "Predict" layer that sees the risk early. If you already have a visibility dashboard and are wondering why it has not changed how fast you respond, the honest answer is usually that visibility was only ever the first of three layers. Our earlier piece on getting a control tower from dashboard to automation covers the two layers below this one — this post is what the top layer looks like when it is built to ship.