Orchestrating Agents Is Not Orchestrating an Enterprise

Orchestrating Agents Is Not Orchestrating an Enterprise

Orchestrating Agents Is Not Orchestrating an Enterprise

a brain representing GraphRAG with interconnected nodes
a brain representing GraphRAG with interconnected nodes

Article

Table of contents

Orchestrating Agents Is Not Orchestrating an Enterprise
A plan that fits is only the start
Give agents a way to calculate the trade-offs
Why this is possible now
What this looks like in practice
Keep decisions connected when the plan breaks
Three questions to ask
Technology is only part of the change

Table of contents

Why agents need optimisation to orchestrate a company’s resources.

Why agents need optimisation to orchestrate a company’s resources.

Why agents need optimisation to orchestrate a company’s resources.

An AI agent can read a shortage alert and book a truck. The harder question is whether the business needs that truck at all.

Agents are software that interpret information and use tools to carry out tasks. A common approach today is to give each department its own agents and put an orchestrator on top to coordinate them. Agents help people spot problems, exchange information and act sooner. But acting sooner does not make the action a good use of the company’s resources.

Imagine a supermarket is about to run out of milk. The replenishment agent requests more stock. The warehouse agent schedules the work. The transport agent finds that the usual truck is full and books another.

The agents have coordinated a response. Yet the extra truck may have been avoidable. Suppose the store has enough cereal to last until its next delivery. Some cereal could wait, leaving room for milk on the existing truck. That also changes what the warehouse needs to prepare. Another store may need the same warehouse time even more.

The answer depends on the combination: what to send, how much, when to prepare it and how to deliver it.

If each agent must accept the decisions passed down by the previous one, exchanging more messages will not open up those choices. The replenishment decision has already become a fixed requirement for the warehouse and transport.

Adding an orchestrator on top does not change this. An orchestrator sends each request to the right agent and brings the answers back together. That makes the handovers faster. It does not calculate which combination of choices is best for the company.

Letting the agents negotiate does not solve it either. Each agent argues from its own targets and sees only its own costs. The talks tend to stop at the first plan everyone can accept. That is rarely the best plan for the company.

When you give every silo an agent, you automate the silos. You do not remove them.

The ambition is to make the best combined use of a company’s scarce resources: stock, people, machines, vehicles and time.

That requires optimising connected decisions together, across departments, for a shared business objective, from planning through execution. This is what it takes to orchestrate an enterprise. Agents can help. But first they need something that calculates the trade-offs.

A plan that fits is only the start

It is tempting to think the problem is solved once agents know all the rules. The warehouse must have enough capacity. The goods must fit on the truck. Deliveries must meet their commitments.

Those checks are necessary. But many plans can pass them, at very different costs. Hiring another truck might work. So might changing quantities, delaying goods that can wait or rearranging warehouse work.

Take the milk again, as a hypothetical example. Suppose the missed milk sales would cost the store €150 in margin, and an extra truck costs €300. Doing nothing loses €150. Booking the truck saves the €150 but costs €300, so the company ends up worse off than if it had done nothing. Letting some cereal wait saves the €150 at no extra cost. The agents booked the truck. It was the fastest answer and the most expensive one.

Now change the numbers. Before a holiday weekend, the same shortage might cost €1,000 in margin, and nothing on the usual truck can wait. Then a €300 truck is money well spent, even half empty. A full truck is not an objective in itself.

Rules cannot settle this. The numbers decide, and they change every day. So the question is which combination creates the most value once the effects elsewhere are counted for.

Give agents a way to calculate the trade-offs

Telling an agent to “maximise profit” gives it a goal, not a method.

The calculation needs a model: a description of how the operation works, what resources are available, which choices are still open and how one choice influences another.

Optimisation software uses that model to search for the best combinations. It can compare decisions about replenishment, warehouse work and transport against the same business objective.

Together, the model and the optimisation form a decision layer. This is what agents need to orchestrate a company’s resources.

An agent can request a plan, change an assumption and compare the results. It may even help build the model or write the optimisation software. Whoever builds it, the business still needs to check that it represents the operation accurately, produces workable plans and compares them against the shared objective.

Most supply chain platforms already include optimisation. The important question is which decisions the calculation can reconsider together, for what objective and at what speed.

A routing tool can find an excellent route for the quantities it receives and still miss a better plan that changes those quantities.

Connecting specialist tools does not fix this by itself. If quantities are locked in before the routes are known, the better plan is already out of reach. What matters is whether the system can revise the earlier decision once it sees the effect on the later one.

Why this is possible now

Why did companies not work this way long ago? The main reason is the number of combinations. It does not just grow. It explodes.

Take one store and two products, milk and cereal. Each can go on today’s truck or wait. That gives four options: send both, send only the milk, send only the cereal, or let both wait. With ten products, there are more than a thousand options. With thirty, more than a billion. With 300, more than there are atoms in the known universe. And this is the simple version. A real retailer also decides how much of each product to send, for hundreds of stores and thousands of products. And every choice changes the warehouse work and the routes, so the options multiply again.

This is also why a clever agent is not enough on its own. A language model can describe one sensible plan. It cannot check a billion alternatives. For that, it needs to call something that does the mathematics.

For decades, neither planners nor software could work through a problem of that size in time to act. So companies split the decision up. Each department solved its own part and passed the result on. The silos were a way to make the problem small enough to handle.

That limit has moved. Optimisation methods do not test every combination. They rule out large groups of weak options at once and close in on the strong ones. The methods keep getting better and computers keep getting faster. One benchmark study found that, on average, problems of this type were solved about 1,000 times faster in 2020 than in 2001: about 50 times from better methods and about 20 times from faster computers.

The second obstacle was effort. Describing a whole operation in a model, connecting the data and keeping both up to date took too much work. AI now does a growing part of that work, such as mapping data, writing model code and keeping it current.

So replenishment, warehouse work and transport can now be calculated together, in minutes.

What this looks like in practice

We have seen this in our own work at Superlinear. For a large European grocery retailer, we calculated replenishment, warehouse work and transport together. A full plan took under five minutes. We tested the plans against several past periods of the retailer’s own data, and the retailer’s operations experts verified them. The tests point to 3% to 6% higher EBIT. The gain comes from deciding the three together, not from doing any one of them faster.

The same holds outside retail. At a large European transport hub, we planned traffic movements together with the crews and equipment that handle them. In a peak scenario, the plan showed room for over 25% more movements per day without new infrastructure.

Keep decisions connected when the plan breaks

The decision layer must keep helping once the plan is being carried out. Suppose a truck breaks down after the morning plan is ready. Replacing it may be the right response. But the business should also be able to consider combining deliveries, changing quantities or preparing different goods first.

If execution must work around a fixed plan, those choices are already off the table. A useful decision layer reconsiders every choice that is still open, under the same shared objective. People and agents work out what changed, request a revised plan, put the approved response into action and check what happened.

This only works if the calculation is fast, because options expire. Once a truck has left, its load is committed. Once production has started, changing the sequence can be costly. An answer that arrives after the decision has been made is of no use. Neither is one that needs three systems and a handover between each of them.

The calculation must also respect work already under way and count the disruption caused by changing the plan. A small gain may not justify another change.

Agents have a clear role here. They bring the decision layer the right information and carry the result back into the work.

Three questions to ask

Ask three questions of any system that claims to orchestrate your operations:

  1. Can it compare hiring a replacement truck with changing shipment quantities, warehouse priorities and delivery routes, all together?

  2. Can it show which plan earns more after all relevant costs, while meeting the same delivery commitments?

  3. Can it finish the calculation in time for the warehouse and drivers to act?

If any answer is no, the system coordinates the work. It does not orchestrate the enterprise.

Technology is only part of the change

The shared objective also has to reach the way people are managed and rewarded. A transport manager should not be penalised for a lower truck utilisation rate when that choice improves the company’s result.

A recent simulation shows what happens otherwise. In Supply Chain Management Review, Knut Alicke, partner emeritus at McKinsey, and Ida Hedman of Seco Tools gave each of the five functions of a fictional manufacturer its own AI agent. When each agent chased its own function’s targets, four of the five functions looked better on their own scorecards than when all agents worked for the company’s result. Yet the company earned less. Every function saw the same information. The authors’ conclusion: AI agents amplify the incentives a company gives them.

A shared view of the business does not remove conflicting incentives. Orchestrating a company’s resources therefore requires more than connecting systems or adding agents. The business must change which decisions are made together, which measures guide them, who has authority to act and how performance is judged when one function’s gain harms the whole.

Technology provides the model, the calculation and the coordination. Changes in how the company operates make them usable. Without those changes, agents may simply speed up the old handovers and reinforce the old scorecards.

Agents will help orchestrate an enterprise. But only when they can calculate the connected decisions, and when the business is ready to operate differently around them.

Before celebrating how quickly an agent booked the truck, ask whether the business needed it, and whether the organisation is set up to choose differently next time.

Davio Larnout is co-founder and CEO of Superlinear.

author(s)

Davio Larnout

CEO & Co-founder at Superlinear