A capable AI agent knows freight. It does not know your freight. It does not know that this consignee refuses deliveries after 2pm regardless of what the appointment says, that this customer wants a phone call rather than an email when a load is going to be late, or that this lane always needs a tarp even though the order rarely says so.

That knowledge is the difference between an agent that is technically correct and one that is actually useful. It lives in your team's heads, in scattered notes, and in the pattern of past decisions — almost never in a document.

Onboarding an agent is the process of extracting it. Two weeks is a realistic timeline, and the work is more about your operation than about the technology.

Why "we don't have SOPs" is not a blocker

Most logistics teams say some version of this, and it is usually half true. Formal written procedures are rare. Consistent actual behaviour is common.

The distinction matters, because you do not need to write a procedure manual before deploying an agent. You need to surface the decisions your team already makes consistently — and the fastest route to that is not a documentation project. It is looking at what they actually did.

Your inbox is the SOP. Several thousand past threads contain the real answers: how quote requests get handled, what gets escalated, which customers get different treatment, what the standard replies actually say. That corpus is more accurate than anything anyone would write down, because written procedures describe intent while historical threads describe behaviour.

The two-week curriculum

• 1-2 — Focus: Scope the workflow, pull historical examples · Output: A defined workflow and a real corpus
• 3-4 — Focus: Extract the decision rules from actual behaviour · Output: A written rule set, including exceptions
• 5-7 — Focus: Configure and run in draft mode · Output: Agent drafts, humans approve everything
• 8-10 — Focus: Review the edit log, tighten rules · Output: Rules corrected against real disagreements
• 11-12 — Focus: Account-specific and exception handling · Output: Named exceptions encoded
• 13-14 — Focus: Limited autonomy inside a written boundary · Output: Live on the categories that hit the bar

Days 1-2 — scope and corpus. Pick one workflow. Not "customer communication" — something with a completion state, like inbound status requests or quote acknowledgements. Then pull the last 60 to 90 days of real examples, including the messy ones. A corpus of curated clean examples is how you build an agent that fails on contact with reality.

Days 3-4 — extract the rules. Read the corpus and write down what actually happened, not what should have. This is where teams discover their process is less consistent than they believed, which is uncomfortable and extremely valuable. Two reps handling the same situation differently is a decision your organization has never actually made, and now has to.

Days 5-7 — draft mode. The agent writes, a human approves or edits every message. Zero customer risk, and the edit log is the highest-value artifact in the entire process: every edit is a rule you got wrong, stated precisely.

Days 8-10 — tighten. Work the edit log. Most edits cluster into a handful of systematic issues — tone, a missing data source, an exception nobody mentioned. Fix those and the approval rate moves sharply.

Days 11-12 — the named exceptions. This is the part that gets skipped and shouldn't. Every operation has twenty or thirty account-specific rules that exist only as tribal knowledge. Get them written down. The prompt that surfaces them reliably: "which customers do we handle differently, and how?"

Days 13-14 — limited autonomy. Enable auto-send only for the categories meeting your accuracy bar. Everything else continues to escalate with context. This is the authority boundary being drawn deliberately rather than by default.

How long does it take to train an AI agent on a logistics workflow?

Two weeks is realistic for a single well-scoped workflow: two days to gather real examples, two to extract the decision rules, three in draft mode with humans approving everything, three to tighten against the edit log, and the remainder encoding account exceptions before enabling limited autonomy. Workflows fail this timeline when the scope was a category rather than a task.

The constraint is almost never model capability. It is how quickly your team can articulate what they actually do — which is why the draft-mode edit log matters so much. It converts an impossible interview question into a concrete artifact.

The edit log is the whole game

If there is one thing to take from this: treat the draft-mode edit log as your primary instrument.

Every edit is a labelled error. A human saw the agent's output, decided it was wrong, and demonstrated the correct version. That is a higher-quality signal than any amount of upfront specification, and it comes from work the team was doing anyway.

Reviewing it well means categorizing rather than fixing one by one:

• Tone and format edits — usually a single systematic correction, not many.
• Missing information — the agent lacked a data source, which is a configuration gap.
• Wrong decision — a genuine rule error, the most valuable category.
• Exception applied incorrectly — an account-specific rule that was never stated.

When edits stop clustering and become idiosyncratic, the rules are close to right. That is also the honest readiness signal for autonomy — better than an accuracy percentage, because it tells you whether the remaining errors are systematic or random.

What to write down permanently

The onboarding produces an artifact worth more than the agent: an explicit statement of how your operation actually handles a workflow.

Most teams have never had this. It makes onboarding human employees faster, it survives turnover, and it is the thing that makes the next workflow take one week instead of two. It also feeds directly into the testing and QA process you will want before expanding scope.

Teams that treat agent onboarding as a configuration task get an agent. Teams that treat it as an operational documentation exercise get an agent and a materially better-understood operation.

Frequently asked questions

Do we need written SOPs before deploying an AI agent? No. Historical message threads are a better source than written procedures, because they record what your team actually does rather than what someone intended. The onboarding process produces the written version as a byproduct.

What if our team handles the same situation inconsistently? That is the most useful finding of the whole exercise. Inconsistency means a decision your organization has never made explicitly. Making it is valuable independent of the automation.

How many historical examples are needed? 60 to 90 days of real threads for the chosen workflow is generally sufficient, and including the messy and exceptional ones matters more than the total count.

Can we onboard multiple workflows at once? Not for the first one. The first workflow is also teaching your team how the process works, and running two in parallel makes the edit log harder to read. The second workflow goes substantially faster, and the 30-day playbook for scoping the first applies directly.

The bottom line

Model capability is not the constraint. Your operation's undocumented decision rules are — and the fastest way to surface them is to let an agent draft against real threads and watch what humans change.

Scope one workflow, pull 90 days of real examples, run draft mode for a week, work the edit log by category, encode the named account exceptions, then enable autonomy only where the accuracy bar is met.

Debales deploys AI agents for freight quoting, order processing, ETA updates, and multi-channel customer communication — starting in draft mode against your real threads, with an edit log that turns your team's corrections into rules. Book a demo.