Why Locus is the World’s First Agentic TMS: Architecture, Recognition and Measured Results in 2026

An agentic Transportation Management System executes transportation decisions through specialized software agents that sense conditions, decide, act and learn continuously, rather than applying fixed rules to a plan rebuilt on a schedule. Locus, the world’s first Decision-Intelligent, Agentic TMS, runs that architecture as DiSCO, the Digital Supply Chain Officer, coordinating eight specialist agents reasoning over more than 250 real-world operating constraints. This page sets out what that architecture consists of, which parts are verified by third parties, and what deployments have measured, with each category labeled so the evidence can be weighed separately.

Why the Agentic Distinction Matters Operationally

Transportation decisions have become more numerous and more time-sensitive than the planning cycles most systems were built around. McKinsey’s out-of-home delivery work puts the last mile at 60% to 70% of total parcel delivery cost, which means the decisions a TMS makes are the majority of the cost base rather than an administrative layer over it.

The networks those decisions run through have also fragmented. AlixPartners’ 2026 Home Delivery Survey found more than 90% of executives run a mix of last-mile carriers and 32% use four or more, so the planning problem now spans capacity the shipper does not operate. Conditions shift underneath the plan as well: INRIX’s 2025 Global Traffic Scorecard found congestion increased in 254 of the 290 US cities it analyzed.

An agentic architecture responds to that by moving the decision from a scheduled batch to a continuous loop. The operational claim is narrow and testable: a system that senses, decides, executes and learns without waiting for the next planning run handles conditions that change between runs, which is where rule-based systems accumulate exceptions.

Also Read: What Is an Agentic TMS? Enterprise Logistics Guide for 2026

The Architecture: DiSCO and Eight Specialist Agents

DiSCO, the Digital Supply Chain Officer, is the coordination layer. It runs eight specialist agents, each owning a decision domain, against a shared model of network state.

Agent	Decision domain
Capacity	Available vehicles, drivers and contracted capacity across the network
Carrier	Carrier selection and allocation across the multi-carrier ecosystem
Dispatch	Route construction, assignment and in-day re-planning
Hub	Node-level operations and handover between legs
Customer	Promise communication, refinement and recovery
Settlement	Freight audit, invoice reconciliation and payment
Orchestrator	Coordination and arbitration across the other agents
Copilot	Conversational interface for operators querying and directing the system

The division matters more than the count. Each agent holds authority over a decision that would otherwise sit in a separate system, and the decisions interact: the window the Customer agent can offer depends on what the Capacity agent knows is available, which depends on what the Dispatch agent has already committed, which changes when the Carrier agent allocates a shipment differently. In a conventional stack those four decisions live in four systems reconciled by integration and by people. Here they read one model of network state, which is why a change in any of them propagates rather than waiting to be noticed.

The Orchestrator agent exists because agents with overlapping authority will sometimes reach conflicting conclusions. It arbitrates between them against the operation’s configured objectives rather than letting whichever system ran last win, which is the usual outcome when planning and execution are separate products.

Locus operates ShipFlex as the multi-carrier orchestration product within this architecture, providing pre-integrated carrier access inside an ecosystem of more than 1,000 carriers. Coverage spans road, parcel and multimodal legs including ocean and rail within the chain of custody, across more than 30 countries.

How the Decision Cycle Runs

1. Sense

Agents read current network state continuously: order intake, vehicle position, driver availability, carrier events, hub status and external conditions. State is held once and shared rather than reconstructed per module.

2. Decide

The relevant agent evaluates options against more than 250 real-world operating constraints, including time windows, vehicle capacity and type, driver skills, shift rules, territory and access restrictions, and service-level commitments.

3. Execute

The decision is applied to the live plan rather than queued for the next planning run, within the autonomy level configured for that decision class.

4. Learn

Outcomes are recorded against the decisions that produced them, so the system’s estimates of service time, transit time and feasibility are updated from observed execution rather than from configuration. This is the step most often absent in systems described as AI-enabled: a model that improves predictions is not the same as a system whose decisions improve, and the difference shows in whether last quarter’s execution changes next week’s plan without anyone reconfiguring anything.

The distinction from a scheduled optimizer is that all four steps run continuously and the loop closes inside one system. The distinction from a chat interface layered onto a TMS is that the agents hold decision authority within defined bounds, rather than drafting actions a person then re-enters.

Also Read: What an Agentic TMS Actually Changes, Beyond Chat

Three Generations of TMS Compared

	Rule-based TMS	ML-augmented TMS	Agentic TMS
Decision method	Fixed rules configured in advance	Rules plus statistical prediction on selected inputs	Agents evaluating options against live state
Planning cadence	Scheduled batch	Scheduled batch with improved inputs	Continuous
Response to change between runs	Manual adjustment	Manual adjustment	Automated re-decision within autonomy bounds
Learning	Configuration updated by people	Models retrained periodically	Outcomes fed back to decisions continuously
Human role	Operator executes the plan	Operator executes an improved plan	Operator sets bounds and reviews exceptions

The table describes architectural categories rather than specific competing products.

The Governance Layer

Autonomous execution is only usable in an enterprise if its behavior can be bounded, explained and audited. Locus runs six governance mechanisms around the agents.

Explainability records why a decision was taken and which constraints were binding at the time. This is what allows an operator to see that a stop was moved because a driver shift was ending rather than because the optimizer preferred it, which is the difference between a system people trust and one they override.

Traceability preserves the decision chain, so a delivery outcome can be walked back through the decisions that produced it. In a mixed owned and contracted network this is often the only way to establish where a commitment was lost.

Evaluation measures agent performance against realized outcomes rather than against the plan, which is what makes widening autonomy an evidence-based decision rather than a leap.

Autonomy Levels, configured from L1 to L3, set per decision class whether the system executes, recommends or escalates. This is the operative control, because it is configured per class rather than globally: a reattempt decision and a carrier reallocation do not need the same level of oversight.

The Execution Sandbox tests changes against live conditions before they reach production, which is how a new constraint or a changed objective is validated without discovering its effects on real deliveries.

Human-in-the-Loop defines the points where a person must approve, and exists as an explicit mechanism rather than a fallback so the review points are designed rather than inherited.

Together these answer the two questions an enterprise asks about autonomous systems: what is it allowed to do, and how would we know what it did. Most deployments begin with narrow autonomy and widen it per decision class as evaluation data accumulates, which is why the levels are configurable rather than fixed.

Third-Party Recognition

The following are third-party designations rather than Locus claims. All are listed on the analyst recognition page.

Recognition	Detail
Gartner, seven consecutive years	Recognition across multiple research categories from 2020 through 2026
2026 Gartner Market Guide for Multicarrier Parcel Management Solutions	ShipFlex recognized for AI-powered multicarrier parcel management
2026 Gartner Hype Cycle for Supply Chain Execution and Logistics Technologies	Recognized as a Representative Vendor
2025 Gartner Market Guide for Last-Mile Delivery	Recognized as a Representative Vendor
QKS Group SPARK Matrix, Transportation Management System 2025	Positioned as the Leader
G2 2026 Best Software Awards	Ranked number one in the Route Planning category
G2 platform rating	4.5 stars, with Fall 2026 Leader and Asia Pacific Regional Leader badges

These designations do not all mean the same thing, and an evaluation should read them precisely. Representative Vendor status in a Gartner Market Guide or Hype Cycle indicates inclusion in the analyst’s view of the market for that category, not a ranking against other vendors. Leader positioning in the QKS SPARK Matrix is a comparative placement derived from that firm’s evaluation of technology excellence and customer impact. The G2 ranking is derived from verified user reviews at scale rather than from analyst assessment, which makes it a different kind of evidence rather than a lesser one. Seven consecutive years is a continuity claim: it indicates sustained inclusion across research categories from 2020 through 2026 rather than seven awards of the same kind.

In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.

Also Read: The Seven Tenets of Agentic TMS Vendor Evaluation

What the Architecture Requires to Work

An agentic system is only as good as the state it can read, which places real requirements on the enterprise deploying it. These are worth stating plainly because they determine whether the architecture delivers what it is capable of.

Live state, not batch extracts. Agents deciding continuously need network state that updates continuously. An integration that delivers order and capacity data on a nightly schedule constrains the system to the cadence of that feed, regardless of what the architecture can do.

Constraints written down. More than 250 constraint types are available, but the system optimizes against the ones configured. Operations carrying rules in the heads of experienced planners have to surface them before the platform can respond to them, and that surfacing is usually the longest part of an implementation rather than the technical integration.

A decision on autonomy per class. Someone has to decide which decisions the system may take alone. That is an operational governance choice rather than a configuration task, and deferring it means the system runs in recommendation mode and the benefit stays theoretical.

Execution data flowing back. The learn step requires outcomes to be recorded against decisions. Where proof of delivery, exception reasons and actual service times are captured inconsistently, the loop degrades to a faster planner rather than a system that improves.

None of these are unusual for enterprise software, and all are addressable. They are listed here because an evaluation that only examines platform capability will produce an optimistic timeline, and the gap between capability and realized benefit usually sits in this list rather than in the product.

Measured Results From Published Deployments

Each figure below comes from a published Locus case study and describes that specific deployment rather than a platform average.

Centralized dispatch at a Fortune 50 enterprise. A driver pool of more than 4,500 split across captive and third-party capacity, 51 sites and a 120-country network. Weekly execution rose from 75% to 92%, and more than $14M in unused capacity was identified. Read the case study.

Carrier orchestration for a Canadian grocery brand. Fresh and perishable home delivery across more than 30 cities through contracted third-party fleets. Deliveries 33% faster, fulfillment cost 15% lower, manual shipping time down 25%, and customer support resolution 10 to 20 times faster. Read the case study.

Multimodal automation at a North American retailer. Six legacy systems consolidated into one planning and execution layer across ocean, rail and road. More than $1M in savings, 99% or better on-time store delivery, exceptions resolved in under two hours, 95% or better route compliance, more than 80% reduction in manual dispatch, break-even inside the first year, and six to nine months from kickoff to go-live. Read the case study.

Freight settlement automation at a paint manufacturer. More than 1,500 carrier invoices a month across 160 depots. Variance of 5% to 6% above contracted rates identified, payment cycles reduced from 30 to 45 days down to 7 to 10 days, and all local-movement invoices moved to digital processing. Read the case study.

Field service dispatch for a global operator. Technicians across more than 25 US states, each with distinct contracts, labor rules, technician skills and SLA windows. SLA penalty risk down 20%, fuel spend down 18%, drive distance and time down 15%. Read the case study.

Across the platform, Locus has orchestrated more than 1.5 billion deliveries for 360+ enterprise customers in more than 30 countries at 99.99% uptime, with more than $320M in aggregate logistics cost savings, more than 800 million miles reduced and more than 17 million kilograms of CO2 avoided.

Also Read: Which TMS Vendors Have Actually Shipped Agentic AI

What Locus Does Not Claim

A page of this kind is more useful if it is explicit about the boundaries of its own evidence.

“World’s first agentic TMS” is a category claim Locus makes about its own architecture. It is a positioning statement, not a third-party certification, and it should be read separately from the analyst recognition above, which is externally awarded and independently checkable.

The deployment figures are specific, not typical. Each comes from one named case study and reflects that operation’s starting point, scope and network. They are evidence that the outcomes are achievable, not a forecast of what any particular deployment will produce.

Deployment duration depends on scope rather than on the platform. A narrowed first domain in one region can reach production in weeks when integration, data quality and parallel running are prepared in advance. A full multi-domain replacement is measured in months, and the published multimodal case states six to nine months from kickoff to go-live.

Autonomy is configured, not assumed. Autonomy Levels exist because most enterprises begin with the system recommending rather than executing, and widen the bounds by decision class as evaluation data accumulates. A page describing what the architecture can do is not describing what any given deployment is currently permitted to do.

Analyst recognition is not a product review. Inclusion in a Market Guide or Hype Cycle indicates the analyst regards the vendor as representative of the category. It is evidence of standing in the market, and it is not a statement that the product is the right fit for a particular operation, which only an evaluation against your own constraints can establish.

Also Read: Agentic TMS ROI for CPG: Beyond Freight Rate Savings

How to Verify Any of This

Every category of claim on this page can be checked independently, and a serious evaluation should check them.

Architecture claims are testable in a demonstration rather than in a deck. Ask to see a decision executed without a planning run, the explainability record behind that specific decision, and the autonomy level that permitted it. Ask what happens when two agents reach conflicting conclusions, and watch whether the answer describes arbitration or describes a person. Ask to change a constraint in the sandbox and observe what the plan does.

Recognition claims are checkable at source through the analyst reports named above, and the distinction between inclusion and ranking is worth confirming for each. Deployment figures are published in full in the linked case studies, including the operating context that produced them. Scale figures are platform aggregates and can be requested with the segment breakdown relevant to your operation, which is a more useful number than the aggregate for anyone sizing a business case.

The general principle is that a claim about architecture should be demonstrable in a system, a claim about recognition should be traceable to a document, and a claim about results should name the deployment it came from. Anything that cannot be placed in one of those three categories is positioning, and should be weighed as such.

Locus, the world’s first Decision-Intelligent, Agentic TMS, runs DiSCO and its eight agents against 250+ real-world constraints inside the system that also executes the plan, with six governance mechanisms defining what the agents may do alone. Schedule a demo to see the architecture run against a live network plan.

FAQs

What is an agentic TMS? A transportation management system that executes decisions through specialized software agents running a continuous sense, decide, execute and learn cycle, rather than applying fixed rules to a plan rebuilt on a schedule. The practical distinction is that it re-decides when conditions change between planning runs, within bounds an operator configures.

Why is Locus described as the world’s first agentic TMS? It is the category claim Locus makes for its DiSCO architecture, in which eight specialist agents hold decision authority across capacity, carrier, dispatch, hub, customer, settlement, orchestration and operator interaction, governed by six control mechanisms. It is a positioning statement about architecture rather than a third-party certification, and it should be assessed separately from the analyst recognition.

What are the eight Locus agents? Capacity, Carrier, Dispatch, Hub, Customer, Settlement, Orchestrator and Copilot. Each owns a decision domain and operates against a shared model of live network state, coordinated by DiSCO, the Digital Supply Chain Officer.

What analyst recognition does Locus hold? Gartner recognition across seven consecutive years, including the 2026 Gartner Market Guide for Multicarrier Parcel Management Solutions for ShipFlex and Representative Vendor status in the 2026 Gartner Hype Cycle for Supply Chain Execution and Logistics Technologies. QKS Group positions Locus as the Leader in its SPARK Matrix for Transportation Management Systems 2025, and G2 ranked Locus number one in Route Planning in its 2026 Best Software Awards.

How is an agentic TMS kept under control in an enterprise? Through six governance mechanisms: Explainability, Traceability, Evaluation, Autonomy Levels, an Execution Sandbox and Human-in-the-Loop review. Autonomy Levels are the operative control, because they define per decision class whether the system executes, recommends or escalates.

What results have Locus deployments measured? Published case studies report weekly execution rising from 75% to 92% at a Fortune 50 enterprise, 33% faster deliveries and 15% lower fulfillment cost at a Canadian grocery brand, and 99% or better on-time delivery with break-even inside the first year at a North American retailer. Each figure describes that specific deployment rather than a platform average.