The RFQ agent, end to end: Microsoft's flagship Dynamics 365 demo — and what it takes to run it on your data

If you've seen Microsoft demo agentic ERP for Dynamics 365 recently, you've probably seen the RFQ agent. It's the flagship, and it's genuinely impressive — because it's not a chatbot answering a question, it's an agent doing a multi-step procurement job end to end.

Worth understanding exactly what it does, because it's the shape of the demo every D365 buyer is now being shown — and then worth being honest about the gap between the demo and your actual estate, because that gap is the whole project.

What the demo does, step by step

The agent runs the request-for-quote process from intake to a drafted purchase order:

1. Pulls the context from Dynamics 365 — the RFQ lines, the vendors, and the scoring criteria, straight from the ERP.
2. Reads the vendor responses in Outlook — including the emails and the PDF attachments where the real numbers usually live.
3. Flags discrepancies — where a vendor's response doesn't match what was asked, or the lines don't reconcile.
4. Scores the bids against the criteria.
5. Writes a recommendation — a reasoned summary of which vendor and why.
6. Waits for a person to approve. Only then does it create the purchase order and draft the award email.

That last step is the important one, and it's the right design: the agent does the heavy, tedious, cross-system legwork; a human approves before anything irreversible happens. Operate by exception, with a person on the irreversible call.

Why the demo is clean and your estate isn't

The demo works beautifully because the demo environment is standard and tidy. Yours isn't, and the gap is in four specific places:

• Your scoring criteria are yours. A real procurement team doesn't score on price alone — it weighs lead time, supplier risk, contract terms, past performance. Encoding your scoring logic, not a generic one, is work. (This is where business skills come in: your procedure, codified.)
• Your vendor and item data is customized. The RFQ lines, the vendor master, the custom fields your business added — the agent has to read your data model, including the X++ and ISV customizations a generic agent can't reach. (The fix: governed MCP Action tools.)
• Your approval chain is specific. Who approves what, at which threshold, in which legal entity — that's your routing, not the demo's single approve button.
• Your governance has to hold. The agent is acting with real permissions on real money. Approval before posting, segregation of duties, and every action traced to the instruction and the record are not optional in procurement. (See the agent governance gap.)

None of this makes the RFQ agent a bad idea. It makes it a build — the demo shows the destination, and the four items above are the road to it on your estate.

The honest version of "can we have that?"

Yes — and the fastest path is usually not "build the whole RFQ agent from scratch." It's: start from Microsoft's platform and first-party capability where it fits, then do the specific work that makes it run on your data — your scoring logic as a skill, your customizations as governed actions, your approval chain, your audit trail. The demo is the standard version; the value is making it true for your procurement, with the controls your finance team will insist on.

It's the same shape as what we build for quoting on the sell side — Quote Rabbit reads a messy request, matches it to the customer's own Business Central catalogue, prices it, and flags the judgement lines, with a person always pressing send. The RFQ agent is that discipline pointed at the buy side.

If you've seen the demo and want to know what it would take to run it on your procurement, tell us how your RFQ-to-PO process actually works today — including the exceptions, because that's where the real build is.