Chasing quotes and vendors without becoming the bottleneck

Buying anything at a company means the same email sequence every time. Ask four suppliers the same question, chase the two who did not reply, translate three different answer formats into something comparable, and keep every commitment somewhere findable. None of it is judgement, all of it is slow, and it is usually done by someone whose actual job is the decision at the end.

1 August 2026 · 5 min read

What is safe to automate here#

The line is unusually clear in procurement, which is what makes it a good use case.

Safe: requesting a quote to a specification you were given, chasing a non-response, asking a clarifying question, collecting documents, confirming receipt, and normalising answers into a table.

Not safe: choosing a supplier, negotiating price, agreeing terms, accepting a contract, or saying anything that could be read as acceptance of an offer. Those are commitments, and an email can create one.

That last point deserves emphasis, because it is a legal difference rather than a stylistic one. An agent that replies "that works for us" to a priced offer has done something with consequences. Keep every word of acceptance with a person, and make the agent's tools incapable of it rather than merely instructed against it.

The loop#

1. Send the same question to each supplier. Separate threads, not a group message. Five recipients per message is the cap anyway, and separate threads mean each supplier's replies stay their own conversation.
2. Wait. wait_for_reply with a timeout matched to the request: a day or two for a simple price, a week for anything requiring an engineer.
3. Chase once. One follow-up, then stop and tell the human who did not answer. A supplier who ignores two emails is telling you something useful about working with them.
4. Normalise. Pull the numbers and terms out of each reply into one structure: price, lead time, minimum order, validity date, what is excluded.
5. Hand over a comparison, not a recommendation. The agent presents; the person decides.

send_email  { to: ["sales@supplier-a.com"], subject: "Quote request: 500 units, delivery week 34" }
wait_for_reply { thread_id: "thr_...", timeout_seconds: 172800 }
remember_about_contact { contact_id: "con_...", fact: "Quotes exclude freight by default." }

That last call is worth more than it looks. Supplier quirks are exactly the knowledge that lives in one person's head and leaves when they do, and recording them per contact is how the second round of quotes goes faster than the first, per giving an email agent memory.

The sell side of the same conversation, where the agent must never put a number on anything, is in quote requests that arrive while you are on a roof.

Attachments are the medium here#

Procurement runs on documents: quotes as PDFs, specifications, certificates, signed terms. The agent should fetch based on metadata rather than reflexively, extract the fields it needs, and forward the original intact when a person needs it.

forward_email in wrapped mode keeps the headers and attachments as they arrived, which matters when the recipient is finance or legal and needs the actual document rather than a summary of it. The safety rules, including treating extracted document text as untrusted input, are in attachments.

The fraud shape to design against#

Procurement is the most targeted email surface in most companies, because the payoff is a redirected payment. Two rules, both structural.

A request to change bank or payment details is always escalated and never actioned. No exceptions, no matter how convincing the thread looks. Verification happens out of band, by a person, using a number they already had.

A supplier writing from a new domain is a flag, not a fact. Lookalike domains are a registration away, and a thread that suddenly continues from a slightly different address deserves a human eye. This is where the alerting in what to monitor in production earns its place, and where the injection defences in prompt injection by email apply directly: the message body is not evidence about who sent it.

Where it fits alongside your systems#

The purchase order lives in your ERP or finance system, and it stays there. The agent handles the correspondence around it, writes outcomes back, and keeps every commitment attached to a thread anyone can read later.

That last property is the quiet benefit. Procurement disputes are almost always about what was agreed in an email six months ago, and a per-identity audit trail with the whole thread in it turns that from an argument into a lookup.

Starting narrow#

One category, one supplier group, one week of reading every thread. Repeat quote requests for a commodity item are the usual first choice: the specification is stable, the answers are comparable, and the worst realistic failure is a price you have to ask for again. The day-by-day version is in the first week with an email agent.

Questions#

Can an AI agent handle procurement email?

Yes, for the coordination: sending the same request to several suppliers, chasing non-responses, collecting documents, and normalising answers into a comparable set. Selection, negotiation, and acceptance stay with a person.

Why can it not negotiate?

Because email can create a commitment. An agent replying "that works" to a priced offer may have accepted it. Keep acceptance language with a human and make the tools incapable of it.

Should it email all suppliers at once?

No. Separate threads per supplier keep each conversation its own, and the recipient cap is five per message in any case.

How many times should it chase?

Once, then report the non-response to a person. A supplier ignoring two emails is information worth acting on rather than automating around.

What about requests to change bank details?

Always escalate, never action, and verify out of band using a number you already had. This is the most common fraud shape in procurement email.

Does it replace our purchasing system?

No. The purchase order stays in your ERP. The agent handles the correspondence around it and writes outcomes back, leaving a readable thread for every commitment.