Agents in a logistics app: the driver's hands are the constraint

In most verticals, speaking to an app is a preference. Some users like it, some find it awkward in public, and the product team argues about whether it earns its place. In a cab it is a legal question, and the regulation is more specific than most people building for this market realise.

Under 49 CFR 392.82, “No driver shall use a hand-held mobile telephone while driving a CMV”, and the same rule binds the carrier: “No motor carrier shall allow or require its drivers to use a hand-held mobile telephone while driving a CMV.” Driving includes being temporarily stopped in traffic. The only exception is contacting law enforcement or emergency services.

What counts as use is the part that matters for an interface. 49 CFR 390.5 defines it as holding the phone with at least one hand for a voice call, “dialing or answering a mobile telephone by pressing more than a single button”, or reaching for it in a way that takes the driver out of a properly belted seated position.

Read that as a design constraint and it is unusually precise. One button is allowed. Two is not. A voice feature that requires the driver to unlock, open the app, tap a microphone and then speak has already failed the test before the model gets involved.

That constraint reaches further into the build than it looks, because it rules out several of the shapes described in the honest cost of adding an agent. A push-to-talk button is not available to you here, and everything downstream of that decision changes.

Someone already shipped the reference architecture#

The useful thing about this vertical is that the in-app framing is not a theory here. Truckstop launched AVA on 9 July 2026, and FreightWaves reports that it operates directly inside the existing Truckstop Go mobile app rather than as a separate product or a phone line. Drivers use it to search load boards, check whether a rate is competitive, start a negotiation with a broker, and find fuel and parking, by voice while driving.

Jacky Zhao, Truckstop’s head of innovation, framed the problem the way an operator would: “The last thing carriers need while they’re driving is the stress of not knowing their next load or a notification that takes their eyes off the road.” It ships at no extra cost on several account tiers, with no separate setup.

Every other vertical we write about has to argue that the agent belongs inside the app the user already opened. Here, the company with the load board simply did it.

The four tasks#

Load search is the one the regulation forces and the one with the most interesting query. A driver saying “anything going north out of Laredo that pays over two fifty” is describing a filtered search with a rate threshold, which your board already supports and your UI makes them assemble by hand across four controls.

Arrival and departure logging is trivial technically and valuable operationally, because the alternative is a timestamp entered later from memory. Two taps with gloves on is a worse interface than one sentence.

Exception reporting is where the value hides. Every field operation has a free-text box for “what went wrong” and every field operation finds it empty, because typing a paragraph at a dock is nobody’s priority. Spoken exceptions get reported because speaking one costs eight seconds. The data quality improvement here is larger than anything the search feature produces, and it is the hardest to put in a business case.

Proof of delivery is the fourth, and it is the one that needs the most care.

Proof of delivery, spoken#

A single sentence carries most of a delivery record: status, count, damage, who received it. Timestamp, location and driver identity come from the device, which is both more accurate than a transcript and harder to dispute.

Two things decide whether this works in practice.

The first is the confirm step. A delivery record is a commercial document, and a transcription error in a count becomes a claim three weeks later. The agent proposes the filled record, the driver sees the numbers, and the write happens on a tap. This is the same interception described in intercepting a write before it runs, and the logistics case is the clearest argument for it, because the cost of a wrong write is measured in money rather than embarrassment.

The second is correction. “Twelve, not fourteen” has to change one field and leave the other five alone. A design that restarts the turn on any correction will be abandoned in a week, because the first correction happens on day one. That means the agent needs the previous turn’s proposed record in context, which is a state problem, not something a better model fixes.

The photo is the honest gap. Signature capture and damage photos need a camera and a hand, and no amount of speech removes that. The agent’s job is to get everything else out of the way so the only manual step left is the one that genuinely requires eyes.

Interruption is not a nicety here#

An agent reading a load description aloud while the driver needs to say something is worse than useless, because a driver who cannot interrupt will reach for the phone. Barge-in has to cancel the speech, stop the audio and claim the microphone within the same moment the driver starts talking, and every state in the interface has to be interruptible.

Our SDK runs five states for this: idle, listening, transcribing, thinking and speaking. The transition that matters is any of them back to listening, immediately, on the first frame of the driver’s voice. What an interruption costs mid-answer covers the engineering, which is mostly about cancelling work that is already in flight rather than about detecting speech.

The other reason interruption matters is that cab audio is hostile. Road noise, an open window, a radio, and a recognition model that was tuned on conference-room speech. This is the same evaluation problem the language cluster deals with in a different guise, and the answer is the same: test on recordings from the environment you actually ship into, not on a clean corpus.

The answer belongs on the screen, not in the ear#

A spoken question does not require a spoken answer, and in a vehicle the distinction is the whole design. Reading out six available loads with rates and pickup windows is a memory test. Saying “six, best pays two seventy” and drawing the list means the driver hears the decision and looks at the detail when it is safe to look at anything.

That is the argument for an agent that returns native UI, and it is more obviously right in a cab than anywhere else.

The offline problem#

Freight routes run through places with no coverage, and an agent is a network-dependent feature by construction. The recognition is remote, the model is remote, and the tool call is remote.

Three states, and the design decision is in the middle one. With a good signal the turn runs normally. With no signal at all the agent refuses and says so, which is unhelpful and honest. The dangerous case is an intermittent connection, where a capture can be held locally and queued.

A queued write is only safe under two conditions. The driver can see the queue, with a count and a plain label saying nothing has been sent. And the server can reject a stale one, because a delivery confirmation that arrives four hours late may be contradicted by something that happened in between.

The latency conversation changes shape here too. A driver on a weak connection is not comparing your agent to a fast one, they are comparing it to a form that at least told them it had failed. The latency budget and who owns each segment of it covers normal conditions, and the cab is the environment where the tail of that distribution is what people remember.

Where to start#

Pick exception reporting first. It has no confirm-step design work, no camera dependency, no regulatory exposure, and it produces data your operations team currently does not have. If drivers use it, the case for the other three makes itself. If they do not, you have learned that cheaply.

For the mechanics of interruption, endpointing and what the SDK reports per turn, see the speech configuration reference. For the category question underneath all of this, what an in-app agent is is the place to start.

Sources#

• Legal Information Institute, Cornell Law School, “49 CFR 392.82, Using a hand-held mobile telephone” and “49 CFR 390.5, Definitions”. Accessed 12 September 2026.
• FreightWaves, “Truckstop.com launches industry’s first voice-native carrier assistant”, 9 July 2026.