Superintelligence in Logistics: Routes, Incidents and Delivery Promises

Superintelligence in Logistics: Routes, Incidents and Delivery Promises

Superintelligence in logistics is, today, a lens for analysis and not a product you can buy. It asks what would happen if a system planned routes, interpreted delivery incidents and calculated delivery times better than any team, and what the operation would still need to keep under human decision. What exists in practice are highly capable but limited models and agents, and the operator remains the one who defines what they can propose, execute and promise to the customer.

Key takeaways

• Superintelligence is a design exercise: by imagining a very capable system, you discover which decisions cannot be delegated.
• In routing, AI helps read constraints and re-optimize, but business priorities, safety and driver working hours stay with people.
• In incidents, classifying and suggesting is safe. Compensating, assigning blame or changing a contract requires human approval.
• In delivery times, separate the internal forecast from the promise to the customer. The system can estimate, but it only commits to what a business rule covers.
• The safe path is a pilot on a single flow, with decision logs, an agreed metric and a clear rule for when to hand off to a person.

What does superintelligence in logistics actually mean?

The term describes a hypothetical system that outperforms people at practically any intellectual task. No delivery operation runs anything like that today. What runs are language models, optimization engines and fixed rules combined into flows, each good at one part of the work. The difference between these concepts is explained in AGI, ASI and AI agents: what your company can actually run.

The lens is still useful. If we accept that analytical capability will keep growing, the question stops being whether the system can do something and becomes whether it should do it alone. In logistics, this comes down to three decisions with very different costs of error:

• Which way to go: an error costs fuel, time and delays, but is usually reversible.
• What to do when something goes wrong: an error can create direct cost, conflict with a customer or unfairness to a driver.
• What to promise the customer: an error becomes a broken expectation, a complaint and sometimes a contractual obligation.

The more irreversible a decision is, and the more it affects a person, the closer it should stay to the operator.

Routing: where capability helps and where the operator decides

Routing is an optimization problem with many constraints: delivery windows, vehicle capacity, stop time, address access, driver qualifications and loading order. That calculation is already done by specialized mathematical engines, and a language model should not replace them. What a highly capable model adds is the layer that always causes trouble: turning loose information into usable data.

For example, customer notes such as the front desk only accepts deliveries after lunch, trucks enter through the side street, or call before arriving usually sit in free-text fields. AI can read that history, structure the constraints and hand them to the routing engine. It can also re-optimize when something changes midday and explain in plain language why a route changed.

What stays with the operator:

• Business priorities, such as which customer gets preference when two deliveries compete for the same time slot.
• Safety restrictions, such as areas where the company has decided not to operate at certain hours.
• Driver working hours and rest rules, which involve labor law and internal agreements.
• Approval of any change that alters a commitment already communicated to the customer.

The design that works is simple: the model interprets and proposes, the engine calculates, and the operator approves anything that changes a commitment. Anthropic itself recommends, in its guide Building effective agents, starting with the simplest solution and using predictable workflows whenever the path is known, reserving autonomous agents for steps where flexibility pays off.

Incidents: classifying is easy, deciding is the real issue

Customer absent, address not found, damaged goods, refused delivery, stopped vehicle, traffic delay. Each incident arrives through a different channel: the driver app, a WhatsApp voice note, a phone call, an email from a partner carrier. This is where a highly capable system stands out most, because it reads messy text and gathers context quickly.

What AI can do at low risk:

• Transcribe and summarize the driver's report.
• Classify the incident into categories the operation already uses.
• Gather the order, route and customer history into a single view.
• Suggest the next step already defined in the procedure, such as rescheduling or contacting support.
• Draft the message to the customer for review.

What should require approval from a person:

• Refunds, discounts, re-shipments with extra cost or any monetary amount.
• Declaring who was at fault for damage or delay.
• Any consequence for the driver, such as a warning or a route block.
• Refusing a redelivery or changing the agreed conditions.

Two more precautions apply. First, the text that enters the system comes from third parties and may contain instructions disguised as a report. Treat incident content as data to be read, never as orders to be followed, and limit the tools the agent can trigger. Second, when an automated decision affects a person, Brazil's LGPD provides the right to request a review. The article LGPD automated decision-making: Article 20 and the right to review explains what this means for your company, and it is worth reading before you automate any decision about drivers or customers.

Delivery-time communication: the promise is where risk appears

One distinction solves most of the problems: a forecast is an internal estimate, and a promise is a commitment to the customer. A highly capable system can improve the forecast by combining route, stop history, traffic and address type. That does not authorize it to promise anything.

Practical rules for delivery-time communication:

• The message uses only data confirmed in the transport system, never a time the model deduced on its own.
• When uncertainty is high, give a window instead of an exact time.
• Delays are acknowledged with the real reason and the next step, without blaming the driver or the customer.
• The agent does not offer compensation or change conditions. It hands the case to a person.
• Exception requests, such as an urgent delivery off the planned route, go straight to the operator.

If the notice is sent proactively on WhatsApp, channel rules apply: customer permission and approved templates. It is worth reviewing WhatsApp outbound messages: templates, opt-in and best practices before designing the flow, because a well-written delay notice does not make up for a number with a poor reputation.

Decision guide: AI, fixed rule or operator?

Use this list as a test for each step of the flow. For each decision, answer the questions in order.

• Is the rule known and stable? Use a fixed rule or a calculation engine, without AI.
• Is the input free text, audio or messy data? Use AI to interpret and structure it, with output in a fixed format.
• Is the error reversible and cheap? AI can act alone, with a record of what it did.
• Does the error create cost, conflict or affect a person? AI proposes, the operator approves.
• Does the decision change a contract, a price or a condition? It stays with the operator, and AI only prepares the context.
• Is there doubt about what the customer wants? AI asks or hands off, and never assumes.

The result is a written map of responsibility that the team can read and challenge. Without it, the split between system and person happens by improvisation, usually on the worst day.

Illustrative scenario: a day of deliveries at a regional distributor

Illustrative scenario, not related to any real company. A regional distributor serves shops with deliveries in agreed windows. In the morning, the system reads the customer notes, structures the constraints and sends them to the routing engine, which returns the routes. The operator reviews two exceptions the system flagged and approves them.

Midday, a driver sends a voice note saying the street is blocked and the shop is closed. The agent transcribes it, classifies it as inaccessible address plus customer absent, gathers the history and suggests two paths already defined in the procedure: reschedule for the end of the route or for the next day. It prepares a draft message to the customer with a window, not a fixed time.

The operator chooses to reschedule, approves the message and records the reason. Later, the customer asks whether they will get a discount for the delay. The agent does not answer about amounts: it says the request has been forwarded and opens the case for a person with the full context. AI did the reading, the organizing and the drafting. The decision and the promise stayed with the people who answer for them.

How to apply the method in a pilot: map, limit, pilot, hand over

The method we use to bring AI into business processes fits logistics well, and the order matters.

• Map: describe the current flow from end to end, who decides each step, which systems and channels take part, and the starting point for time and rework. Without that baseline, there is no way to know whether the pilot helped.
• Limit: define which data the agent can see (respecting LGPD and the minimum necessary), which actions it can perform and which require approval. Start with read and draft permission, not write permission.
• Pilot: choose a real, narrow flow, such as classifying incidents for one route or sending delay notices for one type of delivery. Record each agent decision, what was approved and what was corrected, and agree on the success metric beforehand.
• Hand over: at the end of the pilot, give the team documentation, rules and a monitoring dashboard, and decide together whether to expand, adjust or stop.

Two technical supports help. The first is observability: recording what the agent received, decided and executed, in line with the concepts in the OpenTelemetry observability primer. The second is continuous evaluation: building real incident cases with the expected answer and running them after every change, as Anthropic describes in Demystifying evals for AI agents. To structure risk management more broadly, the NIST AI Risk Management Framework offers a useful vocabulary. Once the pilot matures, it is worth thinking about the architecture as a whole, which is covered in company superintelligence layer architecture: five building blocks.

Part of the ongoing monitoring of these agents can be run by Be Human, but the rule of who decides what always belongs to the company.

What operators need to master from now on

The more capable the system, the more valuable the judgment of the person operating it. The operator stops typing and starts reviewing exceptions, calibrating rules and investigating why the agent got something wrong. This calls for three habits: reading decision logs regularly, updating the list of permitted actions when the business changes, and having the authority to pause the agent without asking permission.

It also calls for care with metrics. Measuring only response speed pushes the system to resolve things quickly and badly. Combine speed with the rate of human corrections, complaints and rework, always within what was agreed at the start of the pilot.

Frequently asked questions

Does superintelligence in logistics exist yet? No. What exists are language models, optimization engines and automations combined, covering parts of the routing, incident and communication cycle. Using the concept as a lens helps you decide what to delegate and what to keep with people, but it should not be sold as a current capability.

Can AI decide the day's route on its own? It can propose and recalculate, but approval of anything that changes commitments, safety or driver working hours should stay with the operator. A good start is letting the system act alone only on small, reversible adjustments, always recording the reason.

Can I let an agent notify customers about delays on WhatsApp? Yes, as long as it uses only data confirmed in the system, gives windows instead of firm times when there is uncertainty, and respects the channel's permission and template rules. Any request for compensation or an exception should be handed to a person with the case context.

Where do I start without risking the operation? Choose a single, well-defined flow, such as classifying incidents for one route, with the agent only reading and suggesting. Measure the flow beforehand, record every decision during the pilot, and only then discuss expanding permissions or incident types.

Sources

• Anthropic: Building effective agents
• Anthropic: Demystifying evals for AI agents
• OpenTelemetry: observability concepts
• NIST AI Risk Management Framework