Smart Warehouse is a warehouse diagnostics agent. It lives next to your WMS — SAP EWM today, Manhattan Active and Blue Yonder next. It reads the system, reasons about what it sees, and helps a shift lead or consultant figure out what is actually wrong.
The single most important thing we had to get right is not the LLM. It is not the prompt. It is not the tool calls. It is the memory.
Without memory, Smart Warehouse is a chatbot with a tokenizer. With memory, Smart Warehouse is a colleague.
Three layers, three lifetimes
We think of memory as three distinct layers, each with a different lifetime and a different owner.
Episodic memory (hours) is the live session. What has the operator asked? What did the agent propose? Which tool calls went through? This is the short-lived working context. It lives in PostgreSQL keyed by session id, and it dies when the session dies.
Case memory (weeks) is the middle layer. Every warehouse issue is a case: a stuck delivery, a broken wave, a mis-bin. The case accumulates artefacts — WMS extracts, hypotheses, resolutions — until the case closes. Case memory lives in PostgreSQL plus an embedded vector index, so that when a new case opens we can pull the closest old cases as reference.
Site memory (years) is the long horizon. Every warehouse has its own personality: which putaway strategies it relies on, which RF transactions it uses, which users tend to escalate, which exception patterns have happened before. Site memory is a curated store of ground truths about this particular site. It is built by humans, for humans, with the agent adding proposals.
The three layers are layered deliberately. Short memory is cheap and disposable. Long memory is expensive and sacred.
Why not a vector database for everything?
Because meaning is not always the right index. Sometimes you want strict equality. Sometimes you want joins.
A stuck delivery in a specific plant, warehouse, and door is not a cluster of vectors. It is a tuple. Smart Warehouse starts its reasoning in the structured world and only reaches for semantic search when the structure runs out.
The vector index is a fallback for the moment the agent asks "what does this situation remind me of?" — and for that question, vectors beat SQL. For everything else, SQL beats vectors.
Governance: every write is reviewable
The hardest part is not storing memory — it is deciding what is worth storing.
Every write to site memory passes through a human review queue, because the site memory is read during every future reasoning step. A bad site memory fact poisons every future case. A good one compounds.
Case memory is written by the agent directly but flagged for review after a defined number of referrals. An agent that cites a case seven times is, in effect, claiming that case matters — and that claim deserves audit.
Episodic memory is never reviewed. It dies too fast to matter.
The result
A Smart Warehouse session on day one is useful. A Smart Warehouse session on day ninety, in a site with a well-curated memory, is materially different. The agent now speaks in the vocabulary of the floor. It knows that this warehouse's staging area is the usual suspect. It remembers the consultant who always resolves this class of issue.
That compounding — memory built from real cases, carefully written, carefully reviewed — is the difference between an agent that ships and an agent that sits in a demo.
Anyone who tells you memory is a solved problem has not yet put an agent in front of a shift lead at 3am on a bad night.