Project Overview
| Client Industry | Logistics / Freight Brokerage |
| Business Type | Mid-size freight brokerage managing ~1,200 active shipments/month across 300+ carrier relationships |
| Project Duration | 16 weeks |
| AI Service Provided | AI Agent Development |
| Technologies Used | Anthropic Claude models, LangChain agent framework, Python, FastAPI, PostgreSQL, Twilio (SMS/voice), AWS (ECS, EventBridge), McLeod TMS API |
The Client Challenge
The client’s dispatch team manually coordinated load bookings, carrier check calls, and exception handling — a process that involved constant phone calls, emails, and manual data entry into their Transportation Management System (TMS).
Their operational reality:
- Each dispatcher managed 25–30 active loads at once, spending most of the day on repetitive check calls (“Where’s the truck?”) and confirming pickup/delivery status.
- When something went wrong a delayed pickup, a missed appointment window, a documentation issue resolution depended on a dispatcher noticing it, which often happened hours after the fact.
- Carrier communication happened across phone, email, and text with no unified record, making it hard to track commitments or spot patterns.
- Nights and weekends had minimal coverage, so overnight exceptions sat unresolved until morning.
- The team was near capacity and couldn’t take on more freight volume without hiring additional dispatchers.
The client didn’t need a chatbot. They needed something that could actually do dispatch work check on loads, contact carriers, update the TMS, and escalate genuine problems to a human.
Our Solution
AirBrite Labs designed and built an AI dispatch agent that performs real dispatch tasks autonomously, with clear escalation boundaries for anything requiring human judgment.
The agent operates on a task-based model: for each active load, it determines what needs to happen next (confirm pickup, request an ETA, verify delivery, chase a POD document) and executes it via automated SMS/voice outreach to carriers, TMS status checks, and status updates without a dispatcher initiating each step.
Key capabilities:
- Autonomous check calls — the agent texts or calls carriers at scheduled intervals to confirm status, using natural conversational prompts rather than rigid scripts.
- Exception detection and triage — when a response indicates a delay or problem, the agent classifies severity and either resolves it (e.g., rebooking a delivery window) or escalates to a dispatcher with full context.
- TMS-integrated actions — the agent reads and writes directly to the McLeod TMS, so status updates are reflected in the system of record automatically.
- 24/7 coverage — the agent runs continuously, closing the overnight and weekend gap that previously went unmonitored.
- Human handoff with context — when escalation is needed, the dispatcher receives a structured summary (what happened, what the agent already tried, recommended next step) instead of a raw alert.
Technical Approach
Agent Framework: Built on Anthropic Claude models using LangChain’s agent tooling for task planning, tool selection, and multi-step reasoning. The agent operates with a defined toolset (send SMS, place call, query TMS, update load status, escalate to human) rather than open-ended autonomy.
Architecture: Event-driven agent runtime on AWS ECS, triggered by scheduled EventBridge rules (per-load check-in cadence) and inbound webhook events (carrier replies via Twilio).
Data Processing: Carrier responses (SMS text or transcribed voice) are parsed and classified by the agent into structured outcomes confirmed, delayed, needs escalation which are logged to PostgreSQL for audit and pattern analysis.
Integrations: McLeod TMS API for load data and status updates; Twilio for SMS and voice communication with carriers; internal Slack integration for dispatcher escalation alerts.
Security & Scalability: Agent actions are scoped and logged every TMS write and carrier communication is auditable and tied to a specific load and decision trail. The system is designed to run thousands of concurrent load check-ins without added dispatcher load, since the agent’s constraint is API throughput, not human bandwidth.
Implementation Process
- Discovery & Requirement Analysis (Weeks 1–3): Shadowed dispatchers for two full weeks to map the actual decision logic behind check calls and exception handling this became the foundation for the agent’s tool boundaries.
- Prototype / PoC (Weeks 4–6): Built a limited agent handling only routine check calls on a subset of 50 loads, with all actions requiring dispatcher approval before execution.
- Development (Weeks 7–11): Expanded the toolset to include exception triage, TMS write actions, and escalation logic; removed approval gating for low-risk actions based on PoC accuracy.
- Integration (Weeks 12–13): Full McLeod TMS and Twilio integration; Slack escalation workflow built with dispatch team input on message format.
- Testing (Week 14): Ran the agent in shadow mode alongside live dispatchers for one week, comparing agent-recommended actions against actual dispatcher decisions.
- Deployment (Week 15): Phased rollout agent given full autonomy on routine check calls first, exception handling enabled two weeks later.
- Optimization (Week 16 and ongoing): Tuned escalation thresholds based on false-escalation rate feedback from dispatchers.
Key Features Delivered
- Autonomous carrier check-call agent (SMS and voice) running on a scheduled cadence
- Exception detection and severity triage with automatic resolution for routine cases
- Direct McLeod TMS read/write integration for status updates
- Structured human escalation with full context handoff
- 24/7 continuous coverage including overnight and weekend hours
- Full audit trail of every agent action and decision
- Slack-based escalation and alerting for the dispatch team
Business Results
- Average time-to-detect a shipment delay dropped from 3–4 hours to under 20 minutes
- Dispatchers freed up roughly 60% of time previously spent on routine check calls, reallocated to relationship management and complex problem-solving
- Overnight exception response time improved dramatically — issues that previously waited until morning were now resolved or escalated within the hour
- The team absorbed a 30% increase in load volume without adding dispatch headcount
- Carrier satisfaction scores improved, attributed to faster, more consistent communication
- TMS data accuracy improved since status updates were logged in real time rather than batched manually at end of shift
Technology Stack
| Layer | Technology |
|---|---|
| AI Agent | Anthropic Claude models |
| Agent Orchestration | LangChain agent framework |
| Backend | Python, FastAPI |
| Database | PostgreSQL |
| Communication | Twilio (SMS, voice) |
| TMS Integration | McLeod TMS API |
| Cloud Infrastructure | AWS ECS, EventBridge |
| Alerting | Slack API |
Why the Solution Worked
The project succeeded because the agent was scoped around real, observable dispatch tasks rather than an abstract “AI for logistics” concept. Shadowing dispatchers before writing a line of code meant the agent’s tool boundaries matched how experienced staff actually made decisions.
Starting with approval-gated actions and expanding autonomy only after the PoC proved reliable also mattered it gave the dispatch team confidence in the system instead of a mandate to trust it blindly. And structuring escalations with context, not just alerts, kept the human dispatchers effective rather than overwhelmed with unfiltered notifications.
Future Scalability
The agent architecture is built to take on additional dispatch responsibilities over time. The client is currently scoping:
- Extending the agent to handle initial load booking negotiations with carrier partners
- Adding a customer-facing status agent so shippers can get real-time updates without calling dispatch
- Building a predictive layer that flags loads likely to encounter delays before they happen, based on historical carrier and lane performance
- Expanding TMS integration to support additional back-office systems as the brokerage grows
Because the agent’s tools and escalation logic are modular, new capabilities can be added as additional tools without re-architecting the core system.
Final Outcome
The AI dispatch agent turned a reactive, manually-intensive dispatch process into a proactive, continuously monitored operation. The brokerage now handles significantly more freight volume with the same team, responds to problems before they escalate, and gives dispatchers back the time to focus on the judgment calls that actually require a human.
