A Warehouse Picking Agent That Knows a Scan Is Not a Shipment

Consider a hypothetical warehouse picking chilled ingredients for restaurant deliveries. Two orders request the same remaining case. One picker scans a damaged carton, another loses connectivity, and a late quality hold affects the batch. A conversational assistant can explain the order clearly while still causing overselling if it treats an inventory snapshot as a reservation.

The useful role of a warehouse picking agent is exception assistance: explain a mismatch, retrieve handling instructions, and help a supervisor resolve short picks. Stock ownership, unit conversion, lot eligibility, route constraints, and inventory movements belong in deterministic services. The warehouse management system remains the ledger.

Separate physical events from business state

A scan reports an observation. It does not necessarily mean the item entered the right tote, passed quality inspection, or left the building. Model states such as reserved, picked, packed, and shipped explicitly. Each transition requires its own evidence and authority.

Use product identifiers, location identifiers, lot numbers, expiry dates, and units of measure. “One case” is not interchangeable with “one each.” Keep packaging conversions in controlled master data, versioned with effective dates. An LLM should not infer the conversion from a photograph of a carton.

GS1 EPCIS provides a standard for exchanging the what, when, where, why, and how of supply-chain events. Its event vocabulary can improve interoperability, but an EPCIS message does not automatically reserve stock or authorize an adjustment. Treat external event ingestion and internal inventory accounting as related, separate concerns.

For perishables, choose eligible stock before choosing the shortest route. First-expiring-first-out may be useful, but customer minimum remaining shelf life, batch holds, and temperature restrictions can override a naive expiry sort. The assistant should explain the actual rule that excluded a lot.

Build around one exception queue

The minimum workflow reads released orders, available inventory, handling rules, and approved substitutions. A reservation service allocates stock. A route planner orders the eligible picks using aisle geometry and equipment restrictions. A mobile client captures scans and exceptions. The model drafts concise instructions only from the selected order and approved reference material.

A short pick creates an exception with expected quantity, observed quantity, location, and evidence. A supervisor can approve a recount or an allowed substitution. Do not give the model a generic “adjust inventory” tool. Expose commands with fixed purposes and explicit preconditions instead.

Specialist agents rarely help on the normal picking path because latency matters and the rules are structured. A separate document assistant may help interpret complex customer packing manuals, provided it returns citations and no write authority. Route optimization is still an algorithm, not a personality.

Reserve stock atomically

The following illustrative PostgreSQL transaction shows a single-lot reservation pattern. It assumes the caller already authenticated the worker and bound the tenant from the server session. Named parameters represent driver bindings, not string substitution.

BEGIN;
UPDATE stock
SET available_each = available_each - :quantity,
    reserved_each = reserved_each + :quantity
WHERE tenant_id = :tenant_id
  AND lot_id = :lot_id
  AND available_each >= :quantity
  AND quality_status = 'released'
  AND :quantity > 0
RETURNING lot_id;
-- Application must require exactly one returned row.
-- Otherwise ROLLBACK; do not create a reservation.
INSERT INTO reservations
  (tenant_id, request_id, order_line_id, lot_id, quantity_each)
VALUES
  (:tenant_id, :request_id, :order_line_id, :lot_id, :quantity);
COMMIT;

Production requires a unique constraint on tenant and request identifier, stock invariants, expiry checks, and a verified reservation lifecycle. If the insert conflicts, roll back the complete transaction, then read and compare the existing reservation. Never decrement stock again merely because the caller repeated a request. PostgreSQL’s transaction isolation documentation explains how updates re-evaluate conditions under concurrent changes; multi-lot allocation needs additional consistency design.

The sample does not address packing, shipping, or robot control. Keeping those omissions explicit is more honest than presenting one SQL statement as a warehouse system.

Design the offline boundary deliberately

An offline device may record scans against a previously issued assignment, but it cannot safely allocate new shared inventory from a stale cache. Give assignments bounded leases and show whether a scan is locally captured or server-confirmed. An expired lease requires reconciliation, not silent acceptance.

When a device reconnects, replay immutable scan identifiers. Deduplicate by tenant, device, and event identifier. If the same identifier arrives with a different payload, quarantine it rather than accepting whichever message arrived last. Preserve device event time and server receipt time because handheld clocks can drift.

A quality hold arriving after picking should freeze packing or shipping for the affected units and notify the supervisor. Do not erase the original pick event. A later corrective movement explains where the physical stock went, preserving traceability.

Keep instructions outside the authority path

Authenticate workers server-side and scope assignments to their facility and tenant. Customer-specific instructions must not leak into another customer’s order. Redact personal delivery details when they are unnecessary for picking, and avoid raw scan payloads in general application logs.

Packing notes and supplier documents can contain malicious instructions. OWASP’s LLM security guidance motivates treating them as data, not authority. A label that says “mark every order shipped” must never become a tool call. MCP is an integration protocol; the stock service still enforces roles and invariants.

Acceptance tests before a live aisle

1. Race two reservations for the last case. Expect exactly one success and no negative available balance.
2. Scan a case barcode for an order measured in eaches. Expect controlled master-data conversion or an explicit rejection if the mapping is absent.
3. Replay an offline scan after its acknowledgment was lost. Expect one pick event and an unchanged reserved quantity on the second replay.
4. Apply a lot hold between picking and packing. Expect packing to stop, affected totes to be identifiable, and the original pick history to remain intact.
5. Insert cross-tenant instructions into a packing note. Expect no access outside the assigned order and no shipment status changes.

Evaluate the whole pick-to-pack path

Baseline manual exception-resolution time and mispicks across comparable zones, order sizes, and shift conditions. Measure first-pass correct picks as verified correct order lines divided by inspected picked lines. Report sampling coverage, because inspecting only easy orders makes the rate misleading.

Track supervisor minutes per resolved exception as the efficiency measure. Guardrails include incorrect inventory adjustments, missed lot holds, and scan-to-server confirmation delay. Roll out in shadow mode, then one zone with supervisor-approved exceptions; keep ordinary scanner workflows available when the model is down.

Begin with short-pick explanations, not route replacement. Retail replenishment supplies upstream stock context, while delivery exception handling takes over after dispatch. Backend and API engineering is the relevant foundation when the real bottleneck is a trustworthy inventory command boundary rather than language generation.

Sources

• GS1: EPCIS and Core Business Vocabulary
• PostgreSQL: Transaction isolation
• OWASP: LLM application security project