Logistics / 2026

An agent pipeline for freight booking intake

Three cooperating agents that read inbound booking emails, extract shipment details, check them against rate and capacity data, and queue clean bookings for a dispatcher to approve.

Sample project: an illustrative engagement showing how we scope and build this kind of work.

agents in the workflow
3
bookings reviewed by a dispatcher in phase one
100%
target time from email to draft booking
< 2 min

Context

This sample engagement describes a mid-sized freight operator that takes most of its bookings by email. Customers send requests in every format imaginable: free text, forwarded threads, spreadsheets, PDFs of bills of lading. A small dispatch team reads each one, retypes the details into the transport management system, checks rates and capacity, and replies with a confirmation or a question.

Challenge

The work is repetitive but not simple. Requests are often incomplete, addresses are ambiguous, and the same customer may describe a pallet three different ways in one week. A rules-based parser had been tried and abandoned because it broke on anything unusual. The team wanted to spend their time on exceptions and customer relationships, not data entry, but they were not willing to let software book freight without a person checking it.

What we built

We scoped a pipeline of three narrow agents, each with one job and a limited set of tools:

  • Intake agent. Reads each new email and its attachments, classifies it (new booking, amendment, query, other) and extracts shipment fields into a structured record. Anything it can’t classify confidently goes straight to a person.
  • Validation agent. Checks the record against the customer’s account, the rate card and lane capacity. It flags missing or inconsistent fields and drafts a clarification email where needed.
  • Booking agent. Prepares a draft booking in the transport management system and a confirmation reply, but does not submit either.

Dispatchers work from a review queue in a small internal web app. Each item shows the original email, the extracted fields with the source text highlighted, any flags, and the drafted reply. They approve, correct or reject with one click. Corrections are stored and added to the evaluation set.

Architecture

The agents run as a LangGraph workflow on AWS, triggered by a Microsoft Graph subscription on the shared bookings mailbox. Each step writes its inputs, outputs, tool calls and model usage to PostgreSQL, which also backs the review app. Hard limits on retries, tokens and spend apply per email. The transport system is accessed through a thin internal API that only exposes the operations the booking agent needs.

An evaluation set of several hundred historical emails, labelled with the correct booking, runs on every prompt or model change. The plan only lets agents submit bookings without review for specific customers and request types once accuracy on that slice stays above an agreed threshold.

Stack

Claude API for extraction and drafting, TypeScript and LangGraph for orchestration, PostgreSQL for state and audit logs, Next.js for the review app, Microsoft Graph for mailbox access, deployed on AWS.

Have something you want built?

Tell us what you are trying to do and where it is stuck. We will reply with questions, an honest view on the right approach, and next steps.

Start a conversation