Case studies

Fourteen production builds. These six carry the day.

All of this was built for a freight brokerage, on live freight, from inside the seat that does the work: 33 days, 150 commits, 121 test and probe scripts, one developer. Freight is where the approach was proven. The approach itself transfers to any operations-heavy back office.

// client details anonymized; every metric from production logs and commit history

Silent data corruption, ended

The load-posting converter

The problem

Posting container loads to the DAT load board went through an old Excel macro workbook: refresh the TMS, download the export, paste, upload. About five minutes a cycle, many cycles a day. And the macro had a habit: every so often it looked at a weight like 2500 and decided it was a date. The posting went live offering freight that weighed November 4, 1906. Spreadsheet automation fails silently, in the middle of live commercial data, and the cost is a phone call you never knew you missed.

How it works

Reads the TMS shipment export and emits load-board bulk-posting files, every field derived by code that cannot reinterpret a weight as a date.
A dedupe ledger remembers every posted shipment, so re-running an overlapping export posts nothing twice. Incomplete rows are skipped by name and self-heal on a later run once their data arrives.
Rates are deterministic: a fixed percentage of the sell rate, truncated to whole dollars. Output splits at 50 rows per file because the load board's bulk upload gets flaky above 80.
Every processed export archives itself. Nothing is deleted, ever.

// a weight can never become a date again; every field is derived, not reinterpreted

The result

4,342 loads posted across 442 batches with zero corrupted fields, in the tool's first days of life alone. Each posting cycle now costs seconds: drag the export in, click once.

AI that haggles without ever touching a price

The carrier negotiation bot

The problem

Carriers email about posted loads all day and haggle. Someone answered every one by hand, and the after-hours ones went unanswered entirely. Industry job boards are full of $45,000 to $60,000 a year roles for exactly this work.

How it works

Every dollar figure a carrier ever sees originates in a pure, deterministic pricing module with a fixed ladder and a hard floor. The AI can only phrase numbers this module returns; it cannot invent one.
Claude reads each inbound email and produces structured intent (an ask, a counter, an acceptance, something off-script) for about $0.003 per email. It never writes the reply and never chooses the route.
A pure state machine runs the protocol. Agreement is the only outcome that reaches a human. A negotiation that fizzles dies politely. Anything off-script parks silently for review.
Carrier vetting is a deterministic chain: pattern extraction of MC/DOT numbers, the federal carrier registry, then the TMS. The ambiguous middle parks for a human.
Three modes: off, shadow (writes drafts), live (sends in-thread), plus per-thread human takeover.

// the AI never touches a price; every dollar comes from a deterministic ladder

The result

Proven in shadow against real inbound carrier email. Roughly forty behavior refinements came from watching it run against live traffic before it ever sent a word. Per-email cost is about $0.003 against category incumbents charging about $45,000 a year.

The morning chase, automated

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.
Thread-finding is deterministic: rate-confirmation subjects carry the shipment ID, so a subject filter finds the carrier thread. If more than one thread matches, 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 cron runs the loop every 20 minutes, business hours only; off-hours ticks cost nothing.
Version one refuses to go live in code, even though the schema allows it. Shadow mode first, always.

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

The result

First live cycle: 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 morning chase now runs unattended.

One-way doors get double guards

Auto-cancel noise suppression

The problem

When a posted load times out uncovered, the shipper auto-generates a cancellation-request email to the senior brokers. Routine, high volume, and it buries the rare email that matters: a carrier bailing on a load that was already committed. Preempting the routine ones by hand cost a median of 1h11 of attention per load.

How it works

The app already knows every posted load and its worst-case deadline clock. Auto-cancel releases loads past deadline in the TMS before the shipper's timeout fires, so the noisy email never gets generated.
A cancel in this TMS is a one-way door: there is no un-cancel. So the invariant is re-checked with a live read immediately before the irreversible write. A timer alone can never fire it.
The shipper does not auto-cancel overnight, so an overnight load is still coverable and gets deferred, not preempted. The business behavior is modeled, not steamrolled.
The module splits three ways (pure decision, reads, the single irreversible write) so the decision logic is unit-tested without ever touching a live system that has no undo.

// never cancel unless still an open quote with no carrier, re-read live immediately before the write

The result

Routine cancellation noise suppressed at the source. The important cancellations stand out again, and a median 1h11 of per-load manual attention went back to the desk.

Paste, review, apply

Delivery date adjustments

The problem

The owner re-dated delivery appointments in the TMS by hand, load by load, from a table he received by email. A recurring owner-level chore, done at owner-level cost.

How it works

Paste the table, review what the tool plans to do, click Apply. Each row resolves to its single live shipment; the final stop's estimated delivery window moves to the appointment date.
When the shipper re-tenders a load, the same reference matches several shipments. The resolver enumerates the candidates and keeps the only live one. The probe itself sends an empty update so probing can never stamp a field as a side effect.
Two TMS landmines are documented right in the module: the endpoint re-labels wall-clock times without converting them, and there is no undo.
Nothing writes until a human clicks Apply, loads process one at a time, and every write is read back to confirm it stuck.

// nothing writes until a human clicks Apply; every write is read back to verify

The result

The owner's manual re-dating chore replaced by paste, review, apply. In daily use by the owner, who found two edge cases in his first week; both shipped as fixes the same day.

Rate guessing, eliminated

The uncovered-loads auto-classifier

The problem

The TMS export literally cannot tell two load programs apart (every row carries the same customer name), but they post at different rates. Operators picked a converter by eye and sometimes guessed wrong. A wrong guess is a mispriced live posting.

How it works

For each committed-but-uncovered load, the app calls the TMS API and reads the reference field that names the program, then applies that program's deterministic rate rule.
One program prices at a fixed percentage; the other from an owner-editable box-count table stored behind a clamp that guarantees well-formed tiers, so a garbled payload can physically not corrupt rate math.
Transient API failures retry rather than mis-file. A separate reference counter keeps batch numbers from ever colliding with the main sequence.

// an unclassifiable load is held for human review, never posted at a guessed rate

The result

Rate guessing eliminated. Three manual converter variants collapsed into one auto-classifying flow, and the owner edits his own rate percentages in the UI instead of asking for code changes.

Your version of this exists.

Different industry, same shape: a repetitive workflow, a fragile spreadsheet, an inbox someone babysits. Tell me what the manual work looks like and I can usually name the first build in one conversation.

Book an intro call or write to rivelli@kylerivelli.com