Case studyAgentic Engineering · Process Re-engineering

The operation that fixes itself before the customer feels it.

A damaged pallet used to mean a delivery missed and discovered days later. Here a chain of governed agents senses it, prices the recovery options in dollars, and hands a human one decision, all in about ninety seconds. This is the Hertz/Palantir orchestration pattern, rebuilt for a retailer, with the part their demo leaves out: you can audit every decision.

01 / The pain

One damaged pallet, and the promise quietly breaks twice.

A pallet of a high-demand laptop arrives crushed. The units leave sellable stock, but nobody connects that to the S$137,000 contract order due in six hours that depended on them. Traditionally the damage is emailed to inventory, logged by hand, and the shortfall is only discovered at pick-and-pack. A buyer then phones other sites for stock; finance files the supplier claim weeks later, if at all. The cost is paid twice, once in the emergency scramble and again in the customer-facing miss, because each team optimises its own corner and nobody owns the outcome.

02 / Why the naive approach fails

"Stock dropped, so reorder it" is the wrong question.

The obvious automation watches on-hand stock and reorders when it dips. It would miss the actual problem, because the constraints that matter aren't on the stock count:

On-hand ≠ available40 in stock can still be a shortfall. Of the 40 sellable units left, 25 are already committed to earlier orders, so available-to-promise is 15, against a 30-unit order. A reorder trigger on "on-hand" never sees the gap.
Cheapest ≠ bestThe lowest-cost option loses money. A substitute SKU costs almost nothing to offer, but a B2B contract customer may reject it. Pick on price alone and you protect the order on paper and lose it in reality.
Time is a hard constraintA 48-hour replenishment is worthless at hour six. The fastest fix and the cheapest fix are usually different options; you can't optimise one axis.
Recovery is left on the tableThe S$252k supplier claim isn't anyone's job. The damaged units are recoverable under the supplier's terms, but reorder logic doesn't file claims, so the money leaks.

The real job is to price each recovery option against the SLA and the risk, protect the at-risk order, recover the cost, and put the committing decision in front of a human. That is orchestration, and a reorder rule cannot do it.

fig.1 · a reorder rule vs orchestration that scores options against the SLA

03 / How it works

The dollars are computed. The model narrates the reasoning.

Four agents work the event over one connected view of the business. The economics are deterministic. Available-to-promise, the shortfall, the claim value and each option's expected value are computed in code, reproducible to the cent. The language model is read-only. It narrates each agent's reasoning and drafts the supplier claim, citing the records. And the one action that commits money and stock is escalated to a human by policy.

fig.2 · the trust boundary: code scores and gates; the model only narrates

The option scoring is the part that looks like judgment, so here it is written out as an explicit equation. Each option carries a modelled cost, a time-to-execute, and the revenue it protects, discounted by the probability the customer accepts it:

fig.3 · the hard part is expected-value scoring, with the acceptance-risk term

04 / One worked example

Three options, scored, and why the cheapest one loses.

The damaged pallet leaves 40 sellable, of which 25 are committed → ATP 15 against the 30-unit order due in 6 hours. Three recovery options are scored:

Option	Cost	Time	Revenue protected	Acceptance	Expected value	Result
Inter-DC transfer (DC-NORTH)	S$420	4h ✓ SLA	S$136,676	100%	S$136,256	recommended
Offer substitute SKU	S$96	1h ✓ SLA	S$136,676	60% (B2B)	S$81,910	cheapest, not chosen
Priority PO / drop-ship	S$1,150	48h ✗ SLA	S$0	·	−S$1,150	misses SLA

This is the case that separates a good rule from a bad one. The substitute is by far the cheapest at S$96, and a price-led rule would grab it. But a contract customer rejecting a substitute is a real risk, so its revenue is discounted to 60%, and its expected value falls below the transfer. The system recommends the transfer: same product, in-SLA, full value protected. In parallel, a S$252,042 supplier claim is filed for the 80 damaged units, the recovery that usually goes unclaimed.

05 / Numbers & honest trade-offs

What it protects, and what the numbers rest on.

2 days → 90s

detect → decision

vs the manual scramble.

S$252k

cost recovered

80 units × ~S$3,150, claimed.

S$137k

order protected

re-sourced inside the SLA.

human approval

on the committing action.

Where these come from, honestly. Origin is a synthetic retailer I generate. The S$252k is the modelled replacement value of the damaged units and the S$137k is the contract order's value, both computed from the seeded records rather than measured against a real warehouse. The "90 seconds" is the orchestration runtime, not a benchmarked SLA. The acceptance probabilities (100% / 60%) are assumptions, stated as such. In production they'd be tuned from how often each customer segment actually accepts a substitute. What the demo proves is the scoring logic: the system weighs cost, time and acceptance risk together rather than grabbing the cheapest line.

06 / Governance, shown

The committing action is escalated. Here is the ledger entry.

Routine agent actions clear automatically; the one that commits the recovery is gated to a human. That decision is the gate's structured output, written to the hash-chained log, and it is not prose the model wrote.

AI Control Ledger · entryintegrity verified · 4 actions logged

seq        : 4
agent      : Operations manager
action     : commit_fulfilment
subject    : OPT-1 / SO-90021       amount : S$136,676
tier       : high          decision : escalate → human   policy : POL-GOV-HITL
reason     : high-value commitment routed to a human approver
prev_hash  : 7b1e…44af    hash : c9d0…218e

Earlier in the same run, open_supplier_claim, reserve_transfer and reassign_order all cleared as allow. Only the commit escalates.

What this says about how I work.

This is two competencies in one screen. The first is process re-engineering. I take a slow, siloed, multi-day recovery and redesign it as a single flow that optimises the outcome rather than one department. The second is governance by design. The economics are computed and reproducible, the option that looks cheapest is correctly rejected for its real risk, and the action that commits money stays with a human, all on an auditable ledger. Redesign the process, then make it safe enough to trust: that is the judgment I'd bring to leading an AI transformation.

See it run.

The option table and the ledger entry above are real output from the orchestration engine over Origin's data. The full control tower runs as a working application, with the live event feed, the four-agent reasoning chain, and the approve gate.

See the live governance demo →The full console runs on my machine. Ask me for a 90-second walkthrough.