For most restaurant operators, supplier ordering runs on memory, habit, and manual email, and one gap in that routine turns into an empty shelf or a rushed substitution before service. The work is not difficult, but it never stops: the same order to the same supplier on the same weekday, then a wait to see whether anyone confirmed it.
Short answer: An AI agent can take the drafting and tracking part of that cycle: writing reorder emails from the par levels and supplier formats you give it, watching the inbox for confirmations, and flagging the ones that never arrive. Nothing reaches a supplier without your explicit approval, because the human confirmation gate on outbound email is mandatory and cannot be skipped. The agent runs on a server you own or rent, so supplier contacts, pricing notes, and order history stay on your own machine.
What you need before you start
- A server that meets the minimum specification. 2 virtual CPU cores, 4 GB RAM, and 20 GB SSD storage is enough when reasoning is routed to an external model gateway such as Anthropic or OpenAI. Linux, Ubuntu or Debian. Running open-weight models locally with no external calls needs substantially more compute, sized to the model weights you choose.
- A dedicated procurement email account. It needs SMTP for sending and IMAP for reading replies. The credentials go into the platform's local secret store, and the agent reaches them through a tool grant. The password itself is never written into the model's prompt.
- Written supplier records. For each supplier: contact email, the item categories and par levels you order from them, and the order format or subject line they expect.
- Linux administration capability, or an integrator. Installation, operating system updates, monitoring, backups, and recovery are the responsibility of the organization running the node. Most operators bring in an integrator for setup and periodic maintenance.
The agent's reorder logic reads par levels from the records you write. It does not query a point of sale or inventory system on its own, so live stock data has to reach it through an integration you configure and enable. This page assumes you supply the par levels as stored reference documents and that the workflow starts on a schedule or when you trigger it.
Steps, in order
- Define the scope in writing. List every supplier email you send in a week and mark whether each one follows a consistent enough format to automate. Give the agent exactly two jobs: draft outbound order emails and track incoming supplier confirmations. Nothing outside that scope receives a tool grant. The result is a one page scope you can hold the agent to.
- Load your supplier directory into Documents. For each supplier, record the contact email, the item categories and par levels, and the expected email format. This is the only reference the agent drafts from. Procurement is one module in a wider operational picture, covered in the overview at AI for restaurants. The result is a directory the agent reads before every draft.
- Connect the procurement email account. Store the SMTP and IMAP credentials in the secret store, then create a tool grant that lets the procurement agent use that one account and nothing else. You end up with an agent that can read and send from a single mailbox, with no reach into any other.
- Build the reorder workflow. Define the sequence in order: check each item against its par level, identify which suppliers need an order, draft the message from that supplier's stored template, then route the draft to you for review. The workflow engine runs the same sequence every time it fires, so a different outcome comes from different data, not from the model improvising. The result is a repeatable sequence you can test and inspect.
- Set the human-in-the-loop gate on the outbound send. Every draft pauses at the gate and waits until you read it and confirm it. Only then does the message leave. This applies to every send, with no exception path.
- Run one supplier through a live cycle. Trigger the workflow manually for a single supplier, read the draft in your approval queue, edit or confirm it, and check that the send appears in the event log. Add suppliers one at a time once a full cycle completes without errors. You end up with a tested loop and a record of every step in it.
Tip: Start with the supplier whose orders are the simplest and most consistent. If the first live cycle fails, you want it to fail on the email plumbing, not on a supplier who uses three formats and a standing special request.
How to check it worked
Four things to look at before you trust the workflow with your full supplier list.
- Event log. Every agent action, the draft, the pause at the gate, your confirmation, and the send, is appended to the event log, which is not rewritten after the fact. If a cycle stops halfway, the last entry is where it stopped.
- Approval queue. Each draft has to appear in your review queue before anything is sent. Drafts that never appear mean the gate is misconfigured, not that the agent is being cautious.
- Task list. A reorder task stays open until a supplier confirmation arrives. Tasks past their expected reply window surface for follow-up.
- Sent folder. Compare the messages in the procurement account's sent folder against the confirmed drafts in the event log. They should match one to one.
What goes wrong and how to tell
The agent drafts from whatever is stored in your supplier Documents. It does not know that a contact left the company, that a price list changed, or that par levels differ for the summer menu unless the record changes too.
Warning: If a contact email, par level, or order format in your Documents is out of date, the draft reflects that error. The human gate will show you the wrong draft before it sends, but it does not correct the underlying record. Update Documents whenever a supplier changes their details.
When a node routes reasoning to an external model gateway, draft generation depends on that gateway being reachable. Your server, stored data, and event log are unaffected by an outage at the provider, but new drafts stop until the connection returns.
Warning: If your node routes reasoning to an external model gateway and that gateway is unreachable, the agent cannot generate new drafts during that window. Your server, stored data, and event log stay intact, but drafting pauses. Keep a manual fallback for procurement deadlines that cannot slip.
Frequently asked questions
Does the agent send orders to my suppliers without me seeing them first?
No. Outbound email passes through a mandatory human-in-the-loop gate. Every draft waits in your approval queue until you read it and confirm it, and the gate has no bypass.
Can the agent watch for supplier reply emails and flag when a confirmation has not come back?
Yes. The email channel monitors the procurement inbox over IMAP. A workflow can match an incoming reply to the open task and close it, or mark the task overdue when the expected reply window passes.
Where are my supplier contacts and order notes stored, and does any of that go to a third party?
They are held in Documents on your own server, inside a single-tenant runtime that you own or rent, not in a shared cloud database. When the agent drafts an order, the text of that request goes to whichever model gateway you configured, under that provider's commercial terms. Stored documents, credentials, and the secret store are not transmitted, and data kept in local storage is never used to train third-party public models.
Can the agent handle suppliers with different ordering schedules?
Yes. Each supplier can be a separate workflow, or a separate step inside a shared workflow, with its own trigger schedule and par level logic.
Do I need someone technical on staff to keep this running?
Not for day-to-day operation: the operator reads drafts and confirms them. Installation and ongoing server care, including operating system updates, monitoring, backups, and recovery, need Linux administration capability, and most operators get that from an integrator rather than hiring for it.
Next step
Review the prerequisites against the machine you plan to use, then run the installation. Set up your node. If you would rather confirm the hardware and access requirements first, the installation runbook lists both.