The Hardest Part of Agentic TMS is Not the AI. It is Deciding What the AI is Allowed to Do.

One order, three policies, no rule

An order needs to move on Thursday. Three things are true about it at once.

Your contract with Carrier A commits 60% of this lane’s volume to them, and the rate you negotiated resets if you miss it. You are behind on that commitment with two weeks left in the quarter. Your SLA with the customer promises Thursday, with a penalty clause attached. And your cost policy says nobody buys premium service above a threshold without sign-off.

Carrier A can take it, but not until Friday. The carrier who can hit Thursday costs more than the threshold allows. Every one of those three policies is real, current, and approved. On this order, you cannot honour all three.

A senior dispatcher resolves this in about four seconds. They will probably pay the premium, protect the SLA, note the volume gap, and mention none of it to anyone. They have made a policy decision, correctly, using judgment they could not fully articulate if asked. They will make thirty more like it before the end of the day.

Now automate it. The agent needs to know which of the three policies yields. Not in general terms, but as a rule: at what cost differential does the SLA outrank the approval threshold, and does a quarter-end volume gap change the answer. Nobody in the building has ever written that down, because until now nobody had to.

This is the part of agentic TMS adoption that stalls implementations, and it has almost nothing to do with the AI.

The easy half and the hard half

There is a mature answer to the question of how an autonomous system is supervised. Autonomy configured per decision class rather than as a single switch, targeted escalation with context attached, explainability on every decision, an immutable trace, continuous evaluation, and a sandbox to validate changes before they reach production. Those mechanisms are well specified and they work.

They are also the easy half, because they are mechanisms for enforcing a policy. They assume the policy exists.

Also Read: Why Governance Matters More Than Autonomy in Enterprise Logistics AI

The hard half is upstream and it is nobody’s job. Before you can set an autonomy level for carrier allocation, you have to be able to say what a correct carrier allocation is, in a form precise enough to configure and general enough to cover the cases the agent will actually meet. That turns out to be a discovery project, not a configuration task, and it is the reason these programmes go quiet in month three.

Gartner’s April 2026 survey of chief supply chain officers found 56% naming integration with legacy systems and processes as a major roadblock to scaling AI, and 50% citing limited internal expertise. Both numbers get read as engineering problems. In practice the connectors are rarely what fails. What fails is that the connected systems have no agreed answer to what the agent is permitted to decide.

Why the policy was never written down

The reason is not negligence. It is that under human operation, unstated policy costs nothing to leave unstated.

A dispatcher absorbs the contradiction between two policies at no visible cost. There is no error, no exception report, no queue. The conflict is resolved and the resolution evaporates. Multiply that across a few thousand decisions a week for a decade and you have an operation running on a large body of consistent, effective, entirely undocumented policy, held by people who experience it as common sense rather than as rules.

That is stable right up to the moment you try to delegate it. Then the accumulated ambiguity arrives all at once, as configuration questions that cannot be deferred. The programme did not create the ambiguity. It just stopped it being free.

This is why the objection from operations managers deserves better than being handled as change resistance. Someone who spent nine years building exception protocols is being asked to hand them to a system, and they know something the project plan does not: the protocols were never fully specified, and specifying them badly is worse than not automating at all.

Also Read: What is an Agentic TMS? A Practical Guide for Enterprise Logistics Leaders in 2026

Where enterprise policy actually lives

Before writing precedence rules, it helps to see how scattered the raw material is. Policy in a logistics operation lives in at least five places, in five different forms, owned by five different functions.

The pattern in that last column is the finding. For most rows, the honest answer to who can state the policy is that no single person can state all of it, and the person closest to it can only demonstrate it by doing the job.

An implementation that treats policy definition as a workshop will not surface this. It surfaces when the agent meets its first real conflict and someone has to decide, on the record, what the rule is.

The conflicts you will find

The contradictions are not random. Five classes recur across almost every enterprise operation, and it is worth expecting them by name.

Two things are worth noticing about that table.

The fourth column is where the cost hides. In every row, the current resolution is invisible, which means it is also unmeasured. No operation knows what its named-account priority costs in network efficiency, because the trade is made by a person who does not log it. The configuration exercise is the first time anyone has to price these.

The fifth column is the actual work product. It is not a setting. It is a decision about what the business values more, and it usually cannot be made by anyone in the implementation meeting.

Also Read: Which Dispatch Decisions Should Your AI Make? A Decision-by-Decision Autonomy Map for 2026

Precedence is the artefact you are building

The output of getting this right is a precedence ladder with three tiers, and the discipline is in keeping them separate.

Hard constraints are never traded. A violation is a compliance, safety, or legal event, not an expensive outcome. The correct agent behaviour when a hard constraint cannot be satisfied is to fail loudly and escalate, never to find the next best option. Cargo restrictions, licensing, driver hours, and cold-chain limits belong here. The most common design error is filing something here that the business actually does trade, at which point the operation learns to route around the system.

Ranked objectives are traded against each other by a stated order or stated weights. Cost, speed, carrier commitment, emissions, and account priority belong here. The requirement is not that the weights are perfect. It is that they are visible and owned, so that when the agent makes a trade you can see which rule produced it.

Tiebreaks resolve cases where ranked objectives fall within a stated tolerance. These should be cheap and deterministic, because their only job is to stop the system dithering or behaving unpredictably on near-identical options.

The reason to insist on this structure is a claim worth stating plainly: instructing a system to optimise everything is not a policy. If two of your objectives can conflict and you have not ranked them, the ranking still happens. It is made by a default buried in the software, which means a vendor has decided your commercial trade-offs on your behalf and nobody has reviewed it. That is a worse governance position than a human dispatcher with unwritten judgment, because at least the dispatcher can be asked.

Who decides, and why it is usually nobody

Here is the part most implementation plans miss. Resolving a precedence conflict requires authority to trade margin against service, and almost nobody on the project has it.

IT owns the configuration but has no mandate to decide that an SLA penalty outranks a cost threshold. The vendor can advise and should refuse to decide. The senior dispatcher has the knowledge but not the authority, and is often not in the room. Procurement owns the carrier commitment but not the customer promise; account management owns the promise but not the cost line.

The conflicts are commercial, so adjudication has to sit with someone owning a P&L wide enough to contain both sides of the trade. Naming that person is a prerequisite, not an implementation detail.

It also cannot be a one-off. New conflicts arrive continuously as contracts renew, accounts change tier, lanes open, and regulations shift. So the requirement is a named owner plus a standing forum with a short cycle time. The characteristic failure is a conflict register that fills up faster than anyone empties it, at which point the agent sits at a low autonomy level indefinitely and the programme is quietly judged a disappointment. PwC found 89% of operations leaders reporting that digital initiatives underdelivered against expectations. A share of that is this, unrecognised.

McKinsey’s research on enterprise AI points the same way: deployments stall on the organisation’s ability to govern what it has deployed rather than on model capability. Policy adjudication is the least glamorous part of that and the part most likely to be unassigned.

Five things to measure from week one

Instrument the policy layer itself, not just the agent’s output.

Open policy conflicts, and the age of the oldest. A register with a growing tail is the leading indicator that autonomy will never expand.

Policy silence rate. The share of decisions where the agent applied a default because no rule covered the case. This is the single most useful number here, because it measures how much of your operation is still running on undeclared policy.

Escalation rate split by cause. Separate genuine novelty and low confidence from unresolved precedence. Only the first two are the system working as designed. The third is a backlog wearing an escalation costume.

Time from conflict raised to precedence decided. This is a governance metric, not a technical one, and it usually reveals whether the adjudication forum exists in practice.

Policy change lead time. How long it takes an operations lead to change a threshold, and whether it requires engineering. If a parameter change needs a ticket and a release, the policy layer is not really owned by the business, whatever the architecture diagram says.

Also Read: Agentic-Washing: How to Tell a Real Agentic TMS From a Rebranded Rules Engine in 2026

How Locus makes policy explicit before the agent acts

Locus, the world’s first Decision-Intelligent, Agentic TMS, is built on the position that autonomy is only grantable where the boundary is stated. Its agents, including Dispatch, Capacity, Carrier, and Settlement agents coordinated by an Orchestrator, operate through a continuous Sense-Decide-Execute-Learn loop against a constraint model rather than a fixed rule set, with more than 250 configurable constraints covering cost, service, compliance, capacity, and carrier commitments.

The design choice that matters for this problem is that the constraint model separates hard constraints from ranked objectives, so a compliance limit and a cost preference are structurally different objects rather than two rules of equal standing competing in the same list. Autonomy is configured per decision class, and six governance mechanisms apply to every autonomous decision: explainability, traceability, evaluation, autonomy levels, an execution sandbox, and human-in-the-loop escalation. Explainability is what makes the precedence ladder auditable in practice, because a decision arrives with the constraints it honoured and the alternative it chose against, which is how an operations lead discovers that a rule they thought was hard is being traded.

Locus has been named in Gartner reports for seven consecutive years and appears in the 2026 Gartner Hype Cycle for Supply Chain Execution and Logistics Technologies, with further analyst recognition including QKS Group naming it a Leader in its SPARK Matrix for TMS.

Two deployments show what resolving this looks like at scale.

A Fortune 50 parcel and logistics provider moved to centralised dispatch across 51 sites in a 120-country network, running more than a million freight shipments a year against a 4,500-strong driver pool. Centralising dispatch across 51 sites is precisely the local-against-central conflict in the table above, at maximum difficulty: each site arrived with its own established practice, and the programme had to determine which of those were legitimate local policy and which were drift. Making allocation policy explicit and consistent surfaced more than $14 million in unused capacity that local practice had been hiding, including $565,000 at a single site, and execution rate rose from 75% to 92%. The capacity was not created by the software. It was already there, invisible because no single view of allocation policy existed.

A paint industry leader in India automated freight reconciliation across 160 depots and more than 1,500 invoices a month. Reconciliation is where unstated policy eventually presents its bill: it is the point at which what the contract said meets what was actually charged. Automating the check against contracted terms caught 5% to 6% variance that manual review had been missing, and cut reconciliation from 30 to 45 days down to 7 to 10, a roughly 78% reduction. The variance figure is the useful number for this argument. It is a direct measure of the gap between policy as written and policy as executed, in an operation where nobody was doing anything wrong.

Request a Locus agentic TMS policy readiness assessment to map your constraint set and identify precedence conflicts before configuration begins.

The question to ask before the demo

The useful question for a vendor is not whether their platform supports policy governance. Every platform will say yes, and most will show a configuration screen.

The useful question is what the system does when two of your policies conflict and neither is marked as a hard constraint. If a default resolves it, ask to see the default and who set it. If it escalates, ask what happens when it escalates four hundred times in the first week, which it will.

The internal question comes first and is simpler: who here can decide that a named account outranks network efficiency, and by how much. If that person is not identified, the implementation has not started, whatever the project plan says.

The hardest part of agentic TMS really is deciding what the AI is allowed to do. Not because the decision is technically difficult, but because it forces an organisation to state, on the record and in a specific order, what it values more. Operations have been running on the comfortable ambiguity of never having to answer that. The agent is what removes the comfort.