Client Project · Red Dog Logistics · Freight Brokerage
Built for Red Dog Logistics. Lives in the dispatcher's own Outlook. Scores carriers on a hundred-point scale, negotiates within margin guardrails, and stops the moment it isn't sure. It runs while you sleep. It never overrides your judgment.
Red Dog Logistics runs a mid-market freight brokerage on Microsoft Outlook and their in-house TMS. Their dispatchers spend most of their day inside two applications: their inbox and their order system. We built TTMS Mailer to close the loop between them — so the AI doesn't sit alongside the dispatcher's workflow, it lives inside it.
Tender requests, carrier quotes, rate counters, status inquiries, RFP CSVs, PDFs, forwarded threads with signature noise. Every single one is a load, a lane, a margin decision — or spam. Sorting them is the job.
Booking a load to the wrong carrier. Missing a shipper's counter. Quoting a lane below margin because the DAT number moved and nobody updated the spreadsheet. Losing a customer to a competitor who replied first. They lose it three cents per mile at a time.
Black-box pricing models that spit out a number with no math. TMS-bundled AI assistants that replied on top of a teammate's thread. Autonomous email agents that fuzzy-matched a load and booked it to the wrong shipper. Dispatchers turned them off after the first incident and never turned them back on.
If a specific order ID is referenced but not found in TTMS, the agent stops. No fuzzy fallback. Ever.
No autonomous booking below the margin floor. 14% target, $125 hard floor, 10% carrier-side floor — enforced server-side, not in a prompt.
If a pod member has already replied on a thread, the agent defers. Multi-tenant trust is a code path, not a config toggle.
An autonomous agent that a dispatcher cannot interrogate is a support ticket. So we built the agent that answers to the dispatcher — that shows its math, keeps its receipts, and stops the moment it isn't sure.
TTMS Mailer runs two parallel pipelines against a shared state machine in Supabase. The outward-facing pipeline reads carrier and shipper email from the dispatcher's Outlook, classifies it, extracts loads, scores carriers, negotiates rates, and books loads in TTMS. The internal pipeline listens on category-scoped internal addresses (qq@ · rates@ · loadwork@ · status@ · carriersourcing@ · loadbuilding@) so teammates can hand off work to the agent by email. Both pipelines share the same guardrails, the same margin engine, the same carrier scoring, the same ledger.
Every outbound email the agent sends — every offer to a carrier, every reply to a shipper, every internal auto-reply — goes out from the dispatcher's real Outlook address via Microsoft Graph's /sendMail endpoint. The carrier sees the dispatcher they've been working with for years. The shipper sees the person whose voice is on the phone every Tuesday.
The AI doesn't have a name, doesn't have a signature, doesn't announce itself. That was the requirement. The user's identity is the interface.
Inbound is a delta-sync from Graph API's subscription mechanism, with webhook notifications for real-time updates. Duplicate webhook deliveries are caught in Upstash Redis. Conversation threads — including the Reply-All chains, forwards, and signature noise that make freight email unique — are reconstructed through Graph's conversation ID and parent references.
The main agent cycle is a single Vercel cron: POST /api/cron/agent. It fires once a day at 9 PM UTC and iterates over every enabled user's Outlook inbox in sequence. For each user, the planner (Claude Sonnet 4.6, with tool-use and prompt caching) reads unprocessed emails and decides which specialized handler to invoke. The handler executes. The state machine updates. The cycle costs about a penny.
One cycle. About a penny in LLM cost. Fully idempotent — safe to re-run.
“Quoting on order 134637.” “ORD-134637.” “Load #588.” The regex catches all three shapes. Direct API call. GET /api/orders/{id}. Single source of truth. Nothing else runs first.
Score carriers. Draft rate. Send. Standard cycle. The verification is invisible in the happy path — which is exactly the point. The guard is only expensive when it fires.
Search by PO number, then by address, then by rate. That is how you book a load to the wrong shipper. The dispatcher wakes up to a rate confirmation on the wrong customer's account, and the trust is gone forever. TTMS Mailer refuses that path.
“Couldn't find that order — could you resend with the correct reference?” The miss is logged. The thread is queued for the dispatcher's morning review. The agent does not guess.
“One wrong-book is worth a thousand right-books that never happened.”
The wrong-order guard is joined by two siblings: the margin floor and the pod-aware handoff. Together they form the safety architecture. The LLM never overrides them; they are enforced in code, not in prompts.
When a carrier replies about a load, the agent tries to match the reply to an order in TTMS in strict priority order. Each path is faster and more specific than the next; the agent only falls through if the higher-priority path has no signal to work with. And the guard on top of all three: if a specific order ID was extracted but not found, the fall-through does not happen. The agent stops.
Every carrier the agent considers for a load gets a score between zero and one hundred, computed from the past_carriers table in TTMS and modified by the response-history data the agent has collected itself. Scores drive the offer-email order: the top-scored carriers get the offer first. Scores are visible in the UI with badge colors — 80+ green, 60–79 amber, 40–59 gray, under 40 red — so the dispatcher can see at a glance which lanes have deep coverage and which are thin.
Reliability is scored. Ghosts are penalized. The scoring updates every time a carrier does something.
Most AI pricing tools are one-shot LLM calls. Prompt in, number out, no math. That is the wrong shape for a freight brokerage. Margin teams need to see how the number was formed — because half the job is defending it to the shipper. So we built the Margin Engine: a rate synthesis pipeline that pulls from five sources, applies a Claude Sonnet 4.5 synthesis step, and returns a recommended rate with the math trail attached. Every source, every weight, every override — visible.
14% target margin. $125 hard floor. 10% carrier-side floor. Enforced server-side. The LLM cannot underprice.
TTMS Mailer routes every LLM call through OpenRouter using the OpenAI-compatible SDK. The hot path — classification, extraction, drafting — runs on Gemini 3 Flash: fast, cheap, and good enough for structured extraction from PDFs and DOCX. The planner — the model that decides which tools to invoke next — runs on Claude Sonnet 4.6 with tool-use and prompt caching enabled; the system prompt, tool definitions, and historical learnings are cached so repeated cycles don't re-tokenize static context. Lightweight reasoning runs on Claude Haiku 4.5. Vercel AI Gateway sits behind the whole thing as a fallback.
| Model | Provider | Use case | Notes |
|---|---|---|---|
| Gemini 3 Flash (preview) | OpenRouter | Classify · extract · draft | Hot path |
| Claude Sonnet 4.6 | OpenRouter | Planner (tool-use) | Prompt caching |
| Claude Haiku 4.5 | OpenRouter | Thread resolver · rate fast path | Lightweight |
| Claude Sonnet 4.5 | OpenRouter | Margin Engine synthesis | Reasoning |
| Vercel AI Gateway | Vercel | Fallback | Reliability |
Cost target held: ~$0.01 per agent cycle ·
~$7/mo/user at 24/7 Live mode.
LLM usage tracked per request in the llm_usage table.
Every night at 3 AM UTC, a cron job named distill-patterns reads the previous day's carrier blast history and lane-level negotiation outcomes and distills them into two pattern sets. The first is carrier-level: this carrier accepts on this lane at this rate window; that carrier ghosts. The second is lane-level: this corridor's average closing rate, time-to-close, acceptance rate. Both pattern sets are injected into the next day's LLM prompts.
This isn't fine-tuning. There is no LoRA. No RLHF. No custom-trained model. The loop is observation → distillation → prompt injection, and it runs on commodity models.
The advantage is that the learning is inspectable — you can read the patterns as text, argue with them, correct them. The disadvantage is that it doesn't compound the way a fine-tuned model would. For a freight brokerage that changes lanes and carriers every quarter, that trade is correct. Rigidity is the enemy.
Red Dog Logistics runs its dispatchers in pods — a pod is a team that shares visibility on a set of loads. TTMS Mailer respects the pod boundary at every level. A user only sees loads assigned to their pod. The agent only auto-replies on threads where no pod member has already engaged. If a teammate has drafted, replied, or commented on a thread, the agent defers. This is not a config toggle; it's a hard-coded query gate.
Combined with the wrong-order guard and the margin floor, the pod-aware handoff completes the safety architecture. The agent is autonomous, but it operates inside three concentric fences: it verifies, it prices honestly, and it defers to humans. Nothing about that should be revolutionary. It is what an autonomous agent for a working brokerage should look like.
We didn't build a queue. We didn't build a worker fleet. We didn't build an event bus. We took a hard look at the workload — daily batch cycles, occasional real-time email triggers, everything idempotent — and decided that nine Vercel cron jobs and a Supabase state machine would do the job.
It did. It has been in production for two months. It costs a rounding-error amount of money. It has no ops overhead. Every cron is idempotent; every cron can re-fire safely; every cron writes state to Postgres and reads state from Postgres. Nothing is in memory.
The main agent cycle fires at 9 PM UTC. Delta-sync at midnight. Pattern distill at 3 AM. Token refresh at 6 AM. Ghost detect at 9 AM. Graph subscription renew at noon. VAPI extract at 3 PM. TTMS sync at 6 AM. Quote-board refresh at 4 AM. That is the whole async architecture.
Every one of these was considered. Every one was rejected.
Every autonomous agent in production has parts that are custom, surgical, and embarrassing to talk about at a conference. Here are three of ours. They are the reason the agent works on real customer data. They are also, we think, the most honest thing we can say about the system.
Three tiers of resolution: (i) what the document said, (ii) what the client's history said if 80% of orders agreed, (iii) hardcoded for byte-stable clients. Higher tiers short-circuit lower ones. Every resolved value carries provenance.
TTMS Mailer is not a prototype. It is a working product handling real freight for a real brokerage. The numbers below are architectural and operational — they are the ones we can verify from the codebase and the production database. Business-outcome numbers belong to the client to publish, not to us.
The LLM part of the system is small. The guardrails around it — the wrong-order guard, the margin floor, the pod-aware handoff, the circuit breaker — are most of the work. If we had spent that effort on prompt engineering instead, the agent would be smarter and unshipped.
For IKO Kankakee, every order is byte-identical. Trying to infer stability with a machine learning loop was slower, less reliable, and philosophically worse than typing the constants into a config. Sometimes the honest answer is a hardcode.
Every time we felt tempted to build a queue, we found a way to solve the problem with an idempotent cron. Two months in, we haven't regretted a single one of those decisions. The queue is a hedge against a scale we don't have and may never have.
Every conversation with the client's dispatchers came back to the same question: “what does the agent do when it's not sure?” Everything downstream — the guardrails, the visible math, the escalation queue, the pod-aware handoff — is a different-shaped answer to that single question.
Three more case studies from Creative Mantra — author-first AI editors, voice-driven logistics platforms, and 35-mailbox healthcare ops.
The author-first AI manuscript editor. Every AI edit is a proposal. Every accepted proposal is logged in an exportable provenance ledger.
A cloud-based transportation management platform automating freight operations for Red Dog Logistics with AI-driven communication and document intelligence.
Always-on AI email automation that triages insurance claims and payments across 35 clinic mailboxes for Krest One Dental, in real time.
If you're planning an AI product where the trust story matters — where the agent has to be safe enough to run overnight against real customer data — we would like to hear about it.
TTMS Mailer · built for Red Dog Logistics · in production · 2026