Can an AI agent price a quote line without knowing the customer?

No — and the interesting part is that it will still produce the document. In Business Central a price is not a number attached to an item. It is the output of a calculation whose inputs include who is asking. Remove the customer and the calculation still runs; it just stops describing the deal you actually have with that company.

So an agent that has not resolved identity does not fail loudly. It produces a quote that looks finished, at prices nobody agreed.

Why is the customer an input to the price rather than a label on it?

Because Microsoft's own pricing path says so. The item-availability page [PRP] describes how the Unit Price Including Discount field is produced:

"Shows the item's calculated price for the specific customer, date, and quantity. The agent creates a temporary sales document behind the scenes and applies Business Central's standard pricing engine, including customer price groups, customer discount groups, and line discount rules."

Three of those four inputs — price groups, discount groups, line discount rules — are keyed to the customer. The fourth, quantity, is keyed to the request.

Microsoft then states the consequence in one sentence, and it is the sentence to keep:

"The result reflects the actual price the customer would see on a quote, not the list price from the item card."

The gap between those two prices is the customer. In distribution that gap is the whole commercial relationship, and it is not small.

How does the agent establish who is asking?

From one field, deliberately. The Sales Order Agent overview carries this as a Note:

"For security, the agent identifies contacts exclusively by matching the sender's email address to the E-Mail field on contact cards. It doesn't search by contact name, company name, or other fields when establishing the security context. This restriction prevents unauthorized parties from impersonating a customer by using a similar name."

Read that as engineering rather than as a limitation. Name matching is the obvious approach and Microsoft rejected it on purpose: a fuzzy match on a company name is an impersonation route, because two names can be made similar and an email address has to be controlled.

The cost of that choice is stated on the same page. If the address does not match, the contact does not exist as far as the agent is concerned:

"If you can see a contact in your contact list but the agent reports it as not found, check whether the contact's E-Mail field matches the address the customer sent from."

Which makes your contact records a pricing dependency. Microsoft says it plainly: "Contacts without an email address, or with an outdated address, aren't matched when the customer sends a request."

What happens when the request arrives forwarded?

It resolves to the wrong person, and Microsoft documents this specifically:

"When you forward an email to the agent's mailbox, the agent uses the forwarder's email address (not the original sender's) for contact lookup. If an internal team member forwards a customer's email, the agent doesn't automatically identify the customer."

This is worth sitting with, because forwarding is how requests move inside a small distributor. A rep gets an enquiry on their own address and pushes it to the shared mailbox. The agent then resolves the identity of the rep.

Microsoft provides the recovery. When no contact is matched, the incoming-message review page offers three routes — "Create a new contact", "Use another contact once", and "Update an existing contact's email" — and names which one this case needs: "use the Use another contact once option to manually link the correct customer contact to the task." Microsoft notes it changes nothing permanent, and that "Future emails from the same address still show as unregistered."

So the forwarded request is a recurring manual step, not a one-off correction. Worth knowing before you design a mailbox around forwarding.

Can it quote someone who is not a customer at all?

Yes, and this is the case to design for rather than assume away. The overview sets out what happens once a contact is matched, and the second branch is the one that matters:

"If a contact is found but it's not a customer, the agent filters to use only documents belonging to the contact. Quotes can be sent to contacts that aren't registered as a customer."

A quote goes out. But a contact who is not a customer has no customer price group and no customer discount group, because those live on the customer record. The pricing engine runs with its customer-keyed inputs empty — and the number it produces is closer to the list price the previous section said it was not supposed to be.

Nothing is broken. Every component behaved correctly. The document is simply priced for a relationship that does not exist yet, and it looks exactly like a document priced for one that does.

This is the same failure shape as a line that matched nothing: the loud failure is cheap, and the confident one is not.

Will the agent negotiate a discount if the customer asks?

No, by three separate mechanisms, and the layering is the point.

It is filtered before processing. The relevance model that screens inbound mail "filters out offers to sell, discount requests, or attempts to access internal data."

It is excluded by design. The FAQ is explicit, and gives the reason first:

"Business Central has an advanced price/discount calculation logic, often extended by ISV solutions. Therefore, the most reliable way to get the item price is to create a sales document—for example, a quote. For this reason, the agent is designed not to provide or update any pricing and discount information by email. Requests for changing discounts and pricing aren't accepted by the agent. Instead, they're surfaced to the users for applying them manually."

And it is tested for. Microsoft's published test suite lists a Safety & guardrails category covering "Prevention of unauthorized promises (discounts, services)".

Three layers to enforce one boundary: the agent transports the price the ERP calculated and never authors one. That is the correct boundary, and any quoting agent worth building keeps it.

What does this mean for anything you build?

Resolve identity as a gate, not as a step. Everything downstream — the price, which documents are in scope, whether a discount applies — depends on it, so an unresolved identity has to stop the quote rather than colour it.

Three engineering positions follow, and they are ours rather than Microsoft's:

• An unresolved sender produces no priced document. Produce the matched lines, produce no numbers. A quote with prices is a commercial statement and it needs a party.
• State the pricing basis on the quote itself. If the numbers came out without a customer price group, the document should say which basis it used. A reviewer cannot see an empty input.
• Make the identity match visible to the reviewer, including which address matched. That is the one check that catches a forwarded request before it becomes a sent quote.

None of this is exotic. It is the ordinary discipline of treating identity as the thing the price hangs off, which is what Business Central's own pricing engine already assumes.

If your quote prices depend on who is asking, the identity step is where a build gets this right or wrong. Book a 15-minute call and bring the way requests actually reach you — forwarded, shared mailbox, or straight from the buyer. We will tell you what that does to the pricing.

Sources

• Sales Order Agent overview — Business Central
• Item availability in Sales Order Agent (preview)
• FAQ for Sales Order Agent — Business Central
• Process sales quotes and orders with Sales Order Agent

This article is part of our work on the RFQ quoting engine.