The carrier ETA bot.

The problem

Every morning someone chased every load whose ship date had passed but whose status still said not picked up. Did you pick up? What is your ETA? Per load, per carrier, by hand, first thing, daily.

How it works

• Eligibility is pure logic: dispatched or committed, carrier assigned, ship date today or past. Since October the board pulls itself from a TMS report, so the morning starts with one click and no export upload.
• Thread-finding is deterministic: rate-confirmation subjects carry the shipment ID, so a subject filter finds the carrier thread. More than one match means a human resolves it. The bot never guesses.
• Claude classifies carrier replies read-only: on time, not on time, unclear, auto-reply or bounce. All routing on that verdict is deterministic code.
• One ask per load per day, enforced by a ledger. A cloud cron runs the loop every 20 minutes, business hours only: picked-up loads drop off, out-for-delivery loads highlight, stale asks get a follow-up.
• Shadow first. Version one refused to go live in code even though the schema allowed it. Live mode shipped only after a 114-agent audit, 20 fixes, 223 passing checks and the team's feedback round.

// before the first live send: a 114-agent audit, 20 fixes, 223 passing checks

The result

First cycle on real loads: 35 asks drafted, 16 ETAs confirmed, 3 real problems flagged, in 40 minutes, with three operators working the queue concurrently and zero duplicate asks. The first live cycle sent 14 asks and parked 4 ambiguous threads for a person. The morning chase now runs unattended.