Supplier emails arrive continuously, and a missed short delivery notice or an unacknowledged price change can cost margin before you have had time to read the thread. Using AI for restaurant supplier chats does not take you out of that loop. It moves your work from writing the replies to approving them.
Short answer: An AI agent running on your own server can read incoming supplier messages, compare them against your stored order records, and draft a reply. The draft is held at an approval gate; nothing is sent to a supplier until you confirm it. Your email credentials stay in a local secret store on that server and are never passed into the model prompt.
How supplier-chat AI works
An agent connects to your supplier email account over standard email protocols: IMAP for inbound messages, SMTP for outbound. The login credentials live in a secret store on your own server. When the agent needs one, it resolves the reference locally over a Unix domain socket under a strict allowlist, so the password itself is never placed in the model's context. The agent also runs as its own isolated process with a declared set of tool grants, which means a second agent on the same node cannot reach that mailbox or those credentials.
When a message arrives, the agent reads it and checks it against the order Documents you have stored on the node: standing orders, agreed prices, delivery schedules. It then drafts a reply from those records and the instructions you gave it. The draft does not go anywhere yet. Outbound email is one of the actions held behind a human-in-the-loop gate, so the message waits in a queue until you confirm or edit it.
Every step is written to an append-only event log on your server: the message received, the Document referenced, the draft created, your approval or rejection, and the send. Nothing in that sequence is rewritten after the fact, which is what makes the log worth reading when a discrepancy turns into a disagreement three weeks later.
One boundary is worth knowing before you plan hardware. If your node routes reasoning to an external model gateway, the context of that request, meaning the message text and the order details the agent is working with, travels to that provider under its commercial zero retention API policies. Credentials still do not leave. If you need message content to stay on your machine as well, that means local model weights and compute sized for them.
Supplier communication is one component of a broader set of AI tools for restaurant operations; the full picture is at AI for restaurants.
| Stage | What happens |
|---|---|
| Receive | Agent reads the incoming supplier message via email |
| Match | Agent checks your stored order Documents |
| Draft | Agent prepares a reply |
| Review | Draft is queued; nothing is sent yet |
| Confirm | You approve or edit, then the message goes out |
| Log | The full sequence is written to the event log |
A worked example
The restaurant keeps a standing order for 24 cases of roma tomatoes as a Document on the node. On Tuesday the supplier sends a delivery confirmation for 18 cases.
The agent reads the confirmation, retrieves the standing order, and finds a shortfall of 6 cases. It drafts a discrepancy notice that cites both numbers: 24 ordered, 18 delivered. The draft is queued for review next to the original incoming message and the order Document it was built from, so you can verify the comparison in a few seconds instead of reconstructing it from the thread.
You read the draft, change the wording if you want, and confirm. Only then does the message leave your server. The event log now holds one unbroken sequence: message received, Document referenced, draft created, human confirmation received, outbound message sent. If the supplier disputes the claim later, that sequence is the record.
Steps to set this up
The base node needs a Linux host (Ubuntu or Debian) with at least 2 vCPU, 4 GB RAM and 20 GB SSD when remote model gateways do the reasoning; running local weights instead needs dedicated CPU or GPU capacity sized to the model. The steps below assume you can administer that host, or that an integrator does it for you.
- Connect your supplier email account. Give the node the IMAP and SMTP credentials for the mailbox. It stores them in the local secret store, and the agent receives a scoped reference rather than the password. You now have an agent that can read and hold supplier mail.
- Store your standing orders and current price agreements as Documents on the node. These are the records the agent checks each incoming message against. You now have a reference set instead of a memory.
- Define which message types the agent handles. Start with delivery confirmations, quantity acknowledgments and invoice queries. Anything outside that list stays with you. You now have a bounded scope you can widen once you trust it.
- Configure the approval gate for outbound messages. This is a required step, not an optional setting. You now know that no supplier receives anything without your explicit confirmation.
- Run a test on a low-stakes message. Take a routine acknowledgment, let the agent draft it, and complete the cycle through approval and send. You now have evidence that the draft-and-approve loop works before any live thread depends on it.
Common mistakes
Two operational failures account for most bad drafts in this setup: records that have gone stale, and scope that has crept wider than the agent can verify.
Warning: If the Documents you stored at setup are not kept current, the agent compares incoming messages against outdated quantities or expired prices and produces incorrect drafts. Treat your order Documents as live operational records that must be updated when terms change, not a one-time configuration step.
Stale records are the failure a calendar reminder fixes. Scope creep is the one that hides in the middle of a thread. The agent operates within a declared scope: it drafts responses to message types you defined, where your stored Documents give it a clear reference. Committing to new pricing, accepting revised contract terms, or approving a credit claim sits outside that scope. When a message asks for one of those, the agent holds it for your decision rather than drafting an answer, and the thread waits until you pick it up. That is the intended behavior, and it is worth telling suppliers what to expect.
Frequently asked questions
Will the agent send emails to my suppliers without me seeing them first?
No. Outbound email is one of the actions held behind a human-in-the-loop gate, which is mandatory for messages that leave your server. The agent can prepare a draft, but the send waits until you confirm it. Your confirmation or rejection is written to the event log alongside the draft.
Where are my email login details stored, and does the AI model see them?
They stay in the local secret store on your server, and they are never injected into model prompts. The agent resolves a secret reference locally under a strict allowlist; the password itself does not enter the context. Message content is a separate matter: if your node routes reasoning to an external model gateway, that request's payload travels to the provider under its commercial API terms, and the credential does not travel with it.
Can I connect more than one supplier account?
Yes. Agents are separate processes on the same node, so you can run one per supplier account and keep their mailboxes and tool grants apart. One agent's credentials are not reachable from another agent's scope. The practical limit is your own review time, because every outbound message still passes a gate that only you clear.
What happens if the agent receives a message it does not recognise or cannot match to any stored order?
It holds the message for you. Without a Document to compare against, the agent has no grounds to draft a substantive reply, so the message is queued with no outbound answer attached. Price changes, new terms and unusual claims usually arrive this way, and they are exactly the messages you should be reading yourself.
Is there a record of everything the agent did with a supplier message?
Yes. The event log is append-only and lives on your server. It captures the inbound message, the Documents the agent referenced, the draft it created, your confirmation or rejection, and the outbound send. Entries are not edited after they are written.
Does this require a dedicated server, or can it run on a standard VPS?
A standard Linux VPS is enough for the base node: 2 vCPU, 4 GB RAM and 20 GB SSD when remote model gateways handle the reasoning. Running local model weights instead of calling an external gateway needs dedicated CPU or GPU capacity sized to the model you choose. Either way the machine is yours, which means host security, OS updates, backups and recovery are your responsibility or your integrator's.
Where to go next
If you want supplier drafts arriving in your own approval queue, the next step is to stand up a node and connect one account: Set up your node. To see the components before committing, the overview is at what you get, and host prerequisites and the installation sequence are in the installation runbook. One node serves the whole team, with no per seat licensing.