Yes, for three specific jobs. An AI agent can keep reorder points current from the transactions the system already records, run the discipline around cycle counts (opening them, chasing them, reconciling the results), and prepare supplier orders from a low-stock report. Those are the jobs that drift when a person is interrupted, and they are the ones worth handing over first.
Spending is the boundary. An agent should place orders only within a limit the system enforces, exactly as a junior buyer works to an authority, and should stop and ask when an order is above that limit or looks unusual. The safety comes from the software holding the line, not from the model remembering to behave.
Monday morning in a small stockroom
The shelf says twelve. The system says thirty. The supplier order that should have gone out on Thursday is still a draft, because the person who raises it was covering dispatch. None of this is a software failure in the usual sense. What failed is the upkeep: three small jobs that have to be done continuously for the numbers to mean anything, and that nobody is paid to do continuously.
Those three jobs are most of inventory management for a small or mid-sized operation: keep the stock figure true, know when to reorder, and place the order. Each one is routine, each one is interrupted by whatever else is happening on the floor, and each one drifts when it is interrupted. That drift is where AI agents for inventory management earn their keep, and the useful question is which of the three jobs an agent can hold on its own and where it has to stop and ask.
Reorder points: easy maths, constant upkeep
The standard rule is not complicated. A reorder point is the stock level that triggers replenishment, calculated as the expected consumption during the supplier's lead time plus a safety stock held against variation in demand or delivery. If an item sells twenty a week, the supplier takes two weeks, and you keep a week's worth in reserve, the reorder point is sixty. Any textbook on stock control gives the same formula.
The difficulty is that every input moves. Lead time changes when the supplier changes carrier or loses a warehouse. Weekly demand changes with the season, a new customer, or a product that quietly stops selling. Safety stock should move with both. In most businesses the reorder point was set once, when the product was created, and has not been revisited since. The rule is fine; the inputs are stale.
This is the first job an agent can hold, because the inputs already exist in the system as a by-product of other work. Every goods receipt records when an order was placed and when it arrived, which gives lead time. Every dispatch and sale records demand. An agent with read access to stock transactions can recompute the reorder point for each item on a schedule, flag the ones that have drifted beyond a tolerance you set, and propose the new figure. Whether it may change the figure itself is a permission decision; a sensible first setting is that it proposes and a person accepts.
Counts and discrepancies
The second job is keeping the stock figure true. A full annual count is expensive, closes the operation for a day, and is already wrong by the time it finishes. Cycle counting, a few locations or items per day on a rota, is the method most operations settle on and the one most operations let slip, because the rota has no owner once the person who set it up moves on.
An agent is well suited to the rota, not the counting. It can open a count for the locations due today, assign it to whoever is on shift, chase it if the results are not in by mid-afternoon, compare the result with the system figure, post the adjustment for small variances, and raise the large ones as a task for a person with the transaction history attached. The count itself still needs someone with a scanner or a clipboard standing in front of the shelf. The discipline around it, which is the part that actually fails, is administrative and can be delegated.
The threshold matters. A variance of two units on a low-value item can be adjusted and noted. A variance of forty on something that costs $230.00 a unit should not be adjusted by anyone, agent or person, without a second look, because it usually means a receipt was never booked or something has left the building. Set the threshold explicitly, as a number the agent's adjustment tool is scoped to. An agent that is told the rule follows it every time; a person covering dispatch does not.
Purchase orders: how the agent asks before spending
The third job is the one people worry about, because it commits money. The answer is that an agent should prepare orders freely and place them only within an authority it has been given, the way a junior buyer works. Below the limit it sends. Above it, or when anything about the order is unusual (a supplier it has not ordered from before, a quantity far outside the usual, a price that has moved), it stops and asks. Here is what that looks like as one request, run against a workspace with the stock and supplier records in it, with an approval limit already set on the agent's connection.
- Reading stock levels against reorder points
- Three items below reorder point, all supplied by Northwind
- Order drafted from supplier defaults and current lead time
- Total is above your approval limit, holding it for your decision
The agent used the stock, supplier and task tools it was allowed to use. It did not send the order, because the total was above the limit set on that connection. Once the person approves, it sends the order and books the expected goods receipt so the delivery can be checked in against it.
Two things make that safe rather than merely reassuring. The first is that the limit is enforced by the system, not remembered by the model: the connection the agent uses has a spend cap and a fixed set of tools it may call, and placing an order above the cap fails whatever the agent intended. The second is that the approval creates a record. The person who approved, the time, and the draft they saw are logged alongside the tool calls, so the audit trail for an order placed by an agent is at least as complete as the one for an order placed by hand, and usually more so.
Which inventory tasks to hand over
| Task | The agent can own | A person keeps | What the software has to expose |
|---|---|---|---|
| Recalculating reorder points | Yes, on a schedule, proposing changes | Sign-off on large changes | Transaction history, goods receipts and stock levels as callable tools |
| Low-stock monitoring | Yes, continuously | Nothing routine | A low-stock query that carries the supplier on each item |
| The cycle count rota | Opening, assigning, chasing, reconciling | The physical count | Count start, record and discrepancy tools |
| Small variance adjustments | Yes, below a threshold | Large variances, always | An adjustment tool scoped to the user's permission and the threshold |
| Drafting supplier orders | Yes | Nothing routine | Supplier defaults, item lead times, open orders |
| Placing supplier orders | Below a spend limit | Above it, and anything unusual | A spend cap enforced per connection, with a log |
| Receiving goods | Booking the receipt against the order | Checking the delivery at the door | A receive tool that references the order |
The right-hand column is the test to run on any inventory system. If a task's tools are not there, the agent cannot own it, however capable the model.
What the software underneath has to provide
Everything above depends on the inventory system exposing its work as actions an agent can call, rather than screens the agent would have to drive. Four things have to be true. Every action (query stock, start a count, book a receipt, draft an order) is a named tool with defined inputs. Each tool is offered and run under the permissions of the person the agent represents, so an agent acting for the stockroom lead cannot approve an order the stockroom lead could not. Spend is capped where money is committed. And every call is logged with its inputs and its result.
In Sois that is how the warehouse module is built. A workspace is an MCP server, and the stock tools are named for what they do: getLowStock, getStockSummary, startStockCount, getStockDiscrepancies, receiveStock, manageGoodsReceipt, with the supplier side in accounting alongside purchase invoices. You connect the agent you already use, Claude, ChatGPT or any MCP client, by adding the workspace address and signing in once; there is no token to paste. Tools are filtered by your role before the agent sees them and checked again when they run, a spend limit is set per integration, and every action is traceable afterwards. When your own agent does the reasoning, Sois performs no AI on your behalf and charges nothing for it.
- Get the record straightItems, suppliers, lead times and locations in the system, not beside it. Two weeks of clean receipts and dispatches is enough to start.
- Give the agent read access firstLet it recompute reorder points and report the drift for a fortnight. Check its proposals against what you know.
- Set the thresholdsA variance it may adjust, a spend it may commit, both as numbers the system enforces rather than instructions the model follows.
- Widen the scopeLet it draft orders, then send within the limit, then run the count rota. Read the log each week until you stop finding anything.
Read before write, propose before change, a limit before any spend. Followed in that order, the result is an agent that keeps the stock figure honest, says what needs ordering before it runs out, and asks for a decision only when the decision is genuinely yours.
Questions people ask
Can an AI agent place purchase orders on its own?
Within a limit, yes. Give the agent's connection a spend cap enforced by the system and let it send orders below it. Above the cap, or for anything unusual such as a new supplier or an unusual quantity, it should prepare the order and ask. The cap has to live in the software, not in the agent's instructions.
Does the agent replace barcode scanners or the physical count?
No. Someone still has to stand at the shelf and count, with a scanner or a clipboard. The agent owns the rota around the count: opening it, assigning it, chasing it, reconciling the result and posting small adjustments. That administrative discipline is what usually lapses.
How does the agent know the supplier's lead time?
From the goods receipts. Each receipt carries the date the order was placed and the date it arrived, so the agent can recompute lead time per supplier and per item as deliveries land, and feed that into the reorder point. If receipts are not being booked against orders, that is the first thing to fix.
What if the stock figures in the system are already wrong?
Start with the count rota rather than the reorder points. Let the agent run cycle counts across every location once, raise the large discrepancies for a person to investigate, and post the small ones. Only when the figure is trustworthy is a reorder point calculated from it worth acting on.
- Reorder point (Wikipedia) the standard definition: consumption during lead time plus safety stock
- Sois documentation: the workspace MCP server the warehouse and accounting tool names, permission filtering, budget caps and logging as implemented
- Model Context Protocol specification: tools how tools are listed and called, and the requirement for access controls, input validation and a human able to deny a call
- Sois: security and the permission layer permissions enforced when tools are offered and again when they run, spend limits per integration, traceable agent activity
This article is reviewed when the products it describes change. Next scheduled review: December 4, 2026.