Weekly analysis 18-24 May. North Milan zone: delays +41% vs 12-week average, Carrier C, pattern present for 3 weeks. Fragile items: damage 3.2% vs baseline 0.8% on 2 hubs. Complaints: +28 vs previous week on Turin belt postcodes.
AGENT · DELIVERY ANOMALY WATCH
Delivery anomalies surface before the complaint spike.
Delivery Anomaly Watch monitors the logistics operator's deliveries weekly and identifies anomaly patterns: systematic delays on specific zones, customer complaint clusters, anomalies on specific carriers or items. Structured alert to the operations manager for proactive action, before complaints accumulate.
Delivery Anomaly Watch at work.
On Carrier C I'll open a contractual review this week. On the hub I'll bring in the hub manager for packaging. Confirmed.
Decisions recorded. Next analysis Sunday 31 May.
Why it exists.
Mid-to-large logistics operators handle thousands of deliveries per day. Anomaly patterns — zones with systematic delays, carriers with high complaint rates, items with elevated damage rates — are often only identified after complaints accumulate, when the problem is already structural.
How it works each week.
Delivery Anomaly Watch reads the delivery data weekly: actual times versus planned times, outcomes (delivered, missed delivery, damage), customer complaints, damage reports. It compares against the aggregate baseline and by cluster — geographic zone, carrier, item type — and identifies statistically significant deviations. For each anomaly it proposes a concrete action.
The decision stays with the manager.
The operations manager decides on interventions. The agent does not modify contracts, does not reassign shipments autonomously, does not open complaints without approval.
The operations teams that move from reaction to prevention.
Logistics operations manager
Has a structured view of delivery anomalies every week, not only when complaints cross the critical threshold. Intervention decisions — carrier review, packaging process change, problem zone analysis — arrive based on measured patterns, not anecdotal reports.
Week 23 312 shipments
Madrid-South zone avg delay 28'
Complaint cluster 8 similar tickets
Carrier · Y performance ok
Brief to delivery lead
Customer service manager
Sees the correlation between systematic delay zones and customer complaint spikes. Understanding anomaly clusters makes it possible to get ahead of customer communications before complaints arrive.
Routes · 06:00 42 vehicles
Driving hours Reg. EC 561
Urban LTZ 2 detours
ADR · class 3 dedicated route
12 minutes saved per vehicle
Carrier contracts manager
Has structured data for contractual reviews: delay rate per carrier, trend over time, comparison with the baseline. Negotiation stops relying on impressions.
Dock BK-4 12 slots today
09:30 · carrier A high priority
10:15 · carrier B standard
11:00 · carrier C delayed · rescheduled
Average wait time: 18'
A delivery anomaly detected early, before it becomes a complaint.
Monday morning, three flagged anomalies.
For a logistics operator with four hundred daily deliveries across a regional area, Monday morning is the weekly brief moment. Delivery Anomaly Watch processed the previous week's data over the weekend: actual times, delivery outcomes, complaints received by customer service, damage reports.
Three clusters with structured patterns, not anecdotes.
The operations manager opens the Slack channel and finds three flagged anomalies. The first involves a peripheral zone where the delay rate has risen to forty-one percent above the twelve-week historical average, concentrated on a single carrier and present for three consecutive weeks. The second involves fragile items with a damage rate three times above baseline at two specific hubs. The third flags a complaint cluster on four adjacent postcodes.
The manager decides. The agent records.
The manager decides: opens a contractual review with the problem carrier, calls the hub manager in for a packaging process review, alerts customer service on the four postcodes for proactive customer communication. The decisions stay in the runtime audit registry, queryable by management with a standard SQL client.
Declarative rules from the customer's operations team.
The rules of Delivery Anomaly Watch are declarative. The customer's logistics operations team defines in a readable format the relevant anomaly patterns (e.g. delay rate above threshold for N consecutive weeks, damage rate exceeding the configured percentage for an item category), the analysis segmentations (by zone, by carrier, by goods type), and the thresholds that trigger the alert. The rules live in the customer's repository, versioned, validated at agent startup.
- Language
- TypeScript (Node.js)
- LLM model
- customer's choice: Anthropic, OpenAI, Mistral, open source models hosted internally, AWS Bedrock for a private model
- Built-in controls used
- pii-detector, tool-rate-limit
- Native delivery channels
- Slack, Telegram, WhatsApp, OpenAI-compatible HTTP
- Scheduling
- configurable per instance (typical weekly, end of weekend or Monday morning)
- TMS integration
- dedicated adapter built during delivery by the Exelab team
- Customer complaint system integration
- dedicated adapter built during delivery by the Exelab team
- Memory
- persistent per instance, pgvector + PostgreSQL FTS
- Registry
- immutable, queryable with a standard SQL client
How Delivery Anomaly Watch works in detail.
The cardinal data point is the delivery trace with planned and actual timestamps. Customer complaints and damage reports complete the picture. The customer's TMS is the primary source. TMS integration is built during delivery via a dedicated adapter; the Exelab team maps the available data sources during discovery.
The standard frequency is weekly. For operators with high volumes (thousands of deliveries per day) it is possible to configure more frequent analysis — twice-weekly or daily for high-risk clusters. Frequency is defined during declarative rule configuration.
The agent evaluates temporal persistence: an anomaly on a zone for three consecutive weeks is structurally different from a one-off delay caused by a weather event. Persistence and statistical significance thresholds are configurable by the operations team. Documented exceptional events (strike, certified severe weather) can be added as exceptions in the rules to prevent false positives.
The typical pattern is 10-14 weeks. Discovery and data source mapping two weeks, anomaly rule and segmentation configuration three weeks, TMS and complaint system integration three weeks, testing on real data and hand-off to the operations team two weeks. Actual duration depends on the availability and quality of historical data in the customer's TMS.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how Delivery Anomaly Watch would configure to the customer's case. Which TMS, which anomaly patterns are the priority, which segmentations matter.