What IT should verify before an AI agent handles freight

Key Takeaways

A signed approval says what should happen. Before Wilson, by Cartage, handles live freight, IT should run tests on the configured setup and keep the evidence.
Six things are worth verifying on the live setup: sign-in identity, the sending mailbox, permissions in practice, failure alerts, data leaving and returning, and shipment history.
Permissions are proven by attempting actions that should be refused, not by reading a role list back to the vendor.
A failed test usually narrows the starting scope instead of stopping the project: the affected action or lane waits until the evidence exists.

What does IT need to see working before the agent touches a real load?

IT needs evidence from the live configuration, not another document: proof that the agent signs in as the identity IT created, sends from the mailbox IT approved, cannot do what it was not granted, raises an alert when something breaks, moves only the agreed data, and records what it did.

The IT review before deploying an AI logistics agent maps systems, data and actions, and the IT security checklist for an AI logistics agent covers what to approve. Both answer the question "what should happen?" Verification answers a different one: "does the setup we built actually behave that way?"

Go-live problems tend to live in that gap. A shared mailbox is delegated more widely than intended, a service account gets the parent folder instead of one export folder, or alerts point at a channel nobody on logistics has joined. Everyone agreed on the right design; the setup still drifted.

An AI logistics agent executes work, so a configuration mistake surfaces as a carrier email, a booking or a customer update. That is why verification runs on the production configuration with a controlled test order, not on a vendor sandbox.

A six-test verification run, in order

Run the tests in this order, because each one depends on the one before it. If the identity is wrong, every later result is evidence about the wrong account.

Sign-in identity. Confirm which account the agent uses in each connected system, using IT's own sign-in records rather than the vendor's settings page. Pass: every connection traces to an account IT created and can disable.
Sending mailbox. Send a test message from the agent to an internal address and inspect the headers. Pass: the message comes from the approved address on the company's domain, passes the company's normal email authentication checks, and replies land in a mailbox the logistics team can see.
Permissions in practice. Attempt three things that should fail: read a folder outside scope, change a field outside write-back, post to a channel the agent was not added to. Pass: the system itself refuses each one.
Failure alerts. Drop an order file with a missing ship date, delay a file past its expected time, and leave a test request unanswered. Pass: each failure produces an alert to the named owner, with enough context to act.
Data leaving and returning. Compare the fields that actually left the company's systems with the field list that was approved, then check what came back. Pass: no extra fields go out, and anything written back lands only where it was agreed.
Shipment history. Someone who did not run the tests reconstructs the test order from the record alone. Pass: they can tell what went out, what was confirmed and what changed, in order.

What the tests look like on the live setup

Use one controlled test order in the real order flow, plus test contacts the logistics team controls.

Create the test order in the source the agent will actually read, mark it in a reference field so nobody ships it, and route its outbound messages to internal addresses. Logistics decides in advance how far it may go, for example quote request and booking preparation but no tender to a live carrier.

A few details catch teams out:

Shared credentials. If a connection uses a shared login instead of a dedicated account, fix it before go-live; otherwise the history cannot show who acted.
Write-back scope. The agent may be scoped to one status column while the file share or table permission allows editing every column. The fix is usually on the company's side.
The alert path. Remove the alert owner from the channel and see whether the alert still reaches someone. An alert that fires into an empty room is no alert.
Outbound content. Capture the quote request text, attachments and any API payload. Customer pricing, margin notes and unrelated order lines should not appear in a carrier request.

When a test fails, what should IT do?

Classify the failure first, because the response depends on what kind of failure it is. Most failures fall into one of four groups, and only some of them should block go-live.

Configuration error. The design was right and the setup was wrong, such as a typo in a folder path. Fix it and rerun that test and every later one.
Over-granted access. The agent can do more than approved. This blocks go-live for the affected system until the permission is reduced and the refusal test passes.
Ownership gap. An alert fires but nobody named receives it, or two teams each assume the other owns it. This blocks go-live for the affected workflow. No action should run without a person who sees its failures.
Scope gap. Something works, but not well enough yet, such as write-back into a table with inconsistent column names. Remove that action from the starting scope instead of delaying everything. Order intake and execution can start while write-back waits.

Rerun the affected tests after a credential rotation, a moved export folder, an ERP upgrade or a new lane with different contacts. Each changes the conditions the tests proved.

The go-live evidence sheet

Fill one row per test, attach the evidence, and sign it before the first real order flows. The example entries are illustrative; your systems, owners and blocking rules will differ.

Test	How it is run on the live setup	Evidence kept	Signed by	Blocks go-live when
Sign-in identity	Pull access records for each connected system during the test order	Account names and access log extract	IT	Any connection uses an account IT cannot disable
Sending mailbox	Agent emails an internal address; headers inspected	Raw headers, reply routing screenshot	IT and logistics	Mail fails authentication or replies go unseen
Permissions in practice	Three out-of-scope attempts: folder, field, channel	Error messages for each refusal	IT	Any attempt succeeds
Failure alerts	Missing field, late file, unanswered request	Alert received, recipient, time	Logistics owner	An alert reaches nobody
Data out and back	Capture outbound request and write-back result	Field comparison against approved list	IT and logistics	Extra fields leave or writes land outside scope
Shipment history	Second person rebuilds the test order from the record	Their written timeline	Logistics	The record cannot explain what happened

How Wilson, by Cartage, supports a verification run

Wilson is set up like a new team member, which gives IT concrete things to test: its own accounts, its own mailbox, a defined order source and a recorded history. Wilson replaces the TMS for freight execution and connects to the company's ERP or existing order data flow, so the tests above run against the same path real orders will take.

Wilson gets its own email address on the company's domain. Orders can reach it through an ERP feed, a scheduled file drop, a spreadsheet, email or an API, and write-back is optional and scoped: an updated file, a shared table, or an API connection where available. Exactly how Wilson signs in to each system depends on the customer's environment and scope, which is why the identity test belongs on the live setup.

Wilson tenders only to carriers the company has approved; if none accepts, Wilson escalates. Wilson starts with assisted execution, with approval boundaries the company configures, and the scope of execution can expand step by step as the team gains confidence. Messages, confirmations and changes are recorded in the shipment history, which is what the sixth test reads. Cartage helps map the first workflow during discovery.

Bring the test order, mailbox and service account your IT team set up, and watch Wilson run that order in a demo while IT checks each of the six results.