How Much Work Does a Logistics Team Need to Do During AI Onboarding?

Key Takeaways

Onboarding an AI logistics agent should mostly be extraction, not invention. The logistics team turns decisions it already makes into written rules.
Five inputs carry most of the work: approved carriers, order intake, approval limits, contacts and exception rules.
Scope sets the workload. One real workflow needs only the rules that workflow touches, not a company-wide manual.
Write down the frequent and costly exceptions first. Everything else escalates to a person and becomes a rule only if it repeats.
Wilson, by Cartage, is an AI logistics agent that starts with assisted execution under the company's approval limits. The scope of what runs without review expands step by step as the team gains confidence.

How much work does onboarding an AI logistics agent take from the logistics team?

Less than most teams expect, because the work is collecting decisions the team already makes, not designing a new process. The effort depends on how many of those decisions live only in people's heads and how much freight the first workflow covers.

Every freight team runs on a playbook, even if nobody calls it that. Someone knows which carriers get the dry van loads out of the main plant and how high a rate can go before a manager signs off. Onboarding makes those answers explicit so an AI logistics agent can act on them.

The workload usually lands in three places:

Gathering: pulling carrier lists, contacts and approval habits out of spreadsheets, inboxes and SOPs.
Deciding: settling questions where two coordinators would answer differently.
Reviewing: checking the agent's first real actions and correcting rules.

Gathering is light. Deciding is where the real effort sits. For who on the team should carry that effort, see who trains the AI when logistics has no time.

How do you turn the existing playbook into rules?

Pick the workflow first, then translate only the decisions that workflow needs. Starting from the full operation multiplies the work; starting from one real slice of freight keeps it bounded.

Choose a narrow real workflow. One facility, one mode or a few lanes the team books often. Real orders beat a clean sample because they carry the missing fields the rules must handle.
List the decisions in that workflow. Who quotes, which quote wins, who approves, who hears about delivery, and what happens when a carrier goes quiet.
Write each decision as a condition and an action. "If the rate is above target by more than the approved amount, send it to the logistics manager" is a rule. "Use judgment on expensive loads" is not.
Name an owner for each rule. The owner is the person who can change it later without a meeting.
Mark the boundary. For each action, decide whether the agent completes it within the rules or prepares it for a person to approve.

A rule that can't be written this way means the team hasn't agreed yet.

What the logistics team needs to provide

Five inputs cover most of the first workflow. Each one already exists somewhere; the job is to make it complete enough for the loads in scope.

Approved carriers

The carrier pool by mode, lane or facility, with contacts. Note preferences, such as a primary carrier on a lane, and customers that require or exclude a carrier.

Order intake

Where shipment-ready orders come from: an ERP feed, a scheduled file drop, a spreadsheet, email or an API. List the fields that must be present before a load can move, such as pickup window, weight or accessorials.

Approval limits

Which actions need a person, and above what threshold: booking above the target rate, rebooking after a cancellation or paying an invoice that doesn't match the booking. If your team hasn't set these yet, start with booking approval rules before you automate.

Contacts and notifications

Who internally and at each customer should hear about which events, and through which channel.

Exception rules

What happens when a carrier doesn't respond, no approved carrier accepts, a pickup is missed or a proof of delivery doesn't arrive. For each, define the follow-up and who receives the escalation.

Why you shouldn't document every exception up front

Because the exceptions that matter show up in real freight, and the rest can escalate to a person until they repeat. Writing rules for every scenario before the first load moves adds work without adding safety.

A mature freight operation can list dozens of edge cases, most of them rare. Writing rules for all of them makes onboarding the bottleneck, and many of those rules will be wrong because nobody has tested them against a live load.

Use two questions to decide which exceptions to write now:

Does it happen often in this workflow? Carrier silence and missing fields usually do. Write them.
Is it expensive or hard to undo? A missed pickup on a production order, or a rebooking at a much higher rate, needs a rule even if it's rare.

Anything that fails both tests gets one default rule: escalate to the named owner with the shipment history attached. When a new exception appears, the team handles it, then decides whether it becomes a rule. That is how the playbook grows without a long documentation phase.

A workload map for the first workflow

Use this map to see which inputs need real effort and which can be lighter at the start. Fill in the last column for your own team.

Input	Where it usually lives today	Good enough to start	Can be refined later
Approved carriers	Spreadsheet, routing guide, coordinator memory	Carriers for the lanes in scope, with contacts	Carriers for lanes not yet in scope
Order intake	ERP, emailed orders, shared files	One intake source and its required fields	Additional sources and write-back
Approval limits	Manager habit, finance policy	Thresholds for booking, rebooking and invoice mismatches	Finer limits by customer or lane
Contacts and notifications	Inboxes, customer SOPs	Contacts for customers in the first workflow	Preferences for every customer
Exception rules	Experience of senior coordinators	Frequent and costly exceptions, plus a default escalation	Rare cases, added as they occur

If the "good enough to start" column is mostly covered, the first workflow has what it needs. Carriers and contacts are usually gathering work; approval limits and exception rules are deciding work.

How Wilson, by Cartage applies this

Wilson works from the playbook the team provides and keeps people in the approval path until the team decides otherwise. Customers can configure Wilson themselves or work with the Cartage team.

Carriers: Wilson tenders to the company's approved carriers first. Cartage can introduce additional capacity, but the company approves any carrier before Wilson uses it. If no approved carrier accepts, Wilson escalates to the team.
Intake: Wilson works from the order data flow the company already has: an ERP feed, a scheduled file drop, a spreadsheet, email or an API. Write-back to the ERP is optional and depends on scope.
Approvals: Wilson starts with assisted execution. It negotiates against the company's rate targets and acts within the approval limits the company configures; anything outside them waits for a person.
Exceptions: Wilson follows up with carriers, notifies the people the company named and escalates what the rules don't cover. Messages, confirmations and changes are recorded in the shipment history, so the team can adjust a rule after seeing how it played out.

Wilson replaces the TMS for freight execution, so the rules become how that workflow runs. As it proves reliable, the company can widen the scope one lane or one action at a time.

If you want to see how much of your playbook is already usable, bring one real order and your approved carrier list, and we'll walk through what Wilson would need to run it.