An agent reads the request, identifies the customer, matches each line and prices it. What it does with the lines it cannot resolve is the real engineering.
Ordered by chapter. Each post stands alone but builds on the one before it.
Three layers in order: exact identifier, then attributes, then global fuzzy search. Microsoft documents all three, and the third runs on the hardest lines.
A quantity error produces a document that looks completely normal. Microsoft documents its agent returning 2,000 grams for 2 kilograms, and a price of zero.
It should say so, at zero, with the customer's own words attached. Microsoft documents its agent returning a washing machine for washing powder it cannot find.
It can produce the document but not the price. The agent resolves identity from the email address alone and is designed not to discuss discounts at all.
It reads and writes as a named user, not through an API. It holds permission sets, works only on quotes and orders, creates no master data, and posts nothing.
Microsoft's agent never contacts a supplier. It computes a promised date from capable-to-promise setup, so it is only as good as the lead-time fields behind it.
Microsoft's agent handles the shape it was built for and its limits are published. The dividing line is your RFQs: line count, line types, where answers live.
Four cases where the honest answer is to build nothing: the shipped agent covers it, the catalogue cannot support matching, or quoting is not the bottleneck.