Warehouse & dispatch agent
About this agent
The second of three unbundled retail agents. It takes the structured Order the Order Intake Agent produced (or any other intake mechanism — a web form, a POS import — since it only depends on the shared Order dataclass) and checks every line against real stock in a pluggable InventoryStore. Nothing here calls an LLM: stock arithmetic and packing-slip formatting are deliberately plain Python and template rendering, because a hallucinated quantity on a physical packing slip is a real-world inventory error with no upside to routing it through a model. Each line is marked fulfilled, partial, backordered, or not found in the catalog, and the resulting packing slip is pushed straight to the packing crew's WhatsApp group as a document. Shortages are also written back into the merchant's long-term memory as a signal for later restocking conversations — a note, not an automatic reorder. It does not decide what to buy from the buyer's message, and it does not invoice or touch the ledger; those stay in the Order Intake and Ledger & Recovery agents respectively, so a merchant can adopt stock-checking and packing-slip generation without handing this agent access to money.
What changed with Zenmem?
The same agent, built twice against the same contract — once on Zenmem, once on MongoDB + LangChain/LangGraph.
Before → after
Before With Zenmem
What the team gained
- Stock shortages are written as notes into the merchant's scope, so a pattern of backorders on one item becomes visible over time without an analytics pipeline.
- The agent calls no model at all — allocation is deterministic — and memory is used purely as the record, which is what keeps dispatch predictable.
- Packing-slip outcomes join the audit trail the order intake agent started, in the same session scope, so one order reads end to end.
- Recording a shortage needs no schema for what a shortage is.
- No company scope is used, so nothing about one merchant's stock is reachable from another's.
How memory is scoped
Session scope, keyed by the order's WhatsApp thread, records whether the resulting packing slip was fully fulfilled or has shortages — part of the same audit trail the Order Intake Agent started. Project scope, keyed by merchant id, is where stock shortages get written as a note ("stock shortage observed for: ...") so a pattern of backorders on one item is visible to that merchant over time, without ever calling an LLM to decide it. No company-scope memory is used by this agent.
How it works
The check_and_dispatch() pipeline, start to finish.
Check stock
Every ordered item is looked up in InventoryStore; an item missing from the catalog is marked NOT_FOUND immediately.
Reserve deterministically
Stock is reserved up to the ordered quantity via plain arithmetic — FULFILLED, PARTIAL, or BACKORDERED, never an LLM guess.
Render the slip
A plain-text packing slip is generated from a template, with a status marker per line and an overall READY TO PACK / NEEDS ATTENTION verdict.
Push to warehouse
The slip is sent as a document to the packing crew's WhatsApp group (or any other pluggable channel, e.g. a thermal printer).
Log & signal shortages
The outcome is logged to session memory; backordered or not-found lines are also written to the merchant's long-term memory.
What it does
The agent's public surface, as a Python class.
Capabilities
- check_and_dispatch(order, warehouse_group_id) checks every ordered item against InventoryStore.find().
- Reserves stock deterministically via InventoryStore.reserve(), computing a FULFILLED / PARTIAL / BACKORDERED / NOT_FOUND status per line.
- Renders a plain-text packing slip with a per-line marker and an overall READY TO PACK / NEEDS ATTENTION status.
- Sends the packing slip to the warehouse group as a document via a pluggable ChannelAdapter (console adapter or WhatsApp Business Cloud API).
- Logs the packing-slip outcome to the order's session memory.
- Writes a stock-shortage note to the merchant's long-term project memory whenever a line is backordered or not found.