March 11, 2026•by Quang

What Happens When a Carrier Calls

Voice orchestration is commoditized. Vapi, Bland, LiveKit. Every AI company in freight uses one of these, the same way every SaaS company runs on AWS. Building a demo that can talk about a load takes an afternoon. The hard part is everything after that.

Enterprise brokers care about three things: the agent does the job across thousands of conversations a day, rates and booking confirmations are right because mistakes cost real money, and it works across voice, email, and text without losing context between channels. That's it. They don't care what voice or email or text platform you use. Every decision we make comes back to those three things.

Call Process

So what does a single call actually look like?

A carrier calls in. The first thing that happens is a compliance check. The agent has to figure out who it's talking to. Dispatchers, owner-operators, and brokers all identify themselves differently. Some don't identify themselves at all. We have an agent whose only job is this part of the conversation. Verify who they are and whether they're compliant. Get this wrong and you're booking freight with someone who shouldn't be hauling it.

Then comes load data. TMS data is a mess. Equipment types are encoded differently across systems. Commodity descriptions and special instructions are in notes written by a human in a hurry. We run 3-4 different agents to parse, interpret, and clean this data, plus a separate pipeline that strips anything that can be used for fraud: internal rates, shipper-specific notes, proprietary lane data etc.

Then negotiation. A hallucination here is expensive. If the agent surfaces a rate $200 too low, that comes straight out of the broker's margin. So we run a dedicated negotiation agent with its own context window, its own eval criteria, its own guardrails.

If the carrier agrees and wants to book on the call, a separate agent takes over. Every action in this flow: rate con generation, load assignment, carrier notification, passes through an online eval before it executes. Was this booking intentional? Does the rate match what was negotiated? Is the carrier still compliant? A rate con doesn't send unless the eval passes.

If the carrier needs a human, we have to figure out who to transfer to, dial the brokerage, get through their phone tree, often couple levels deep with hold music and voicemail, and relay enough context that the operator can pick up without starting over. Dedicated models handle this.

After the carrier hangs up, agents generate structured data for the client's systems, update CRM records, and fire Slack and Teams notifications.

None of this runs on one model. A carrier mid-sentence shouldn't wait two seconds for a response, so conversational turns run on smaller, faster models. A booking confirmation can take an extra 500ms if it means the rate is correct, so those run on larger ones. Some are open source, fine-tuned on freight data. Some come from OpenAI or Anthropic. Everything is customized, at context or model level, for broker use cases.

We train our own transcription and synthesis models. When a carrier says "reefer set to minus 10" and the transcription hears "reefer set to 10" the downstream agent makes decisions based on the wrong requirements. When the synthesis mispronounces "Laraydo," the carrier stops trusting the voice. We retrain these continuously.

You can build a demo that handles a scripted call in an afternoon. it will sound great with a cooperative tester who speaks clearly and follows the happy path. Now try it 240,000 times a day. Carriers calling from truck cabs on speakerphone. Dispatchers who speak English as a second language. Calls at 2 AM when there's nobody to transfer to. Rates that changed between when the agent quoted and when the carrier said "book it."

For voice and this use case alone, the eval loops, the model orchestration, the data pipelines, the failure handling, the continuous retraining. That's about 95% of what we focus on. The transport layer is the other 5%.