Fulfillment Exception Agent

A fulfillment exception agent helps a fulfillment coordinator clear stuck orders without guessing. When a pick fails, a SKU is short, an address looks wrong, or a carrier cut-off is missed, the agent gathers what the order and inventory systems already know, proposes a concrete resolution, and stops. A person still decides and still edits the order.

The agent does not cancel orders on its own. It does not invent stock. If inventory on-hand, reservations, or order state are missing or inconsistent, it returns empty output and flags the gap so a coordinator can fix the data first.

Typical inputs are the order ID, line items, ship-from location, promised method, and the exception reason from WMS or OMS. Typical outputs are a short resolution draft: what changed or what should change, which lines are affected, whether the customer needs a message, and whether the case should escalate.

Exception queues grow for ordinary reasons: a pick location is empty after a cycle count, a gift wrap SKU is inactive, a split shipment was blocked by policy, or a customer note conflicts with the selected service level. Coordinators already know how to resolve most of these. The bottleneck is context: opening the order, checking nearby nodes, reading prior notes, and drafting a reply that matches policy.

An agent earns its place when the same exception types repeat and the resolution path is rule-bound. Short ship with a substitute available in the same node. Hold until tomorrow’s inbound ASN posts. Re-route to a secondary DC that already has the units reserved. Notify the customer that the gift message cannot print and offer a card insert instead. Those paths are good candidates because the agent can check systems and assemble a draft faster than a person hopping between screens.

It is a poor fit when the exception is truly novel, when fraud or chargeback risk is in play, or when policy requires a supervisor override for every change. In those cases the agent should classify and escalate, not invent a workaround.

The agent follows a fixed sequence so coordinators can trust what they review.

First it loads order state: open lines, quantities, hold codes, payment or gift-card constraints, and the current fulfillment plan. If any of those fields are absent, it stops with empty output rather than assuming defaults.

Second it checks inventory for the requested SKUs at the assigned node and, when policy allows, at alternate nodes in the same network. Available-to-promise must come from the inventory service, not from a free-text guess. If the inventory feed is down or returns null for a required SKU, the agent again returns empty output and names the missing source.

Third it maps the exception reason to allowed actions. Common drafts include: allocate from an alternate location, split the order, substitute a same-price SKU on the same line, delay ship until a named inbound receipt, change service level within the promise window, or prepare a customer contact asking for a choice. Cancellation is never an automatic action. If the only viable path under policy is cancel-and-refund, the draft states that a human must confirm cancellation and apply it in OMS.

Fourth it drafts customer contact only when needed. Wrong address, missing apartment number, or a customer-requested hold usually need a message. A silent reallocation inside the same SLA window often does not. The draft includes the proposed wording and the channel the team normally uses.

Fifth it marks escalation when inventory is insufficient everywhere, when the promise date cannot be met under any allowed option, or when the exception type is outside the playbook. Escalation means a human owns the case; the agent does not leave the order in limbo with a partial edit.

Staff remain the system of record for order edits. The agent produces a resolution draft: proposed line actions, proposed ship-from or method changes, suggested customer message, and a confidence note that cites which systems were checked. The coordinator accepts, edits, or rejects that draft, then applies the change in OMS or WMS with their own credentials.

That split matters for audit and for safety. Allocation mistakes that look “helpful” (shipping from a store that never ships e-commerce, consuming reserved B2B stock, or cancelling a prepaid gift order) create customer harm and reverse logistics cost. Keeping write access with people who know node capabilities and peak-day policy avoids those errors while still cutting research time.

Review checklists stay short. Confirm the inventory numbers match what the coordinator sees in the live screen. Confirm the proposed method still fits the delivery promise. Confirm the customer message does not over-promise a date the network cannot hit. Confirm cancellation language appears only when the coordinator is prepared to cancel manually.

Related tools that sit upstream of this agent include Order Routing Optimizer for first-pass ship-from selection and Pick Path Optimization for reducing pick failures that feed the exception queue. Promise dates that feed exception urgency are covered in Delivery Promise Accuracy Model.

Minimum viable context is order header and lines with current status, inventory available and reserved by SKU and node, exception reason code, and fulfillment policy for substitutes, splits, and contacts. Useful additions are ASN dates, carrier cut-off calendars, prior customer messages, and gift or legal constraints on the order.

Return empty output when any of these fail: order state cannot be loaded; inventory for a required SKU is null or timed out; the exception reason is unknown and no playbook maps to it; or two systems disagree on quantity in a way the agent cannot reconcile. Empty output should include a one-line reason so the coordinator knows whether to refresh data, open a ticket with inventory ops, or handle the case fully manually.

Do not fill gaps with averages or “usually we have stock.” Do not auto-cancel when stock is zero. Do not send the customer message until a person approves it if your channel rules require approval. The value of the agent is a trustworthy draft, not a silent write.

Start with a narrow exception taxonomy: short pick, address issue, method conflict, gift SKU unavailable, and carrier miss. Measure draft acceptance rate, time from exception open to human-applied fix, and how often empty-output cases trace back to bad inventory feeds. Widen the playbook only after those feeds are stable.

Train coordinators to treat the draft as a starting point. Encourage edits when local knowledge beats the system (a node is in blackout, a substitute SKU looks wrong on the shelf photo, a VIP order needs a phone call). Keep escalation paths visible so unresolved cases do not age in the agent’s “suggested” state.

When the queue is clean, most exceptions resolve as allocate-elsewhere, delay-for-inbound, or ask-the-customer. The agent’s job is to assemble those options quickly from live inventory and order state, leave cancellation and final writes to people, and stay silent when the data is not there.