AI for Logistics and Freight Companies: Tracking, Exceptions, Support

AI for Logistics and Freight Companies: Tracking, Exceptions, Support

AI for logistics and freight companies works best when the agent is connected to the tracking system and answers only with what that system records: status, last movement, estimated delivery and open exception. The gain shows up in two places. Repetitive "where is my shipment?" questions get answered immediately, and exceptions get standardized triage and routing, while a person decides anything that involves an exception to policy, cost or risk.

Key takeaways

• The agent should not "know" where the cargo is. It queries the tracking system (TMS, ERP or the operation's API) and reports what is recorded.
• Delivery status is the safest flow to start with, because it is a data read and the answer can be verified.
• Exceptions (recipient not home, wrong address, damage, refusal) need a catalog of types, action rules and a handoff to a human.
• Clear limits matter more than a sophisticated model: what the agent can say, query, record and never promise.
• Start with one real flow, with logs and an agreed metric, and only then decide whether to expand, adjust or stop.

Why are tracking and exceptions a good starting point?

At freight companies, a large share of customer service revolves around a handful of questions: where is my shipment, when does it arrive, why was it not delivered, how do I reschedule, who handles the damage. The answers already exist somewhere, usually in the system that records movements. Much of the human work is opening that system, copying the status and rewriting it in language a customer understands.

This structure suits AI for three reasons. First, the source of truth is clear: the tracking record. Second, the result is verifiable: you can compare the agent's answer with the system data. Third, the question is recurrent, so any improvement pays off every day.

The risk sits in what comes after the status. When the customer asks "so what are you going to do now?", commercial policy, redelivery cost, deadlines and liability come into play. That is where the agent has to know when to stop. For a broader view of what to automate and what to keep with people in support, see the article on AI customer support: what to automate and what to keep human.

What the agent needs to read from the tracking system

A useful logistics support agent does not depend on the model's memory. It depends on tools that query data. The approach of agents with well-defined tools is described in Anthropic's engineering guidance on building effective agents, and the quality of each tool weighs heavily on the result, as their material on writing tools for agents shows.

For tracking, a minimal set of tools is usually enough:

• Look up a shipment by identifier (invoice, CT-e, tracking code or order number), returning current status and event history.
• Look up the estimated delivery as recorded in the system, without recalculating it on its own.
• Look up the open exception for that shipment, with type, date and situation.
• Record a customer request (for example, a rescheduling request) as a pending item, without making the change.
• Hand off to an agent with a summary of the case.

Notice what is not on the list: changing the address, canceling the delivery, approving compensation, promising a new date. These actions can be added later, with human approval, but they do not need to be part of the first version.

Another important decision is customer identification. Tracking by code is different from discussing the details of a delivery. If the agent talks over WhatsApp, define what it shows to someone who only provides a code and what requires extra confirmation, such as the recipient's tax ID or a detail known from the order. Full address, phone number and cargo contents are personal or commercial data and should be exposed with care. The ANPD, Brazil's data protection authority, is the official reference for data protection guidance, and the article on LGPD and artificial intelligence for companies helps organize that discussion internally.

How to answer delivery status without making things up

The main flaw of a poorly configured agent is filling gaps. If tracking shows "in transit" for several days with no new movement, a model without rules may write "your delivery arrives tomorrow." That is worse than not answering.

The agent's instructions should separate three kinds of statements:

• What the system records: "the last event was departure from the destination hub, recorded this morning."
• What the system predicts: "the recorded estimate is this date," always attributed to the system.
• What the agent does not know: "there has been no new movement since the last event; I will pass this to the team to check."

For that reason, the status reply should follow a simple format: current situation, last movement, recorded estimate (if any) and next step. No adjectives, no guarantees. To write these instructions with a method, see the guide on how to write instructions for an AI support agent.

It is also worth defining rules for missing or conflicting data. If the code is not found, the agent asks for a second identifier instead of guessing. If two records are possible, it asks for confirmation. If the tracking system does not respond, it says it could not check and offers a handoff, without inventing a state. The article on handling LLM API rate limits and outages covers continuity when a component fails.

Companies that run ecommerce and ship through carriers meet the same logic on the seller side, described in AI customer service for ecommerce: orders, returns and tracking. For a freight company, the difference is that the agent speaks from the source data, not from a mirror of it.

How to handle exceptions with AI

An exception is any event that deviates from a normal delivery. AI helps in three steps: classify, guide and route. The decision about exceptions to policy stays human.

A simple decision guide for each exception:

• If it is informational (delivery out on route, scheduled attempt), the agent explains the status and closes the conversation.
• If it is a recipient-not-home case or a hard-to-reach address, the agent collects the needed data (availability window, reference point) and records it as a request for the operation to confirm.
• If it involves a wrong or incomplete address, the agent collects the correction, but the change only takes effect after the operation validates it.
• If it involves damage, loss or refusal, the agent shows empathy, collects evidence (photos, description, invoice number) and hands off with a summary. It does not discuss liability or compensation.
• If there is a formal complaint, legal risk or a very upset customer, it hands off immediately, with no attempt to work around it.

For this to work, the company needs an exception catalog with a name, definition, required data, owner and internal deadline for each type. If each agent interprets exceptions differently today, the AI will reproduce the inconsistency. Standardizing first is often the biggest gain of the project, with or without AI.

It is also useful to run the agent in internal mode: it reads the history, summarizes the exception for the support agent and suggests a draft reply. This mode carries lower risk and already saves time, because the support agent no longer has to rebuild the case on every contact.

Illustrative scenario: recipient not home

This is an illustrative scenario, not a real case. A recipient writes to the freight company's WhatsApp saying nobody told them about the delivery and the shipment shows as "unsuccessful attempt."

• The agent asks for the tracking code or invoice number and confirms identity with a detail from the order.
• It queries the system and sees the "recipient not home" exception, with the attempt date.
• It replies with the recorded fact: there was one attempt, the exception is recipient not home, and the shipment is waiting for a new schedule.
• It asks which period the recipient will be available and records the request as a pending rescheduling item.
• It says the operation will confirm the new date. It does not promise a date or charge anything.
• If the customer insists that nobody came to the address, the agent hands off to a support agent with a summary: code, exception, recorded attempt time and the customer's dispute.

In this flow, the agent resolved the information, collected what the operation needed and escalated the only part that requires investigation. The support agent receives the case ready, instead of starting from zero.

What limits and controls does the agent need?

An agent connected to an operational system needs stricter controls than a general-question chatbot. A few practical layers:

• Minimum permissions: the agent's credential only reads tracking and writes pending items. No broad ERP access. OWASP's guidance on risks in LLM applications lists, among other points, excessive agency and prompt injection as risks to address from the design stage.
• Customer text as data, not as orders: messages, photos and notes fields may contain malicious or confusing instructions. The agent must not obey commands that come from that content.
• Output validation: before sending, check that the reply cites only data returned by the query, with no promises of dates or amounts. The article on guardrails for AI agents details input, output and action controls.
• Decision logging: keep the query made, the data returned, the reply sent and the reason for each handoff, for audit and improvement.
• Easy handoff: the customer should be able to reach a person without repeating everything, and the agent should hand off on its own for damage, formal complaints and conflicting data.
• Data minimization: send the model only what the reply requires, not the customer's or the cargo's full record.

If the channel is WhatsApp, the choice between the app and the official API also affects control and traceability. The article on WhatsApp Business API vs app for an AI agent compares the paths.

How to run a pilot without risking the operation

The method we apply in AI projects for operations follows four moves: map, limit, pilot and hand over. In logistics practice, it looks like this.

• Map: list the most frequent questions that reach support, the tracking data sources and the current path of each exception. Record how much time and how many people the flow consumes today, to have your own baseline.
• Limit: choose one flow (for example, status lookup over WhatsApp) and define which data the agent sees and which actions it can record. Anything that changes a delivery, an amount or liability stays out.
• Pilot: run the real flow with a restricted group, with logs, conversation review and a success metric agreed beforehand (for example, resolution without human intervention with an answer that matches the system). The article on how to measure an AI automation pilot offers metrics and decision gates.
• Hand over: give the operation to the team, with documentation, owners and a monitoring routine. Then decide whether to expand, adjust or stop.

A note on integration: if the tracking system has an API, the path is usually read first. If the company wants to expose these queries as standardized tools for agents, the article on how to build an MCP server for internal systems describes the reasoning behind starting with queries only.

What not to automate at the start

Some flows call for caution, even if the technology can execute them:

• Decisions about compensation, refunds or liability for damage.
• Changing the delivery address without validation, because of the risk of cargo diversion and fraud.
• Communicating critical delays to large customers, which usually needs human contact and commercial context.
• Any irreversible action, such as canceling a delivery or releasing a cargo.

These items can be added later, with human approval per action and an audit trail. Learning from the read-only flow before granting write power is cheaper than correcting an operational error.

Frequently asked questions

Can AI replace a freight company's customer service?

Not entirely, and that should not be the initial goal. It absorbs status queries and the first collection of exception details, while people remain responsible for exceptions to policy, damage, negotiation and decisions with financial or legal impact. The division of work should be written down before the pilot.

Do we need to replace our tracking system to use AI?

Usually not. What matters is being able to query the data through an API, a read replica or a reliable export. If the system offers none of these, the first step may be solving that integration, or using AI only internally to summarize cases and suggest replies.

How do we stop the agent from promising the wrong delivery date?

Instruct it to cite only the estimate recorded in the system, attributed to the system, and validate the output before sending to block promises and amounts. When there is no estimate or the data conflicts, the rule is to state the limitation and hand off to the team.

What does LGPD change in this kind of project?

It changes how you identify the customer, how much data goes to the model and how long conversation records are kept. It is worth defining the purpose of the processing, limiting data to what is necessary, assessing the vendors involved, and checking with legal counsel whether an impact assessment is advisable, following ANPD guidance.

Sources

• Anthropic: Building effective agents
• Anthropic: Writing effective tools for agents
• OWASP Top 10 for LLM Applications
• ANPD: Autoridade Nacional de Proteção de Dados