The load tender hit Marcus's McLeod TMS (transportation management system, the software that manages loads, drivers, and dispatch operations) at 6:14 on a Wednesday morning: a 430-mile dry-van run, Austin to Dallas to El Paso, with a 4:00 PM delivery window in El Paso. Marcus manages a 37-truck fleet out of San Antonio, and at 6:14 on Wednesday morning he was already three drivers short on the day. One was sick, one had a home-time commitment he had honored as promised, and one was sitting at a shipper's dock in Laredo finishing a two-hour detention clock. Normally, Marcus would have declined the tender or scrambled a relay. Instead, he logged into the McLeod booking interface, filtered for available capacity on the Austin to El Paso corridor, and saw something his older self would not have believed: an Aurora autonomous vehicle slot, available for the 430-mile segment, priced at a contracted rate, bookable in six clicks. He booked the Aurora slot for the middle leg. A company driver handled the Austin pickup and delivered to the Aurora transfer hub outside Fredericksburg. The Aurora vehicle ran the highway segment. Another company driver met it at the El Paso transfer hub and made the final delivery on time. Marcus moved the freight, kept his promise to the Laredo driver, and did not scramble. What he needed to understand afterward, and what this lesson teaches, is exactly how that mixed-fleet operation works inside the TMS: what the booking interface looks like, what compliance requirements differ between autonomous and human-driver loads, what the transfer hub handoff protocol requires, and what can go wrong in ways the old dispatch playbook does not cover.

The 2026 Autonomous Market: What Is Actually Bookable Today

The commercial long-haul autonomous trucking market was valued at $2.7 billion in 2024 and is growing at approximately 32 percent compound annual growth rate (CAGR) toward a projected $42.6 billion by 2034. Those numbers are useful context, but they are not the number that matters to Marcus at 6:14 on a Wednesday morning. The number that matters is 250,000: Aurora's logged driverless commercial miles as of 2026, operated on real freight lanes under commercial contracts, bookable through the McLeod TMS integration that serves 1,200-plus fleets across the United States.

This is not a pilot program or a research project. Aurora launched its commercial driverless service in April 2024 in Texas, running between Dallas and Houston. By early 2026, the service had expanded to additional Texas corridors and was operating daily commercial runs at scale. The McLeod integration means that a fleet manager using McLeod does not need to call Aurora, negotiate a separate contract, or set up a standalone system to access this capacity. It appears in the TMS booking interface alongside conventional human-driver capacity options. For the fleet manager evaluating a load, the difference between an Aurora slot and a conventional carrier slot is visible in the interface: equipment type shows as autonomous, the route is constrained to the service corridor, and the compliance requirements differ from a human-driver load in ways the dispatcher must understand.

The autonomous vehicle described in Aurora's commercial operation is operating at SAE Level 4 autonomy. SAE International's J3016 standard defines six levels of driving automation. Level 0 is no automation. Level 1 is driver assistance (think adaptive cruise control). Level 2 is partial automation (the human is still responsible for monitoring). Level 3 is conditional automation (the system can drive but a human must be ready to take over). Level 4 is high automation: the system handles all driving tasks within a defined operational design domain (ODD) with no human intervention required. Level 5 is full automation with no domain restriction. Aurora operates at Level 4. The ODD for commercial operations in 2026 is primarily limited to major highway corridors in the southern United States, daytime operation under defined weather conditions, and specific freight types.

The FMCSA (Federal Motor Carrier Safety Administration) is actively updating its hours-of-service (HOS) rules for driverless truck operations. The current HOS framework (49 CFR Part 395) was written for human drivers and has no provisions for a vehicle that has no human driver to log hours. FMCSA's 2026 rulemaking addresses this by creating a separate compliance framework for SAE Level 4 vehicles operating within their certified ODD: no driver hours to log, but different monitoring, reporting, and incident-escalation requirements. This is a live regulatory development; carriers integrating autonomous capacity should track the rulemaking docket and ensure their TMS configuration and persona-driven compliance checks reflect the current rule state, not the human-driver HOS rule applied incorrectly to an autonomous vehicle.

The Mixed Fleet Model: How It Actually Works in the TMS

A mixed fleet, in the 2026 sense that is actually operational, is not a fleet that has replaced its human drivers with autonomous trucks. It is a fleet that uses autonomous vehicles for the highway segments where the ODD conditions are met and human drivers for the first-mile and last-mile segments where they are not. Marcus's Austin-to-El Paso example is the template: Company driver, transfer hub, autonomous vehicle, transfer hub, company driver. The autonomous vehicle handles the long highway segment within its ODD. Human drivers handle the local pickup and final delivery, which require urban navigation, facility access, shipper and receiver interaction, and the kind of judgment the SAE Level 4 system is not designed to replace.

In the McLeod TMS, this workflow appears as a multi-segment load record. The Austin pickup segment is assigned to a human driver from the fleet's driver pool. The highway segment from the first transfer hub (outside Fredericksburg in Marcus's run) to the second transfer hub (outside El Paso) is assigned to the Aurora slot booked through the integration. The final delivery from the El Paso transfer hub to the receiver is assigned to a second human driver. The TMS tracks the handoff events as status updates in the load record, similar to how it tracks trailer drops in a relay operation, but with differences in the data fields because the middle segment has no driver ELD (electronic logging device, the federally mandated on-board recorder that tracks driver hours in real time) entry to log.

The three operational differences that Marcus's dispatchers need to understand when managing mixed loads:

First: the ODD boundary is a hard constraint, not a preference. An Aurora vehicle operating at Level 4 cannot be routed outside its ODD without transitioning to human control or stopping. The TMS booking interface enforces this by only showing Aurora capacity options that fit within the current operational corridor. If Marcus tries to extend the autonomous segment to a destination outside the ODD, the booking option will not appear. This is different from a human driver, where the dispatcher can technically route the driver anywhere within HOS limits. With autonomous capacity, the geography is non-negotiable.

Second: the transfer hub is not a truck stop. The transfer hub is a dedicated facility where the autonomous vehicle and the human drivers hand off the load. It is not the same as a driver relay at a standard truck stop. The hub has specific check-in procedures, trailer-drop protocols, and time windows. A human driver arriving at the transfer hub needs to know the trailer number, the Aurora vehicle's expected arrival time, and the hub's check-in process. These details are in the load record in the TMS, but the dispatcher must confirm the human driver has reviewed them before the run begins. Missing the transfer hub window is not like missing a relay truck stop; it can strand the load if the Aurora vehicle has a fixed departure time for its next segment.

Third: the DVIR (driver vehicle inspection report, required under 49 CFR Part 396.11) requirement applies differently. Human drivers complete pre-trip and post-trip DVIRs. The autonomous vehicle has its own pre-trip inspection protocol conducted by the terminal operator, not the human driver. The dispatcher cannot confirm DVIR status for the autonomous segment the way they would for a human-driver load. The TMS should receive a status confirmation from the Aurora system before the autonomous segment is released, but the carrier's dispatcher should understand this is a different data source than the driver's ELD-linked DVIR entry.

Booking Workflow: Six Steps from Tender to Autonomous Slot

For fleets with the McLeod integration active, the booking workflow is operationally straightforward. It takes six steps, and Marcus completed them in about four minutes at 6:14 on Wednesday morning. Understanding each step prepares dispatchers for what they will see in the interface and for the decision points where human judgment is required.

Step one: identify the load as a potential autonomous-segment candidate. Not every load fits the mixed-fleet model. The load must have a highway segment long enough to justify the transfer hub overhead (Aurora's commercial lanes in Texas are generally 200-plus miles on the autonomous segment), a freight type within the current ODD specifications (dry van, standard palletized, no hazmat, no oversize in the current commercial service), and a delivery window that accommodates the transfer hub handoff time. A load with a four-hour delivery window on a 430-mile run is a candidate. A load with a same-day two-hour pickup window in a city center is not.

Step two: open the McLeod capacity search and filter for autonomous. In McLeod, the carrier uses the standard capacity search function with the autonomous carrier option enabled. The filter returns available Aurora slots on the qualifying corridor for the load's date and time window. The result shows the segment origin (first transfer hub), segment destination (second transfer hub), available time window, contracted rate, and ODD confirmation status.

Step three: confirm ODD match and rate. The dispatcher confirms the autonomous segment matches the load's geography (the transfer hubs must be within practical range of the pickup and delivery points for the human driver segments), the rate is within the load's margin requirements, and the available time window is compatible with the delivery appointment. This is the human judgment step. The TMS shows the data; the dispatcher decides whether the three-segment design works for this specific load.

Step four: book the Aurora slot and build the multi-segment load record. Once the dispatcher confirms the match, the booking commits the Aurora slot in the McLeod record. The TMS generates a multi-segment load record with the human-driver assignments for segments one and three and the Aurora booking reference for segment two. The dispatcher then assigns the two human drivers from the fleet's available pool, subject to the same HOS and equipment checks that apply to any dispatch decision.

Step five: brief both human drivers on the transfer hub protocol. This is the step that distinguishes a well-run mixed-fleet operation from one that creates transfer hub failures. Each human driver needs to know: the hub location and access instructions, the trailer identification for handoff, the expected arrival time of the connecting segment (whether Aurora vehicle or connecting driver), the check-in procedure at the hub, and the contact number for the hub coordinator if there is a delay or an issue. The dispatcher should confirm this brief is complete before clearing both drivers to run, and the TMS load record should note the brief as a completed step.

Step six: monitor the multi-segment load for status events. Once the run is active, the dispatcher monitors three status streams in the TMS: the human driver's ELD/TMS status for segment one, the Aurora vehicle's position and status data fed through the McLeod integration for segment two, and the human driver's ELD/TMS status for segment three. The TMS displays these as a unified load timeline. Exceptions in the Aurora segment, such as a weather-related ODD limitation or a geofence issue, appear as alerts in the McLeod interface and require the dispatcher to initiate the fallback protocol.

Compliance Mechanics: What Changes for Autonomous Loads

A dispatcher comfortable with human-driver compliance checks will notice that several standard checks are absent or modified for the autonomous segment. Understanding what changes and why prevents two common failure modes: applying inapplicable human-driver requirements to an autonomous segment, and failing to apply the autonomous-specific requirements that replace them.

HOS and ELD for the Autonomous Segment

The autonomous segment has no driver HOS to check. Aurora's commercial vehicles operating at Level 4 do not have a human driver logging hours, so the 11-hour driving limit, the 14-hour on-duty window, and the 30-minute break requirement of 49 CFR Part 395 do not apply to the vehicle itself during autonomous operation. What the dispatcher must check instead is: Does the autonomous segment fall within the vehicle's ODD (geography, weather, time of day, freight type)? Is the Aurora system confirming available capacity for the time window? Is the segment duration within the vehicle's planned operational window before it is recalled for maintenance or remote inspection?

The two human-driver segments on either end of the autonomous run do have full HOS requirements. The dispatcher must confirm each human driver has sufficient hours for their segment, including reasonable dock and hub wait times. The addition of a transfer hub visit to the human driver's segment adds time that must be accounted for in the HOS analysis: typically 30 to 45 minutes at the hub for check-in, trailer drop, and confirmation of autonomous segment status. If the HOS clock for either human driver is tight, the multi-segment design may not work for this particular run even if the Aurora slot is available.

DVIR for a Three-Segment Run

For a standard human-driver load, the dispatcher checks one DVIR chain: the driver's pre-trip at origin, any mid-run condition changes, and the post-trip at delivery. For a three-segment mixed load, the DVIR chain is more complex. The first human driver completes a pre-trip at the origin and a post-trip when they drop the trailer at the first transfer hub. The Aurora vehicle's terminal operator runs the autonomous vehicle's pre-departure inspection protocol. The second human driver at the second transfer hub completes a pre-trip before taking the load for final delivery. The dispatcher must track all three inspection events in the load record, and the TMS must be configured to capture the Aurora inspection confirmation as a status event in the multi-segment record.

If the second human driver arrives at the second transfer hub and cannot confirm the trailer's condition because there is no post-trip from the Aurora segment (the vehicle does not file a DVIR in the human-driver format), the dispatcher should have a protocol for this. The cleanest solution is a brief physical inspection by the driver at the hub before accepting the trailer. The hub protocol should include this step, and the driver should know to perform it and log any findings before accepting the load.

CSA and Incident Reporting for Autonomous Incidents

If the Aurora vehicle experiences an incident during the autonomous segment, the carrier's CSA (Compliance, Safety, Accountability, the FMCSA's safety measurement system that scores carriers on inspections, violations, and crashes) implications depend on the contractual relationship between the carrier and Aurora and on how FMCSA's 2026 autonomous vehicle incident-reporting framework assigns accountability. The carrier should understand this before booking autonomous capacity. In most current commercial arrangements, Aurora retains primary operational responsibility for incidents during autonomous segments. But the carrier's dispatcher needs to have an escalation path: who to call at Aurora, what information to provide, and how to document the incident in the carrier's own records so the load record accurately reflects what happened and when.

The carrier's CSA score is not automatically insulated from an autonomous-segment incident. If the carrier's trailer is involved in a reportable incident during the Aurora segment, the reporting and documentation requirements still apply. The dispatcher should have the Aurora incident contact number, the load's autonomous segment booking reference, and the carrier's own incident documentation template accessible for any mixed-fleet run.

What Can Go Wrong in Mixed Fleet Operations

The mixed-fleet model is operationally real and commercially productive. Marcus moved a load he otherwise could not have moved. But the dispatch playbook for mixed operations has failure modes that do not exist in conventional human-driver dispatch, and a dispatcher who is not prepared for them will make them worse by applying the wrong fix.

Weather-related ODD suspension. Aurora's Level 4 system operates within defined weather conditions. If conditions deteriorate during a run, the system may be required to stop at a safe location and wait for a human driver rescue rather than continue autonomous operation. The dispatcher must know this is a possibility on any mixed run in weather-vulnerable corridors and must have a contingency plan: which of the carrier's human drivers is closest, can that driver reach the stopped vehicle within the driver's own remaining HOS, and who handles the cargo integrity confirmation at the vehicle. A weather suspension is not an Aurora failure; it is the system operating correctly within its safety design. The dispatcher's job is to respond with a plan, not to be surprised.

Transfer hub window miss. If the first human driver is delayed by a shipper detention event and arrives at the first transfer hub after the Aurora vehicle's scheduled departure window, the load does not continue on the autonomous segment. The dispatcher must decide in real time: Can the Aurora slot be rescheduled to a later window? Is there a conventional carrier option that can cover the full route? Is it faster to dispatch a second company driver from the hub for the full remaining distance? These decisions require fast, accurate information about both the Aurora slot availability and the company driver pool's current HOS positions. A dispatcher who treats the transfer hub as a truck stop where any timing works will create a load that sits at the hub without a path forward.

Trailer condition dispute at the second hub. If the second human driver at the second transfer hub observes a trailer condition issue (damage, temperature excursion on a reefer, a seal that appears broken), the carrier must have a protocol for: documenting the condition before the driver accepts the trailer, contacting Aurora to initiate the incident documentation process, and deciding whether to accept the trailer conditionally, refuse it, or hold for inspection. Without a pre-established protocol, the driver is making this decision alone at a transfer hub with a delivery window ticking. The dispatcher needs to be reachable and informed.

Documentation gaps in the multi-segment load record. A mixed-fleet load has more status events than a standard human-driver load: human driver departure, first hub arrival, trailer drop confirmation, Aurora vehicle departure confirmation, autonomous segment active status, Aurora vehicle arrival at second hub, trailer transfer confirmation, second human driver acceptance, and final delivery. If any of these events are not captured in the TMS load record, the carrier's audit trail for the load is incomplete. An incomplete audit trail is a liability in a shipper dispute, a cargo claim, or an FMCSA review. The dispatcher must confirm that the TMS is configured to capture all multi-segment events and that the Aurora integration is feeding status data into the record in real time.

Preparing the Dispatch Board for Mixed Operations

Moving from conventional dispatch to mixed-fleet operations requires four preparation steps that Marcus completed before he was ready to book his first Aurora slot. Carriers that skip any of these steps will encounter the failure modes described above without the protocols to handle them.

Step one: TMS configuration and Aurora integration activation. The McLeod integration for Aurora capacity requires activation by a McLeod administrator, mapping of Aurora's carrier profile in the TMS, and confirmation that the multi-segment load record structure is configured correctly. This is a carrier-side TMS setup task, not something Aurora configures remotely. The carrier's TMS administrator should work through the McLeod integration documentation and confirm that Aurora slots appear correctly in the capacity search interface and that status updates from Aurora flow into the load record as expected.

Step two: dispatcher training on the booking workflow and compliance differences. Every dispatcher who will manage mixed loads needs to understand the booking workflow (the six steps), the ODD constraint, the transfer hub protocol, the HOS and DVIR differences, and the incident escalation path. This training is separate from any McLeod platform training; it is operations-specific content about how the carrier has decided to manage mixed loads within the TMS. The dispatcher persona for mixed loads should be updated to reflect the extended compliance framework described in this lesson.

Step three: transfer hub protocol documentation. The carrier should document the transfer hub protocol for each hub in the Aurora service corridor it plans to use, including hub address and access instructions, check-in process and contact numbers, trailer inspection procedure for the accepting human driver, expected wait times, and the fallback path if the handoff cannot be completed. This documentation lives in the TMS load template for mixed-fleet runs and is available to every dispatcher and driver who needs it.

Step four: incident and exception runbook. The carrier should build a runbook for the most likely exception events: weather ODD suspension, hub window miss, trailer condition dispute at the second hub, and Aurora system communication loss. The runbook specifies who the dispatcher calls, what information to provide, what decisions the dispatcher has authority to make, and what must be escalated to the fleet manager. A dispatcher who has read the runbook before the first mixed run will respond to an exception as a trained professional. A dispatcher who has not read it will improvise, and improvisation at a stranded autonomous vehicle is expensive.

Key Takeaways

• Aurora's commercial autonomous service has logged 250,000-plus driverless miles and is bookable today through McLeod TMS, which serves 1,200-plus fleets; the autonomous long-haul market at $2.7 billion in 2024 is growing at 32 percent CAGR toward $42.6 billion by 2034.
• The mixed-fleet model in 2026 is a three-segment operation: human driver for first mile (origin to first transfer hub), SAE Level 4 autonomous vehicle for the highway segment within the ODD, and human driver for last mile (second transfer hub to destination).
• The ODD (operational design domain) is a hard geographic and environmental constraint, not a preference; an Aurora vehicle cannot be routed outside its defined corridor, and the TMS booking interface enforces this by only showing available slots within the qualifying geography.
• HOS and ELD requirements do not apply to the autonomous segment; the 11-hour driving limit, 14-hour on-duty window, and 30-minute break rule apply only to the human drivers on the first-mile and last-mile segments. FMCSA is updating its rules in 2026 to formalize this distinction.
• The transfer hub is a dedicated facility with specific check-in procedures, trailer-drop protocols, and time windows; missing the hub window can strand a load without a clear forward path, and dispatchers must have a contingency plan ready before any mixed run departs.
• The DVIR chain for a three-segment mixed load requires the first human driver's pre-trip and post-trip, the Aurora terminal operator's pre-departure inspection, and the second human driver's pre-trip at the second hub; the dispatcher must configure the TMS to capture all three events in the multi-segment load record.
• Incident escalation for autonomous-segment events requires a specific protocol: Aurora incident contact, the load's booking reference, and the carrier's documentation template; the carrier's CSA exposure from a trailer-involved incident during an autonomous segment must be understood before booking.
• Four preparation steps before the first mixed booking: TMS configuration and integration activation, dispatcher training on the booking workflow and compliance differences, transfer hub protocol documentation for each hub, and an exception runbook covering ODD suspension, hub window misses, and trailer condition disputes.