System of Record or System of Execution in 2026: Drawing the Decision-Authority Boundary in Logistics Automation and Orchestration

The sentence in every orchestration deployment that nobody unpacks

Read enough logistics automation and orchestration case studies and one sentence appears in nearly all of them, in some variant: the orchestration platform runs as the system of execution, while the ERP and WMS remain systems of record.

It is a good sentence. It reassures the steering committee that nothing is being ripped out, it clarifies that the incumbent stack keeps its job, and it sounds architecturally settled. It is also almost never specified further, and the gap between that sentence and a working integration is where a substantial share of orchestration programmes quietly go wrong.

Here is the problem in one question. An order arrives with a delivery date the OMS committed and the ERP recorded. Mid-morning, the orchestration layer re-decides and the realistic delivery date moves by three hours. Which system now holds the delivery date? If the answer is the ERP, the customer-facing systems reading from it are wrong. If the answer is the orchestration layer, then the ERP is wrong, and every downstream process reading the ERP inherits that error. If the answer is both, you have two dates and no rule for which is correct.

Nothing in the sentence about systems of record answers that question. And for a CTO, that question is the architecture.

Gartner’s research points at the same seam. In a 2026 survey on scaling AI in supply chain, 56% of chief supply chain officers cited integrating AI with legacy systems and processes as a major challenge, and 50% reported limited internal expertise to implement and manage it. Those numbers usually get read as a connectivity problem. In practice the connectors are rarely the hard part. Deciding what the connected systems are each allowed to decide is.

What each system actually owns

The clean way to draw the line is by asking what kind of question each system answers. Systems of record answer questions about state: what was ordered, what is in stock, what was promised, what was invoiced, what happened. Systems of execution answer questions about action: who delivers this, in what sequence, on which vehicle, via which carrier, and what to do now that something changed.

State is durable and should have exactly one authoritative home. Action is perishable and needs to be re-decided continuously, which is a fundamentally different data lifecycle. Most boundary failures come from treating a perishable field as though it were durable.

The distinction that matters most in that table is between the promised delivery window and the predicted delivery time. They are different fields with different owners, and collapsing them into one is the single most common design error in these integrations. The promise is a commercial commitment that should not silently change because a route slipped. The prediction is an operational estimate that should change constantly. An operation that stores only one of the two either cannot detect that it is about to break a promise, or quietly rewrites its promises to match whatever it is currently doing.

Also Read: TMS, WMS, and ERP Integration Architecture: A 2026 Guide

Four failure modes at the boundary

Split-brain state. Two systems hold the same field and diverge. The orchestration layer re-sequences and knows the parcel will arrive at 4pm; the ERP still says 1pm; the customer portal reads the ERP. Nobody is lying and everybody is wrong. This surfaces as a customer service problem long before anyone recognizes it as a data ownership problem, which is why it typically survives for months.

Undefined write-back authority. The orchestration layer decides something and needs the decision reflected elsewhere. Which fields may it write? Under what conditions? What happens if the target system rejects the write, or accepts it and a batch job overwrites it forty minutes later? Teams often discover there is no answer because the question was never asked, and the effective policy becomes last-write-wins. Last-write-wins is not a conflict resolution strategy; it is the absence of one.

Non-idempotent re-decisioning. This one is specific to orchestration and catches teams who have only integrated reporting systems before. A decisioning layer re-decides continuously, which means it emits many messages about the same order during a single day. If downstream consumers are not idempotent, a busy afternoon of re-optimization produces duplicate tasks, duplicate customer notifications, and duplicate carrier tenders. The integration passed testing because testing sent each message once.

Silent precedence. Two systems both act on the same order and neither knows about the other. The ERP allocates the order to a carrier on its nightly run. The orchestration layer reallocates it at 9am on live capacity. At 11am an ERP-triggered process references the original allocation. No error is raised anywhere, because from each system’s perspective it behaved correctly. These are the hardest boundary defects to find, because they produce no exception, only cost.

All four have the same root cause: authority was described in prose and never encoded. The remedy is specification per field rather than per system.

Also Read: Why TMS Migrations Fail: 7 Architecture Mistakes That Kill Digital Transformation in 2026

The integration contract a decisioning layer needs

Most enterprise logistics teams have integrated a visibility or reporting tool before, and they reasonably assume an orchestration layer is a bigger version of the same job. It is not, and the difference is worth stating precisely because it changes the work estimate.

A reporting layer needs read access and acceptable latency. It consumes state and displays it. If it is wrong, someone sees a wrong number. A decisioning layer needs read access, write-back authority on a defined field set, idempotency guarantees on every consumer, live state rather than periodic snapshots, and a conflict-resolution rule for every field two systems can touch. If it is wrong, a vehicle goes to the wrong address.

The bottom two rows are where most CTOs find the real scope. Audit for a decisioning layer means decision lineage: the inputs, the rule or model version, the authority level under which it acted, and the downstream systems it triggered. And rollback is not a database operation. Once a driver has been re-routed, undoing the decision means issuing a new one, which means your orchestration layer needs compensating actions as a first-class concept rather than an exception path.

This is also where governance stops being a compliance topic and becomes an engineering requirement. Deloitte, surveying 3,235 leaders, found only 21% of organizations have a mature governance model for agentic AI, and separately that around 11% have agents in production against 38% piloting them. The gap between piloting and production is substantially this: a pilot can leave authority ambiguous because a human reviews everything, and production cannot.

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

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

What to specify before signature

Eight items to settle in writing during evaluation rather than during implementation. None requires the vendor to build anything; all of them require the vendor to answer precisely.

1. For every field two systems can touch, which system is authoritative, and is that encoded or documented?
2. Are the promised delivery window and the predicted delivery time stored as separate fields with separate owners?
3. Which fields will the orchestration layer write back into the ERP, WMS, or OMS, and under what conditions?
4. What happens when a write-back is rejected, and what happens when a batch job later overwrites it?
5. Are all downstream consumers idempotent, and how was that tested under repeated re-decisioning rather than single-message delivery?
6. What does decision lineage capture, and can you retrieve the inputs and authority level for one specific decision from three weeks ago?
7. How is a decision reversed once it has produced physical action, and is the compensating action automatic or manual?
8. At which autonomy level does each decision class operate, and what is the process for changing that level after go-live?

Question two is the highest-yield question on the list, because a platform that cannot separate the promise from the prediction will either hide promise breaches or overwrite promises, and both are discovered late and expensively.

How Locus draws the decision-authority boundary

Locus, the world’s first Decision-Intelligent, Agentic TMS, is deployed explicitly as a system of execution alongside the systems of record an enterprise already runs, which is a boundary decision rather than a deployment convenience. Within DiSCO, the Dispatch, Capacity, Carrier, and Hub agents own the perishable decisions: sequence, allocation, vehicle, carrier, and re-decisioning against more than 250 real-world constraints per computation. The Customer agent owns the promise against its prediction, which is the separation the table above argues for. The Settlement agent writes execution outcomes back into finance systems as durable record. The ERP and WMS keep state ownership throughout.

The governance layer is what makes the boundary auditable rather than merely declared. Six mechanisms bound autonomous action: explainability, traceability, evaluation, autonomy levels, an execution sandbox, and human-in-the-loop override. Traceability is the decision lineage requirement in the integration contract above, autonomy levels are the per-decision-class authority setting, and the execution sandbox is where a change in authority gets validated before it touches production.

Locus has been recognized by Gartner for seven consecutive years, featured in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, named a Leader in TMS by QKS Group (SPARK Matrix), and ranked #1 in Route Planning on G2’s 2026 Best Software Awards. In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.

Two North American deployments show the boundary drawn deliberately, and one of them shows what happens when it is not.

A Fortune 50 parcel and logistics leader running more than a million freight shipments a year across a 120-country network is the clearest available illustration of the failure mode. The company had implemented a replacement freight platform that was meant to handle routing within its own stack. It could not. A system built to hold state was asked to make continuous operational decisions, and the mismatch surfaced only in production. Meanwhile mid-mile, hub, and warehouse operations sat in systems separate from pickup and delivery, so no layer owned the end-to-end chain. Locus was deployed as the all-mile decisioning layer alongside the new freight platform rather than instead of it, with the Orchestrator and Dispatch agents owning pickup, transit, and delivery decisioning, and Capacity and Carrier agents governing a 4,500-strong driver pool spanning captive fleets and third-party carriers under one policy. It integrates into the freight platform and the legacy estate including infosec, customs, timecard, and labor systems, with every autonomous decision logged for explainability, traceability, and human-in-the-loop override. Weekly execution across 51 service-centre locations moved from 75% to 92%, and a single-site analysis surfaced $565,000 in unused capacity that scaled past $14 million annualized across 25 sites.

A leading North American retailer shows the boundary drawn cleanly from the start. Running a multi-hundred-store network supplied through several distribution centres and hubs, with a private fleet moving tens of thousands of deliveries a year across ocean, rail, and road, it had six disconnected systems and no end-to-end tracking. Locus was deployed as governed agents forming the decisioning layer while the retailer’s ERP and WMS explicitly remained systems of record. The Dispatch agents own routing across DC, hub, and last mile against 250-plus constraints; the Hub agent owns DC, yard, and ocean and rail transit orchestration; the Customer agent owns live status and store ETAs; and Settlement agents write freight billing and reconciliation back into the record systems. The result was more than $1 million in savings, on-time store delivery above 99%, exceptions resolved in under two hours, 95%+ route compliance, an 80%+ reduction in manual dispatch, and break-even inside the first year, with six legacy systems retired rather than six systems argued with.

Also Read: The Real-Time Decision Surface: A Framework for US CTOs Evaluating AI Logistics Orchestration

Specify authority, not just integration

The reason logistics automation and orchestration programmes stall after a clean integration is that connectivity and authority are different deliverables, and only the first one appears on the project plan. The connectors get built, the data flows, the dashboards populate, and then the operation discovers that two systems disagree about a delivery date and there is no rule that settles it.

None of this argues for consolidating onto one platform. The layered model is correct: keep durable state where it already lives and put continuous decisions where they can actually be made. But layering only works when the seam is specified. Draw the line field by field, separate the promise from the prediction, make every consumer idempotent, and require decision lineage before you require dashboards.

PwC’s finding that only 37% of operations leaders are comfortable assigning AI agents to execute end-to-end processes is usually read as a trust problem with AI. Read it again as an authority problem. Teams are not uncomfortable because the decisions are poor. They are uncomfortable because nobody has written down what the system is allowed to decide, what happens when it is wrong, and who finds out.

Book a Locus demo to walk the decision-authority boundary against your own ERP, WMS, and OMS estate before it becomes an implementation discovery.