Stop Calling It a Control Tower

A few months ago, I sat with a senior supply-chain leader at a large manufacturing company while he walked me through what the organization proudly called its control tower. It was impressive. Live vehicle positions, inventory views, red and amber exceptions, supplier alerts, and a wall screen showing service levels across every region.

I asked a simple question: what happens when one of these alerts turns red?

He paused, smiled, and then described the real process. A planner calls the logistics team. Someone checks the ERP. Someone else checks with the transporter. If a customer commitment is at risk, Sales gets pulled in. If premium freight is needed, a manager approves it. If production needs to change, the issue moves to another team. Sometimes there's a WhatsApp group. Sometimes there's a quick meeting. Sometimes there are three.

The screen had detected the problem almost instantly. The company still needed a room full of people to assemble the context, work out what to do, and push the decision through the organization.

Half in jest, I asked him: so what exactly is the tower controlling?

He laughed. But it's a question I've found myself repeating in almost every conversation I have with supply-chain teams since. We've become very good at seeing operations. We're still surprisingly dependent on people to make operations move.

To be fair, the first generation of supply-chain control towers solved a real problem. Not long ago, many companies couldn't answer basic questions quickly: where is the shipment, which customer order is at risk, how much inventory do we have across the network, which supplier is late. Bringing those signals into one place was a genuine step forward, and visibility still matters.

The problem is the word control.

A dashboard gives you awareness. An alert gives you attention. Neither, on its own, gives you control.

Control means that when something changes, the enterprise can understand the consequence, decide what to do, and make the response happen. If all a system can do is point at the problem and wait for a human chain to take over, it isn't controlling the operation. It's observing it very efficiently.

Pick one red alert from yesterday. Any one. Maybe a truck was delayed. Maybe a supplier missed a commitment. Maybe inventory at one location fell below threshold. Maybe an order was about to miss OTIF.

Now trace what happened after the alert appeared. Who looked at it? Who gathered the missing information? Who called whom? How many applications did they open? Who had to approve the response? How long passed before something actually changed in the physical operation?

If the answer begins with “someone called…”, you probably have visibility. You may not yet have control.

This isn't a criticism of the people involved. They're usually doing exactly what the organization expects of them. The issue is that the technology stops at the most important moment: the point where information needs to become a decision.

I've seen another version of this in logistics operations. A team had excellent shipment visibility. Delays were flagged automatically, and the operations room could see exactly which movements were likely to miss delivery windows.

What happened next was almost entirely manual. Someone called the transporter. Someone else checked whether the destination could accept a late arrival. A planner searched for an alternative vehicle. The customer-facing team decided whether the consignee needed to be informed. A manager stepped in if the cost crossed a threshold.

The control tower had created a very accurate red dot. The organization still had to figure out how to make the red dot go away.

That distinction matters, because more visibility can quietly create more work. As systems get better at detecting exceptions, the number of alerts goes up. If every alert still needs human interpretation and coordination, you've simply built a faster machine for generating work for your operations team.

I've watched this play out the same way, almost every time: people start ignoring alerts, or they build their own filters, or one experienced planner quietly becomes the unofficial control tower because everyone knows she's the one who can tell which red alerts actually matter.

Imagine the same delayed shipment again, but change the operating model.

The system detects that the truck will likely arrive four hours late. It knows which customer orders are on that vehicle and whether those customers have a hard delivery window. It checks alternate vehicles, nearby inventory, and the cost of each recovery option. It knows the service policy for that customer and the financial threshold within which it's allowed to act.

If the best response is to reassign a nearby vehicle at a small incremental cost, it does exactly that. It updates the plan, informs the relevant teams, and keeps monitoring the outcome.

If the response would breach a customer commitment, meaningfully change cost, or create a strategic trade-off, it escalates the issue, arriving with the context already assembled and the alternatives clearly laid out.

That's a genuinely different definition of control. The system stops being a place where humans look at the operation. It becomes part of the operation itself.

Whenever I describe this model, one reaction comes up almost immediately: are you saying the AI should just make decisions on its own?

No. Autonomy without boundaries isn't control either.

A useful way to think about the future control tower is as a system with a driving licence, not a blank cheque. It should know where it can act, how far it can go, and exactly when it must stop and ask a human.

A routine stock transfer between two nearby locations may be safe to execute automatically. Changing a strategic customer's allocation may not be. Selecting an approved transporter within a negotiated rate band can be autonomous. Authorizing an unusually expensive recovery move should require sign-off.

The important design question was never “human or AI?” It's “which decisions can be safely delegated, under what conditions, and with what accountability?”

This is where AI governance stops being a policy document and becomes part of daily operations.

Every autonomous action needs a clear owner, a defined objective, and a boundary. The system should be able to explain what signal it saw, what options it considered, which policy it applied, and why it chose the action it took.

You also need to know what the AI is actually optimizing for. A system told only to minimize freight cost may make a perfectly rational decision that damages customer service. A system told only to maximize service may spend money recklessly. A system that learns from human overrides can also learn the wrong lesson if the underlying human behaviour was inconsistent to begin with.

Ethics in supply-chain AI can sound abstract until you put it into an actual operating situation. Should the system always prioritize the largest customer? How should scarce supply be allocated when several customers are affected at once? Can an AI downgrade a supplier based on a pattern it inferred on its own? Which decisions should stay explainable to a customer, an employee, or a partner?

As autonomy grows, governance can't sit outside the product. It has to travel with every decision.

There's another misconception I hear often: that moving toward autonomous operations means throwing away the ERP, TMS, WMS, or planning platforms companies have spent years implementing.

Those systems remain essential. They hold the transactions, master data, workflows, and process controls. They are systems of record.

What changes is the layer above them.

Instead of asking people to move from screen to screen and application to application to assemble a decision, an orchestration layer can pull the required context together, use specialist AI workers to evaluate the situation, and then write the approved action back into the underlying systems.

The applications become infrastructure. Intelligence becomes the operating layer.

For most enterprises, that's a far more practical path than another multi-year replacement programme.

Perhaps we need a better metaphor than a tower.

A tower is static. It watches from above. The model we're moving toward is closer to a nervous system.

Your body doesn't convene a meeting every time you touch something hot. It senses the event, interprets the danger, and triggers a response almost immediately. Your conscious brain gets involved only when the situation actually requires judgment.

That's what an autonomous supply chain should gradually learn to do. Routine deviations should trigger routine responses. Known risks should be handled within policy. People should get involved when the situation is unusual, consequential, or genuinely ambiguous.

The goal was never to remove humans from the loop. It's to stop putting humans in every loop.

So if you're investing in a supply-chain control tower, here are the six questions I'd ask:

1. Can it understand the business impact of an event, not just detect it?

2. Can it evaluate more than one possible response?

3. Can it initiate an action without starting a chain of phone calls?

4. Does it know exactly when it must ask a human?

5. Can you explain why it made the recommendation or took the action?

6. Does it learn from the result?

You don't need to reach the highest level on day one. In fact, you probably shouldn't. Autonomy should be earned. Start with observation. Move to recommendation. Allow execution with approval. Then gradually expand the decisions that can be taken within guardrails as confidence builds.

But the direction matters. If your roadmap ends at better alerts and prettier dashboards, you're improving the view from the tower. You are not changing the operation.

In most of the conversations I have with supply-chain leaders today, visibility is no longer the biggest ambition. Most large organizations already have more data than their teams can comfortably consume.

The bigger question is what happens after the signal appears.

Does another person have to notice it? Does somebody have to interpret it? Does the issue travel through calls, spreadsheets, and approval chains? Or can the enterprise understand the event, choose the right response, act within policy, and involve a human only when judgment is genuinely required?

That's the line between a visible supply chain and an autonomous one.

So yes, keep the maps. Keep the dashboards. Keep the alerts. They're useful.

But perhaps it's time to stop calling the system a control tower until it can actually control something.

The next generation of supply-chain technology won't be judged by how clearly it shows you the problem. It will be judged by how often the problem gets resolved before anyone needs to look at the screen.