Case Study · Intermodal Drayage & EDI

How Chicago Intermodal Transportation built an AI-operated order desk

Q: How does AI automate EDI 204 load tenders?

An AI-operated pipeline watches the EDI tender queue, follows each tender through its lifecycle (the 204 load tender, the 990 acceptance, then revisions and cancellations) and posts the order to the TMS once the trading partner’s acceptance cycle completes. At Chicago Intermodal Transportation, structured EDI is handled by deterministic code, and Claude steps in only where judgment is needed: prose appointment windows, implied rail routings, missing fields. Orders typically reach the TMS in under a minute.

Q: Can AI read emailed rate confirmations and bills of lading?

Yes. CIT’s second intake channel reads monitored Microsoft 365 mailboxes and handles dozens of customer and broker formats: PDF rate confirmations, bills of lading, spreadsheets and plain-text tenders. Fast parsers handle the known formats, OCR handles scans, and Claude’s vision capability reads whatever the first two can’t. If extraction fails, an AI recovery pass re-reads the original and completes the order.

Q: How do you stop AI from creating duplicate or wrong orders in a TMS?

With layered guardrails. Every order is validated before entry, and anything the system can’t confidently fix goes to a person. After entry, the order is read back from the TMS and compared to the source document. Duplicates are blocked by reference and content-signature checks, followed by an independent sweeper. TMS change-log audits show platform-entered orders need fewer corrections than manual entry.

Q: What is a relay agent in logistics?

A relay agent is AI that carries a piece of work across every handoff (intake, understanding, validation, entry, verification and escalation) without losing context along the way. In CIT’s pipeline, each stage passes a fully understood order to the next, and an operations agent in Microsoft Teams picks up anything that needs a person. We explain the idea in The Agent Relay.

Q: Can an AI agent work inside Microsoft Teams?

Yes. CIT’s operations agent lives in Teams. It clears exceptions it can prove are resolved and walks staff through the rest in plain language. Staff can chat with it, and it can make corrections to orders on request, but each one is gated and requires confirmation.

Q: Is AI order automation reliable enough for 24/7 freight operations?

Only if reliability is designed in from the start. CIT’s platform assumes every component will eventually fail, with self-healing monitors, an off-site Azure watchdog and a drill-tested warm standby. Through multiple real infrastructure incidents, post-incident audits confirmed zero lost orders.

Q: Does AI order automation only apply to drayage carriers?

No. Any operation that receives orders through EDI, email or documents and keys them into a system of record has the same pattern: freight brokers, 3PLs, distributors, manufacturers and wholesalers. See how Johanson Transportation uses AI agents, or explore AI and BI for logistics.

Q: How long does an EDI and AI integration take?

CIT’s platform was built in layers: EDI and email intake first, then the AI repair layer, the Teams operations agent, the reliability tooling, and most recently dispatch decision support. Each layer went into production as soon as it proved itself. FreshBI typically delivers a first production solution in as little as three weeks. See pricing.

EDI load tenders and emailed rate confirmations become complete TMS orders in about a minute, around the clock, across four dispatch offices. Working with AI partner FreshBI, Chicago Intermodal Transportation (CIT) put Anthropic’s Claude to work across its whole order lifecycle, wrapped in a self-healing layer that has lost zero orders through real infrastructure incidents.

Talk to us about your business See how it works

<1 min

typical time from tender acceptance to a complete order in the TMS

orders lost through real infrastructure incidents

dispatch offices running on the platform since March 2026

24/7

intake with self-healing monitoring, recovery and escalation

1 Business first Start from the order desk: for a carrier, order speed is service speed.
2 Ontology first One governed pipeline from tender to a verified TMS order.
3 AI ready AI judgment inside guardrails, with dispatch decision support next.

About Chicago Intermodal Transportation

Chicago Intermodal Transportation (CIT) has spent 30 years building one of the leading intermodal trucking operations in its category. Headquartered in Alsip, Illinois, CIT runs 53-foot domestic intermodal and local, regional and cross-town drayage from terminals in Chicago, Indianapolis, Kansas City, St. Louis, Louisville, Minneapolis and across Florida. It is bonded and SmartWay certified, and national brands trust it as their house carrier.

Founded by a driver, CIT made an early move on AI for a simple reason: when a carrier is known for reliability, the order desk is where that reliability begins.

Business first

An order desk built on keystrokes

Every load starts as a tender. At CIT, tenders arrived through two very different channels, and all of them had to be keyed into the TMS by hand. Manual entry took dispatcher hours and delayed order availability. CIT set out to automate it without giving up any of the accuracy or control its customers count on.

Two channels, one keyboard

Hundreds of EDI and emailed tenders a week, across four offices and dozens of formats, all keyed by hand. Some arrived as EDI transactions; the rest as emailed PDFs, spreadsheets and free-text tenders.

Every field matters

Parties, appointment windows, rail ramps, container and reference numbers, revisions and cancellations. One mistyped container number or missed appointment change means a wasted trip to the ramp.

Order speed is service speed

A tender isn’t a load until it’s in the TMS, and dispatch can’t plan around it until then.

It can’t go dark

Order intake is mission-critical. The automation had to keep the accuracy and control customers count on, and never drop an order, even during an outage.

Ontology first

Define a complete order once, whatever channel it arrives on

Before AI touched a tender, the pipeline defined what a complete, valid order looks like. EDI and emailed documents both resolve into that one definition before anything reaches the TMS.

Rules first, AI for judgment

Structured EDI goes through deterministic code. Claude is used only where judgment is needed: appointment windows written as sentences, rail routings that are implied rather than stated.

Customer lane history as governed context

When a required field arrives empty, it is filled from that customer’s own lane history, with confidence thresholds and a kill switch keeping it in check.

Verified against the source

Every order is validated before entry, then read back from the TMS and compared to the source document, so the system audits its own work.

The solution

One AI relay from tender to dispatched order

FreshBI built an automated order desk that watches both intake channels around the clock. It understands each document, enters complete orders into the TMS, checks its own work, and tells a person the moment something genuinely needs one, in plain language, inside Microsoft Teams. Code handles what rules can handle, Claude handles the judgment, and nothing reaches the TMS until it’s verified.

How an order moves

Five stages, one continuous relay

A person is brought in, through Microsoft Teams, only when one is genuinely needed.

1
Intake
Each office’s EDI tender queue and monitored mailboxes, watched continuously.
2
Understand
Format-specific parsers, OCR, then Claude for the documents rules can’t read.
3
Validate & repair
Every order is checked before entry. The AI fixes what it can, re-checks it, and routes the rest to a person.
4
Enter & verify
Posted to the TMS, then read back from the database and compared to the source.
5
Watch & escalate
Self-healing monitors, and an AI agent that briefs the ops floor in Teams.

01 · EDI intake · X12 204 / 990

Load tender automation that understands the lifecycle

Each office’s EDI tender queue is watched continuously, and the pipeline handles the full standard lifecycle: load tenders (204), acceptance responses (990), revisions and cancellations.

Lifecycle-aware: it tells “waiting on the partner” apart from “actually stuck”, and only alerts on the second.
Revision-safe: change tenders update only the fields that changed and never overwrite a dispatcher’s manual edits.
Sustained throughput: about two complete orders per minute, per office, during backlogs.

02 · Email & documents · Microsoft 365

Rate confirmations and BOLs in any format

Monitored mailboxes cover dozens of customer and broker formats: PDF rate confirmations, bills of lading, spreadsheets and plain-text tenders. Fast parsers read the known formats, OCR handles scans, and Claude’s vision capability reads whatever the first two can’t.

Layered reading: fast parsers, then OCR, then Claude’s vision for whatever rules can’t read.
Nothing dropped: if extraction fails, an AI recovery pass re-reads the original and completes the order.

03 · The AI layer · Anthropic Claude

AI used for judgment, inside guardrails

Claude is applied where rules run out, and every use sits inside a check.

Hard fields: appointment windows written as sentences and rail routings that are implied rather than stated.
Backstops: empty required fields filled from the customer’s own lane history, with confidence thresholds and a kill switch.
Validate, repair, re-validate: anything not confidently fixable goes to a person.
Self-audit: every order is read back from the TMS and compared to the source document.

04 · Operations · Microsoft Teams

An AI operations agent for dispatch

Staff never see parsers or queues. Every working hour, an agent in Teams clears exceptions it can prove are resolved and walks staff through the rest in plain language.

Two-way chat with gated, confirmation-protected order corrections.
Morning departure scans flag next-day loads missing critical details before they become service failures.
Live dashboard and two-way sync with the team’s existing issue tracker.

Built to never lose an order

Self-healing

An AI health agent diagnoses, restarts, verifies and escalates in Teams, with a deterministic panic path if it can’t fix the issue itself.

Off-site watchdog

An Azure heartbeat alerts within minutes, even in a full site outage. The alarm doesn’t live in the building that’s on fire.

Warm standby

A drill-tested cloud failover can take over order entry during a long outage, with strict controls so two systems never post the same order.

Duplicate defense

Checks before entry, verification after, and an independent sweeper scanning for duplicates behind everything else.

Human edits respected

Values a dispatcher set by hand, especially appointment times, are recognized and never overwritten.

Proven under fire

Post-incident audits through multiple real infrastructure incidents confirmed zero lost orders.

The results

What changed for Chicago Intermodal

Orders in the TMS in about a minute instead of waiting for someone to type them in, across both channels at all four offices.
Fewer corrections than manual entry. TMS change-log audits show platform-entered orders need fewer corrections than manual entry.
A backlog turned into a managed list. About two-thirds of outstanding exceptions were cleared by the agent in its first passes.
Zero lost orders through multiple real infrastructure incidents.
No new tools to learn. Teams, a browser dashboard and the issue tracker the team already used.

AI ready

AI that is measured, with dispatch decision support next

CIT’s platform is AI-ready in production: every layer is validated, audited and measurable. The newest layer extends that discipline to dispatch decisions.

AI only where judgment is needed

Structured EDI goes through deterministic code, which keeps the system fast, predictable and auditable. Claude handles the hard cases.

The system checks its own work

Validation before entry, read-back after it, and an independent sweeper behind everything mean CIT can trust the automation without double-checking every order.

What’s next: decision support, in shadow mode

A recommender scores how well each driver fits each load, using lane history, reload pairing, rail-ramp positioning and live hours-of-service data. It writes nothing to the TMS and measures its agreement with every real assignment, so its accuracy is a tracked number, not a claim.

CIT’s platform is a working example of what we call the Agent Relay: AI that carries work through every handoff with nothing lost between steps, and hands off cleanly to a person whenever one is needed. See how freight broker Johanson Transportation applies the same idea for its customers, and explore AI and BI for logistics.

EDI automation & AI for logistics: common questions

How does AI automate EDI 204 load tenders?

An AI-operated pipeline watches the EDI tender queue, follows each tender through its lifecycle (the 204 load tender, the 990 acceptance, then revisions and cancellations) and posts the order to the TMS once the trading partner’s acceptance cycle completes. At Chicago Intermodal Transportation, structured EDI is handled by deterministic code, and Claude steps in only where judgment is needed: prose appointment windows, implied rail routings, missing fields. Orders typically reach the TMS in under a minute.

Can AI read emailed rate confirmations and bills of lading?