The 24x7 Agent Narrative Has a Blind Spot
Open any tech publication today and you’ll read a familiar story: hand a coding project to Cursor or Copilot, walk away, and come back to a finished pull request. Hand a back-office task to an agent and it grinds through it overnight. Hand a research brief to an AI co-worker and wake up to a polished deck.
These are real, impressive capabilities. But they share a hidden assumption that quietly breaks the moment you apply them to the physical world: the work can wait.
A pull request can sit in review for an hour. A research brief can be revised at 9am. A marketing draft can be iterated tomorrow. The agent’s clock is generous, and the cost of a slow answer is roughly zero.
Supply chains do not work this way. The clock is unforgiving, the data is in motion, and the cost of a slow answer is measured in spoiled product, stolen cargo, missed vessels, regulatory penalties, and patients without their drugs. When a temperature excursion hits one of 50,000 shipments in transit, “the agent will get to it” is not an answer. The product is degrading right now. The decision window is minutes — sometimes seconds — and the action has to be specific to that shipment, that lane, that SKU, that customer contract, and that regulatory regime.
This is why the dominant agentic AI architecture — a general-purpose LLM, wrapped in tools, fed prompts, polling APIs at human pace — is fundamentally the wrong shape for supply chain decisioning. To do this well, you have to rethink the stack from the ground up.
What Real-Time Supply Chain Decisioning Actually Looks Like
Consider a few representative scenarios. Each one is happening, somewhere in the world, right now:
Cold chain temperature excursion. A pharmaceutical shipment of biologics moving through a Memphis hub crosses a +2°C threshold for the third time in 40 minutes. The decision isn’t just “alert someone.” It’s: Is this a sensor anomaly or a real excursion? What’s the cumulative mean kinetic temperature against this product’s stability budget? Is the lane known for HVAC issues at this hub? Which 3PL is on the hook? Should we re-ice, re-route, condemn, or hold for QA review? Who is the named regulatory contact for this lot? What does the customer’s quality agreement actually require us to do in the next 30 minutes? All of that, resolved and acted on, before the next temperature read comes in.
Unscheduled stop in a theft hotspot. A trailer of consumer electronics stops for 14 minutes on I-10 outside a known cargo theft corridor in Southern California. Legitimate stops happen all day. The system needs to fuse GPS dwell, geofence overlay, driver schedule, fuel-level telemetry, door sensor state, historical theft incident density, and the load value to decide in seconds whether to dispatch local law enforcement, alert the security operations center, trigger covert tracking, or do nothing. Detecting this in 90 minutes via a daily report is worthless — the cargo is already gone.
Port congestion cascade. Long Beach berth productivity drops 30% over six hours due to a labor action. The agent needs to figure out which of your 1,200 in-transit containers will miss their cutoff, which of those carry promotional inventory tied to a retailer’s planogram reset, which can be diverted to Oakland or Tacoma without breaking landed-cost models, and which customers need proactive ETA changes — before the freight forwarder sends their generic delay notice tomorrow morning.
Tier-N supplier disruption. A fire at a sub-tier supplier in Taiwan takes a specialty resin offline. Your direct supplier won’t tell you because they don’t know yet. The signal first appears in local news, port export data, and a 12% spike in spot prices on a B2B exchange. You have hours, not days, to lock alternate supply before competitors do the same.
Customs hold pattern emergence. Three shipments from the same origin get flagged for inspection at three different US ports within four hours. Is this a random cluster or the leading edge of a targeted enforcement action against a tariff classification you use on 600 SKUs a week? The answer determines whether you keep shipping or pause $40M of in-flight inventory.
Last-mile exception in retail replenishment. A driver marks 14 stops as “delivered” but the geofence and dwell-time signature doesn’t match. Is this a falsification pattern? A broken scanner? A neighborhood with poor GPS? The action — coach, audit, redeliver, charge back — depends on getting it right within the same shift.
The pattern in all of these: the data is the world moving, the decision must be made while the world is still moving, and the action has to land on a specific entity with specific context. A coding agent’s leisurely loop of “think, call a tool, think, call a tool” is the wrong control system for this physics.
The Architectural Challenges Nobody Wants to Talk About
If you actually try to build agentic AI for supply chain decisions, you run into a stack of problems that generic agent frameworks were never designed to solve.
1. Data normalization at the speed of events
Supply chain data is not sitting nicely in a warehouse waiting to be queried. It’s arriving as a continuous, heterogeneous, high-velocity stream from sources like:
- Shipment telemetry — GPS pings, accelerometer, temperature, humidity, light exposure, shock, tilt, door sensors — sometimes every 30 seconds across millions of devices.
- Carrier and forwarder EDI/API feeds — 204, 214, 990, 856 messages, plus dozens of proprietary REST endpoints, each with its own schema dialect.
- Port and terminal operations data — vessel berth schedules, gate moves, dwell times, drayage availability, often crowdsourced or scraped because the authoritative feeds are paywalled or delayed.
- Crowdsourced and ambient signals — weather radar, road closures, port labor sentiment, social-media chatter from driver communities, marine AIS data, flight tracking for air freight.
- Product condition data — IoT-tagged pallets, RFID reads at DC doors, quality test results from line-side sensors, photo-based damage AI from yard cameras.
- Compliance and trade data — customs filings, denied-party screening hits, sanction list updates, tariff schedule changes that drop with hours of notice.
- Demand-side signals — POS data, e-commerce order velocity, planogram resets, marketing event calendars that determine which inventory matters most this week.
- Financial and commercial context — open POs, customer SLAs, penalty clauses, incoterms, lane contracts, fuel surcharges that make a “delay” cost $200 or $200,000 depending on which shipment it is.
The volume problem is real, but the harder problem is the semantic problem. The same physical event — “container arrived at port” — comes through five different feeds with five different timestamps, five different identifier schemes (container number vs. BOL vs. booking number vs. shipment ID vs. internal reference), five different status codes, and at least one of them is wrong or stale. Generic LLM agents collapse on this. They will happily hallucinate that a shipment is in two places at once because two of their sources disagree.
This means the underlying stack has to do real work before any agent ever sees the data:
- A streaming ingestion layer purpose-built for late-arriving, out-of-order, partially-correct events — not a batch ETL with a faster cron.
- An entity resolution and tagging layer that knows a shipment, a load, a container, and a leg are related but not the same, and that can match them across identifier systems with confidence scores rather than hard joins.
- A storage tier that can serve both time-series queries (the last 90 days of temperature readings for SKU X across lane Y) and graph queries (everything connected to this shipment, two hops out) with sub-second latency.
- A parsing and fusion layer that promotes raw events into typed, supply-chain-aware facts — not just “GPS ping at 33.7,-117.9” but “Trailer T-4471 dwelling 14 minutes inside theft-hotspot polygon LA-07, against schedule.”
- A normalization layer that maps every dialect of every EDI/API feed into a canonical model, with the original preserved for audit.
If your architecture starts with “let me call OpenAI’s API on this JSON,” you have already lost. The agent has no idea what it is looking at.
2. The relationship graph has to be live
Supply chain decisions are graph decisions. A temperature excursion on one shipment matters because of what it is connected to: the lot it belongs to, the production batch behind that lot, the customer order it’s allocated to, the contract that order falls under, the regulatory regime that contract operates in, the alternate inventory that could substitute, the carrier whose performance trend just got worse, the lane whose risk score just shifted.
Building this graph from a static daily snapshot is useless. By the time the snapshot loads, the world has moved. The graph has to be continuously updated as events stream in, with edges and weights recomputed in near real time, so that when an agent asks “what is at risk because of this event,” it gets an answer grounded in the current state of the world.
This is fundamentally different from the RAG patterns that dominate generic agentic AI. RAG retrieves documents. Supply chain decisioning retrieves the live state of a moving system.
3. Agents need a supply chain dictionary, not just a language model
Here is where most LLM-wrapper approaches fall over hardest. An LLM trained on the internet thinks “MEIO” is probably a typo, “BOL” might be a French exclamation, and “ASN” is autonomous system numbers from networking. It does not natively understand:
- Pharma: GDP/GxP, MKT, CAPA, lot genealogy, cold chain stability budgets, serialized item-level traceability under DSCSA, the difference between an excursion and a deviation, the regulatory weight of a Form 483.
- Food and beverage: FSMA 204 traceability lot codes, KDEs and CTEs, cold chain handoffs, allergen cross-contact protocols, shelf-life vs. code date vs. sell-by.
- Automotive: PPAP, EDI 830/862 release schedules, line-side min/max, sequenced delivery, supplier portal disposition codes, the cost-per-minute of a line-down event.
- High-tech and semiconductors: wafer lot tracking, MSL handling, ESD chain of custody, allocation regimes during shortage, second-source qualification status.
- Apparel and retail: floor-set dates, planogram compliance, ASN accuracy chargebacks under retailer compliance programs (Walmart, Target, Amazon vendor central), seasonal markdown cadence.
- Chemicals: hazmat classification, segregation rules, SDS-driven handling, reach/REACH compliance, tank washout requirements.
- Energy and industrial: rotating equipment criticality, MRO spares with long lead times, turnaround event scheduling, project-bound vs. operations-bound inventory.
These aren’t vocabulary differences — they are decision logic differences. A “delay” in apparel pre-floor-set is a chargeback event. The same “delay” in MRO spares for an offshore platform might not matter at all, or it might shut down a $2M/day asset. The agent needs an industry- and sub-industry-specific dictionary that defines what entities exist, how they relate, what events matter, what thresholds trigger what actions, and what the right next step is.
A generic LLM can be prompted toward this, but it will drift, hallucinate, and get the edge cases wrong — and edge cases are the entire job in supply chain.
4. Agents need to be spun up fast, without code, and orchestrate with each other
Real supply chain operations don’t have one decision to automate. They have hundreds: cold chain monitoring, theft response, ETA management, demurrage and detention, customs exception handling, supplier risk monitoring, returns disposition, allocation under shortage, freight audit, slot booking, yard management, and on and on.
No enterprise is going to hire an army of ML engineers to hand-code each one. The architecture has to support a supply chain agent factory where domain experts — not Python engineers — can:
- Compose new agents from a library of supply-chain-aware skills (entity resolution, geofence evaluation, risk scoring, action dispatch, customer notification, regulatory check) without writing code.
- Bind those agents to the live data graph so they have context the moment they’re deployed.
- Let agents call each other — a theft-detection agent invoking a security-dispatch agent invoking a customer-notification agent — with proper handoff of context and permissions.
- Maintain auditability, because every action an agent takes will eventually be questioned by a regulator, an insurer, a customer, or a courtroom.
A general-purpose agent framework treats this as a workflow problem to be solved with code. A supply-chain-native architecture treats it as a configuration problem on top of a domain-aware substrate.
Why a Wrapper on an LLM Will Not Get You There
It is tempting to believe that all of this can be solved by being clever with prompts on top of GPT-4 or Claude. It can’t, and the reasons are architectural:
- Latency physics. A round trip to a frontier LLM, plus tool calls, plus reasoning, is hundreds of milliseconds at best and many seconds in practice. For a theft-hotspot dwell decision that needs to fire in under a minute across millions of moving assets, you cannot put a generic LLM in the hot path of every event. You can put it in the reasoning path for ambiguous cases, but the deterministic, high-volume detection has to live in purpose-built infrastructure.
- Cost physics. 50,000 shipments emitting an event every minute is 72 million events a day to detect a security breach event. You are not running every event through a frontier model. You need a tiered architecture where most events are handled by deterministic, domain-tuned components and only the genuinely ambiguous ones escalate to large-model reasoning.
- Grounding. LLMs are trained on the public internet. The public internet does not contain your customer’s quality agreement, your carrier scorecards, your lane risk history, your lot genealogy, or your contractual penalty schedule. Without a domain-specific data substrate, the agent is reasoning about a world it has never seen.
- Reliability and audit. “The model decided” is not an acceptable answer to a regulator asking why a biologic was condemned, or to an insurer asking why a $4M load was released to a suspect carrier. Decisions need explainable provenance — which event, against which rule, against which contract, produced which action. This is a property of the architecture, not of the prompt.
- Composability with the operational stack. Supply chain decisions land in TMS, WMS, ERP, OMS, control towers, EDI gateways, and carrier portals. A generic agent that can “call APIs” is not the same as an agent that knows the semantics of an EDI 214 status update or a SAP IDoc, and that can produce a correctly formatted, audit-trailed message that the receiving system will actually accept.
You can build wrappers around these problems one at a time. But what you end up with, after enough wrapping, is the AI-native supply-chain-first architecture you should have started with.
The Emergence of Decision AI for Supply Chains
The category that’s emerging here isn’t “agentic AI in supply chain.” It’s Decision AI — systems whose primary output is not text, not a chart, not a recommendation in a slide, but a decision, executed against a live operating system, in the time window where the decision still matters.
Decision AI for supply chains has a distinct profile:
- It ingests the world as it moves, not as it is reported.
- It maintains a live, semantic, supply-chain-aware graph of entities and their relationships.
- It separates fast, deterministic decisioning from slow, deliberative reasoning, and uses each where it belongs.
- It is built on industry- and sub-industry-specific dictionaries, not on generic language models.
- It exposes an agent factory where operators, not engineers, compose new decisions.
- It closes the loop into the operational stack with the right protocols, formats, and audit trails.
- It treats every decision as a reviewable, explainable, regulator-ready artifact.
This is not where horizontal agent platforms are heading. They are optimizing for breadth: any task, any domain, any workflow. Decision AI for supply chains is the opposite bet — depth in a domain where the physics of the problem rewards depth.
Where Decklar's Moat Lives
Decklar has been building for this shape of problem from the first line of code, and the moat shows up across the stack rather than at any single layer:
- At the data layer, a streaming ingestion and entity-resolution substrate purpose-built for the late-arriving, multi-identifier, multi-dialect reality of supply chain events — not a generic data platform with supply chain dashboards bolted on.
- At the graph layer, a live relationship graph that updates as the world moves, so agents reason about the current state of the network rather than yesterday’s snapshot.
- At the semantic layer, industry- and sub-industry-specific supply chain dictionaries — pharma, food, automotive, high-tech, retail, chemicals — that give agents the vocabulary and decision logic the domain actually requires.
- At the agent layer, a no-code agent factory that lets supply chain operators compose, deploy, and orchestrate agents against the live graph without going through an engineering backlog.
- At the action layer, native integration with the operational stack — TMS, WMS, ERP, control towers, carrier and customer systems — so decisions don’t stop at a notification but land as executed actions with full audit provenance.
- At the decisioning layer, a tiered architecture that uses deterministic, domain-tuned components for high-volume detection and reserves large-model reasoning for the genuinely ambiguous cases, giving the latency, cost, and reliability profile the domain requires.
Each of these is hard on its own. Together, they compound. A wrapper on a general LLM can replicate any one of them on a slide. None of them in production. And certainly not all of them as one coherent stack.
The Bottom Line
The agentic AI conversation is being shaped by use cases where time is cheap and the work product is text. Supply chain is not that conversation. It is a domain where decisions have to be made while the world is still moving, on entities that are physical, against contracts that are real, under regulations that are unforgiving.
Generic agent factories will keep getting better at writing code overnight and summarizing meetings. That is a real and valuable category. It is not the category that will run global supply chains.
The category that will run global supply chains is Decision AI, built supply-chain-first, ground-up. That is the bet, and that is where the moat is.
