1. Why supply chain is the natural home for loops
Picture a mid-size hardware brand: eight or nine ERP stocking locations across the US, Canada, Europe, and Asia, contract manufacturing overseas, and a purchase order that takes roughly 90 days to become sellable stock — 30 to 45 days of production, 20 to 35 on the water, customs, trucking. At any moment, most of the inventory is in motion. Any planning method that only looks at what's on the shelf is wrong by construction.
At that size there is no demand planner. Planning is a spreadsheet, a velocity eyeball, and someone's memory of a PO from January. It mostly works because the people are good, and it fails in the ways you'd predict: purchase orders that quietly slip a year past their promised date, ERP arrival dates that are just the order date typed twice, stock parked in one region that nobody has compared against that region's sales in months.
Here's the thing operators intuit but rarely say out loud: this work is a loop, not a project. The same questions, against fresh data, on a cadence. That's precisely the shape of work agents are good at — and precisely the shape humans do worst, because the tenth identical Tuesday review gets skipped when the quarter heats up. Supply chain planning at review cadence is, I'd argue, the single best-fit agentic use case in an operating company: high dollar consequence, fully structured inputs, and a natural human checkpoint already built into how the work is approved.
2. The architecture: deterministic core, AI edges, human gate
The pattern has four separated stages. The separation is the design.
Mon + Thu, 7:00 AM — cron on a bot fleet (OpenClaw-style gateway)
collector script (deterministic) frozen, hand-verified ERP queries:
stock by location, 28/90-day
velocity, open POs and transfers
│
the model reasons over that JSON days of supply per region, goal
against a rules file gaps, transfer candidates, PO
alerts, ocean-vs-air math
│
publisher script (deterministic) snapshot + recommendations into
a database, each with an ID, a
rationale, and a deadline
│
chat post + live dashboard "2 new POs, 3 recommendations,
1 stockout risk — REC-IDs"
│
HUMAN: "execute REC-07-06-01" an interactive agent re-checks
live stock, creates the actual
Transfer Order or PO in the ERP,
drafts the freight instructionsThree rules make it trustworthy enough to run unattended:
The loop is propose-only. It cannot create, modify, or delete anything in the ERP. Every recommendation carries an ID, the reasoning, and a one-line answer to "what happens if we do nothing." Execution lives in a separate interactive session, against a named ID, after a live re-check, with a human saying yes. That gate isn't a compromise — it's the feature that lets a public-company operator sleep while a robot plans their inventory.
Deterministic core, AI edges. The ERP queries are frozen SQL, verified by hand once. The database writes are a dumb publisher. The model only does what models are uniquely good for: reasoning over the numbers with seasonality, lead times, and business rules in context, then writing the summary a human actually reads. When the collector fails, the bot doesn't improvise. In one deployment, the loop's first-ever run hit a bad file path and posted "no data was collected; I won't estimate inventory" and stopped. That's the proudest failure I've seen shipped — a system that knows refusing is a feature.
The rules file is the moat. Generic planning software doesn't know that prescription stock can only ship from the one building with the lab, that licensed products can't legally cross into certain regions, or that a factory's new-year shutdown means the last safe order date is in late November. An owned loop knows, because you wrote it down once, in plain language, in a file the model reads every run.
3. The economics: a planning run costs less than a coffee
The cron runs a mid-tier model with a small-model fallback. A full planning cycle — collect, reason, publish, post — lands around 7,000 tokens: fractions of a cent, twice a week, informing decisions that move five-figure freight. Frontier models appear in exactly two places: the interactive session where a human interrogates a recommendation before approving it, and the one-time build. Model selection per job is governance, not thrift; a frontier model on a cron is almost always a design smell.
The build is where you spend real compute, deliberately — and mostly on not building yet.
4. The build method: audit before you automate
The most valuable phase of this kind of project produces zero features. Before writing the planner, run two multi-agent passes:
Research with adversarial verification. Parallel agents research the actual supply chain math — safety stock with lead-time variance, periodic-review policy for your cadence, freight economics, seasonality buffers — and every numeric claim gets attacked by an independent verifier agent before it's allowed into the config. You end up with an evidence-backed defaults file instead of a vibe.
Audit everything the system will stand on. Every existing inventory doc, query, and cron job gets reviewed by an agent, and every finding adversarially verified. In one deployment this pass confirmed dozens of defects in "trusted" assets, including a velocity query that counted unfulfilled orders and cost-of-goods lines alongside sales — inflating measured demand up to 3x on some SKUs. Every restock number that query ever produced inherited the error. Automating on top of it would have industrialized the mistake at twice-weekly frequency. The audit found the 3x bug before the 3x bug found anyone.
The output of that research phase is published here as a standalone reference — formulas, z-tables, lane variability, freight seeds, and the config block: SCM Planning Reference: The Math Behind an Inventory Loop.
And one hard-won caveat: adversarial verification cannot catch a false premise everyone shares. Hand your audit agents a "known rule" from the docs and they'll apply it faithfully — even if the live ERP disagrees. In practice, ERPs disagree constantly: status codes that don't match the documentation, dual item records where the sellable balance sits on the record the rule says to ignore, calendar facts in canonical docs that are a full year stale. Docs lie; the live system doesn't. Always budget a verification pass against production before anything automated is allowed to trust a document.
5. What the first runs surface (and why operators should want the argument)
The consistent experience across deployments of this pattern: the loop's first output argues with the operator's intuition, and the data usually wins. The gut says "reinforce the underperforming region"; the numbers show that region holding years of cover at current velocity — a demand problem no transfer can fix, where shipping more units is working capital lit on fire. Meanwhile the actual urgency is three fast movers at a marketplace warehouse with two to three weeks of supply and plenty of donor stock a truck ride away.
The unglamorous findings matter as much: aged POs nobody was chasing, placeholder ETAs, phantom inbound units distorting every reorder calculation. A diff-based PO tracker — compare this run's open orders against last run's — is trivial to build and catches the entire class: new orders announced, dates slipped, promises gone quiet.
6. The operator's workflow, honestly
Twice a week, a chat message: attainment versus plan, any new or late POs, the top recommendations with IDs. Thirty seconds to read. When something needs action, the operator opens the dashboard, reads the rationale and the "if we do nothing" line, and either dismisses it or types one command in an interactive session. The agent re-checks the source warehouse still has the units, creates the transfer order or PO, quotes the ERP document number back, and drafts the email to the freight forwarder for a human signature. The human contribution compresses to the part that was always the point: judgment, relationships, and the yes.
7. What the pattern replaces
Human capital. Below a certain size you never hire the demand planner; the COO and the ops team bleed four to six hours a week into velocity pulls, PO status checks, and "how much do we actually have in Montreal?" Above it, this is a $70–90K S&OP analyst whose first year is mostly data collection. The loop replaces the collection and the arithmetic — which was most of the hours — and leaves the judgment, which was most of the value.
Software. This sits exactly where the inventory-planning SaaS tier lives: ERP-connected tools computing reorder points at $500 to $2,000 a month per brand. They're fine at the math and blind to the constraints — the licensed-region rule, the single-building prescription rule, the factory calendar. The owned loop runs on infrastructure most operating companies already have (a database, a chat server, a VPS, an ERP with an API); marginal cost is those 7,000 tokens per run.
Manual workflows. The quarterly where-is-everything reconciliation panic. The chase list in someone's head. The fourth retyping of the same freight-forwarder email. The export-to-spreadsheet ritual to compute days of supply. Either automated or pre-drafted for signature.
What it does not replace: the vendor negotiation, the bet on a product, the accountability. Every unit that moves still moves because a person read the reasoning and said yes.
8. Where to start
This is forward-deployed engineering in the original sense: the build happens inside the operation, by people close enough to the problem to name it precisely — not a vendor integration project. If you're a COO or supply chain lead considering it, the sequence that works: audit the queries and docs you'd build on (expect defects; be grateful for each one found early), verify the survivors against the live ERP, encode your constraints in a rules file a model can read, ship the loop propose-only, and keep the human gate on anything that touches money — permanently. The gate is not the training wheels. The gate is the product.