AI Agents for Logistics

The agent queries connected carrier APIs and rate engines, FedEx, UPS, DHL, regional LTL carriers, and freight brokers exposing REST or EDI interfaces, using the shipment parameters (origin, destination, weight, dimensions, service level, and any shipper-specific routing rules) as the structured input. Rate comparison applies your routing guide logic: preferred carriers per lane, rate cap thresholds, service level requirements, and any carrier scorecards configured in the TMS.

When a carrier meets all selection criteria, the agent generates the booking request, submits it via the carrier's booking API or EDI 204 transaction, and writes the confirmation back to the TMS record, including PRO number, estimated pickup window, and carrier contact. Confirmation is sent to the warehouse team via the configured notification channel (email, Slack, or TMS task) with the full booking summary.

The agent handles the matching and booking; business logic for lane exceptions, spot-market decisions, and new carrier relationships remains with your team. Bookings outside the routing guide, loads requiring manual negotiation, oversized freight, or hazmat shipments with carrier-specific requirements, are flagged with the specific gap and routed to the appropriate person. The audit trail captures every rate query, carrier ranked, and booking submitted, so lane performance data accumulates automatically without dispatcher data entry.

Stateful workflow management using LangGraph models the multi-step booking process, rate query, carrier ranking, routing guide match, booking submission, confirmation write-back, as a directed graph with explicit state transitions. Human-in-the-loop checkpoints are configurable per shipment type, so high-value or sensitive lanes can require approval before the agent submits a booking.

The agent generates the customs document set from structured shipment data already in your TMS or order management system: commercial invoice, packing list, certificate of origin, shipper's export declaration, and HS code classification. It reads product master data (description, country of manufacture, HS code if available, value per unit) and shipment details (consignee, incoterms, declared value, quantity) to populate each document template.

HS code classification uses a combination of a trained classification model and a customs knowledge base. For products with existing HS codes in the product master, the agent validates the classification against the current tariff schedule and flags any codes that have changed. For new products without an existing code, the agent proposes a classification with a confidence score and routes low-confidence classifications to a trade compliance reviewer before the document is finalised. The reviewer sees the proposed code, the classification rationale, and any similar products already classified, enough context to confirm or override in seconds rather than researching from scratch.

Document generation produces structured outputs formatted for the destination country's requirements. For shipments to the United States, the agent generates the CBP Form 7501 electronic equivalent via ACE filing. For EU destinations, it produces the SAD (Single Administrative Document) fields required for customs entry. Country-specific requirements (licences, certificates, phytosanitary documents) are flagged by the agent when the product category and destination combination triggers them.

The agent does not submit to customs authorities without a human review step for new trade lanes. For established lanes with validated document templates and stable product catalogs, the review step can be set to exception-only: the agent submits automatically and a compliance reviewer sees only documents that triggered a validation warning. Every document generated, validated, and submitted is captured in the audit trail with the input data, the generated output, and the reviewer action.

The agent monitors live tracking feeds from carrier APIs and parcel data aggregators (project44, Fourkites, or direct carrier polling) and classifies each exception event against a defined taxonomy: weather delay, missed pickup, address correction required, customs hold, damage reported, refused delivery, and lost in transit. Classification uses the carrier exception code, the shipment's current location, historical carrier performance on that lane, and any open exceptions already logged for the same consignee.

Resolution logic applies automatically for exception classes with defined playbooks. A weather delay on a carrier with a 98% on-time recovery rate on that lane triggers a customer notification with the revised ETA and no dispatcher action. An address correction exception triggers a structured request to the consignee via email or SMS for the corrected address, submits the address update to the carrier, and updates the TMS record. A damage report triggers a carrier claim initiation workflow, the agent generates the claim form with the shipment details, photos from the carrier report where available, and the declared value, and routes it to the claims team with the case already documented.

Escalation to a dispatcher happens when the exception falls outside the resolution taxonomy: a shipment has been in exception status for longer than the lane's typical resolution window, a high-value order is affected, the consignee has a flagged service level agreement, or the resolution action requires commercial judgment the agent is not configured to make. The dispatcher receives the exception with the agent's classification, the resolution actions already attempted, and the recommended next step, not a raw tracking event requiring interpretation.

The agent processes exception events across the entire active shipment base continuously, not in batches. Dispatchers handle the outliers; the agent handles the volume of routine exceptions that represent the majority of exception events for any carrier mix.

The agent pulls structured tracking data from carrier APIs, parcel aggregators, and ocean carrier platforms on the configured polling interval, normalises the event data to a unified status taxonomy (picked up, in transit, out for delivery, delivered, exception), and pushes structured updates to the configured downstream systems: customer-facing portals, ERP shipment records, e-commerce platform order status, and internal Slack or Teams channels for high-priority shipments.

Customer-facing update messages are generated from the tracking event data using a message template system with personalisation tokens: consignee name, order reference, carrier, estimated delivery date, and any exception context. Message tone and content are configurable per customer segment, retail B2C consignees receive consumer-formatted messages, B2B recipients receive structured operational updates. Delivery confirmation messages include the delivery timestamp and, where the carrier API provides it, the delivery location description (front door, reception, neighbour, etc.).

The agent maintains a status history for each shipment, enabling on-demand status retrieval without polling the carrier API for every customer query. A customer service agent asking "where is order 98765?" gets the answer from the agent's status cache in seconds rather than waiting for a live carrier API call. The cache is updated on each polling cycle and invalidated when a delivery or exception event is received.

High-priority shipments, defined by order value, customer tier, or manual flag in the TMS, receive more frequent polling and immediate push notifications on any status change. Standard shipments are polled on the default interval. The frequency tiers are configurable without code changes.

The agent matches carrier invoices against rate confirmations, BOLs, and TMS shipment records to identify billing discrepancies before payment. The matching logic checks billed weight against shipment weight, billed accessorials against the accessorials recorded in the TMS (fuel surcharge, residential delivery, liftgate, inside delivery), billed rate against the contracted rate for the lane, and billed shipment count against the BOL count for multi-piece shipments.

Discrepancies are classified by type and amount: weight disputes, accessorial disputes, rate disputes, and duplicate invoices. For discrepancies below a configurable threshold, the agent generates a dispute notice to the carrier with the shipment reference, the billed amount, the expected amount, and the supporting documentation, the matched rate confirmation and TMS record, and routes it through the AP workflow with a hold flag until the dispute is resolved. Discrepancies above the threshold are escalated to a freight auditor with the full matched record for review before any dispute is filed.

The agent processes invoices in the format the carrier delivers them: EDI 210 (carrier freight invoice), PDF invoices parsed via document intelligence, or structured CSV from carrier billing portals. Invoice ingestion handles all three formats and normalises them to the same matching schema before the reconciliation logic runs. This means the agent handles the full carrier mix without requiring each carrier to change their billing format.

Recovery data accumulates automatically: every dispute filed, every carrier response, and every resolution is captured in the audit trail. Monthly reconciliation reports are generated showing total billed, total disputed, total recovered, and dispute resolution rate by carrier, giving the freight finance team the data they need to evaluate carrier billing accuracy without manual aggregation.

The agent analyses historical shipment volume, seasonal patterns, customer order history, and any external demand signals (confirmed customer purchase orders, promotional calendars, industry index data) to generate lane-level and carrier-capacity forecasts across the configurable planning horizon. Forecasts are produced at the granularity your procurement and carrier relations teams work at: volume by lane per week, volume by carrier per month, and total network capacity requirement per quarter.

The forecasting model is built on time-series methods (SARIMA for seasonal patterns with stable history, Prophet for lanes with irregular seasonality or external regressor data) with a fallback to exponential smoothing for lanes with insufficient history. The model selection and parameter tuning runs automatically when the forecast is retrained on the updated shipment history. Forecast accuracy metrics (MAPE by lane, bias by carrier) are published alongside each forecast run so the procurement team can see which lanes the model handles well and which require manual adjustment.

The agent surfaces capacity risk signals: lanes where the forecast volume exceeds the contracted carrier capacity, lanes where carrier performance has degraded below the threshold that would make the current volume commitment problematic, and lanes where historical variance is high enough that the point forecast understates the likely capacity requirement. Each signal includes the supporting data, the forecast volume, the contracted capacity, the carrier's recent on-time performance, and the historical variance, so the carrier relations team can act on specific evidence rather than a generic alert.

Procurement actions (requesting spot capacity, adjusting contracted volumes at renewal, shifting volume between carriers) remain with the carrier relations team. The agent provides the forecast and the risk signals; the commercial decisions stay with the people who manage the carrier relationships.