Work · 04 Warehouse assistant · Assistant interface
An assistant that reaches a warehouse without being handed the keys to it.
This is the build with no client in it. It connects an AI assistant to a named warehouse system. You can judge its design, its list of commands, its refusal messages and its test count on their own, without taking my word for anything.
- Client
- None. A build with no client in it.
- Layer
- 4 of 4. Assistant interface.
- Target
- Extensiv 3PL Warehouse Manager.
- As of
- 2026-09-18, tested against a stand-in warehouse, not a live account.
- Published
Service Knowledge bases for AI assistants How an engagement runs
The problem is not making the connection. The problem is that an assistant repeats itself. It tries again after a timeout. It acts on a preview that has since gone stale. A dropped connection leaves it unsure whether the order went through. Each of those can create the same order twice. In a warehouse, a stock system that no longer matches the shelves is the failure that matters. The cheaper answer, named first: a general-purpose connector service already links assistants to thousands of common business apps. If a job is just "connect the assistant to a well-known app", that service does it and I should not be selling a build. The work worth paying for is the rest. Private systems. Apps the connector service does not cover. Deciding exactly what the assistant may touch. Making a repeated request safe.
01 The constraint
What was actually hard.
Making a change safe enough to let an assistant near it. The answer is to split the job in two. Drafting a change and making it happen are separate commands. Drafting writes nothing at all. Every check is then run again at the moment of the change, against what the system holds right then. If someone narrowed the assistant's permissions after the draft, or edited the order in the meantime, the change stops instead of overwriting their work.
02 The mechanism
How it works.
- Five parts, with one of them doing all the vendor-specific work. The main part holds the sixteen commands, the permission rules, the two-step change engine and the logs. It knows nothing about the vendor. A single separate part holds everything the vendor requires. How to sign in. How its messages are shaped. How to filter and page through its data. How to turn its errors into plain answers. Pointing this at a second warehouse system means rewriting that one part.
- Sixteen commands: eleven that only read, four that draft a change, and one that makes a change happen. When changes are switched off, those five commands are not loaded at all. They do not appear in the assistant's list, so it cannot call what it cannot see. Read-only is built into the structure. It is not a setting the code remembers to check.
- Six checks run at the moment of the change, all against live data. Has this already been done? Is it the right company and the right system? Has the draft expired? Is it still within permission? Does this reference number already belong to another order? Has the order changed since the draft? Asking twice returns the first answer. It never creates a second order.
- Four separate safeguards make a repeated request harmless. Asking for the same change twice returns the outcome already recorded. Drafting the same request twice returns the same draft, not a second plan, and a reused reference on a different request is refused. Before creating anything, the system looks up the reference number in the warehouse and stops if it already belongs to someone else's order. And if the order has changed since the draft, the change fails rather than overwriting the newer version.
- Incoming warehouse notifications are handled by a separate program. It checks each notification's signature against the vendor's published key, drops repeats, and adds the rest to a log. It is separate because the vendor needs a public web address that answers within three seconds, while the assistant's connection usually runs on a local machine that nothing outside can reach.
- The damage any one change can do is capped: 200 lines and 10,000 units at most. A draft expires after fifteen minutes. Every request, refusal and change goes into a log that can only be added to. It records who asked, what they were shown, what was sent and what came back.
- Fifteen named failure messages, so a problem is something the assistant can read and act on rather than a crash. One of them covers a connection lost part-way through a change. It marks the change and forces a lookup by reference number before anything else happens. The system never simply tries again and hopes.
Step one: a drafting command checks and shows the change, tests permission and size caps, and returns a draft reference while writing nothing; the draft expires in fifteen minutes. Step two: the only command that writes takes an approved draft and runs six checks again against live data, asking whether this is a repeat, whose it is, whether the draft expired, whether it is allowed, whether the reference is taken and whether the order has moved on, before writing once and putting the outcome in the log, or refusing by name and returning the outcome already recorded.
03 The figures
What it measured.
Each figure carries the date it was taken. A number without a date is not on this page.
| What was measured | Value | As of |
|---|---|---|
| Parts, only one of them vendor-specific | 5 | 2026-09-18 |
| Commands | 16 — 11 read · 4 draft · 1 changes | 2026-09-18 |
| Checks run again at the moment of the change | 6 | 2026-09-18 |
| Separate safeguards against a repeated request | 4 | 2026-09-18 |
| Named failure messages | 15 | 2026-09-18 |
| Tests passing against the stand-in warehouse | 324, and the code builds clean | 2026-09-18 |
Four things it deliberately will not do
It will not confirm a shipment, confirm a delivery, lift a hold, or change a stock count. Confirming a shipment cannot be undone and moves goods out of the building. Confirming a delivery needs someone who has actually looked at the pallet. A hold is a deliberate stop sign, and only the person who put it there should take it down. And changing stock counts from a chat window is exactly how a stock system stops matching the shelves. Asked to do any of these, the assistant reports what it sees and says why it will not act. That is the answer it is meant to give. It is not a gap to work around.
Everything above was tested against a stand-in warehouse I built from the vendor's public documentation. It copies the real system's messages exactly, can be made to fail on purpose, and sends properly signed notifications. Every behaviour it imitates names the document it came from, and every guess is marked for checking later. That is the strongest thing I can say without a live account, and it is not the same as saying it has run in a real warehouse. The code carries a document listing exactly what is still unproven. I tell a prospect this before they ask.
04 Doing it again
What it would take to do again.
A fit
A system no general connector service covers, or one where each customer must see only their own data and a repeated request must stay safe.
Not a fit
Connecting an assistant to a well-known business app that a general connector service already handles. That is a setup task, not a build.
Up against a constraint like this one?
Thirty minutes, no prep, no pitch. Bring the thing that is slow; if it is not a fit, I say so and point you somewhere useful.