Sales Order Agent or your own quoting agent — which request goes where?

Sort by the shape of the request, not by the size of your company. Microsoft publishes what its Sales Order Agent handles and — unusually — what it does not, in enough detail to decide before you build anything.

Most requests in a Business Central shop belong to the shipped agent. The ones that do not are identifiable in advance, from your own quote history.

What is the real dividing line?

Whether the answer to the request lives inside Business Central, in the shape the agent works in.

The shipped agent is deeply wired into the ERP — it holds a user account, reads your catalogue, runs your pricing engine, and uses your promising configuration. You cannot rebuild that integration cheaply, and there is no reason to try. Anything replicating it is doing work Microsoft already did.

What a build earns you is the requests the shipped agent is documented not to take. So the question is never "agent or build" in the abstract. It is: what fraction of last quarter's RFQs fall outside the published envelope, and what are those worth?

What does the shipped agent already cover?

The end-to-end capture path, stated as its intended use:

"Taking the customer's order by email. Iterating on the details with the customer via email. Checking the availability of the items. Preparing the sales quote with the requested items. Sending the quote to the customer for approval. Converting the quote to a sales order upon receiving customer confirmation."

That includes multi-turn email conversation, a three-layer item search, availability with capable-to-promise dates, pricing through the standard engine, and human review on every outbound message. It also reads attachments: "PDF attachments must be 20 MB or smaller and contain a maximum of 50 pages."

If your requests are emailed lists of catalogue items, that is the whole job. Build nothing.

Where does a request fall outside the envelope?

Microsoft publishes the boundaries. These are the ones that decide routing, each quoted:

Read that table against your own quote log, not against a feature list. Two of these firing on ten per cent of requests is a workflow question. Two firing on most requests is a different build.

Which of those limits can be engineered around?

This is where the comparison stops being a feature table, because one boundary governs the rest:

"Currently, partners can't extend this capability."

You can see how it thinks — the prompts "are included in the Sales Order Agent source code on GitHub" and "Partners can review these prompts to understand how the agent evaluates messages and matches items." Readable, not modifiable.

Microsoft is also plain that customisation around it is not free of consequence: an agent "can recognize and interact with the custom fields and actions introduced by customizations and ISV solutions", but "the results might vary in quality and should be thoroughly tested", and improving that "might require adjustments to the agent's instructions, which is currently not supported."

So a limit in the table above is a fact to design around, not a backlog item. That is the honest input to the decision, and it is Microsoft's own engineering judgement rather than a criticism of it.

What runs it, and what stops it?

Two operational facts that belong in the comparison because they shape running cost and continuity.

It consumes Copilot Credits. The agent "uses Copilot Credits for AI interactions, which incur charges based on interaction complexity", and a billing model must be set up before use. Microsoft describes what happens at the ceiling:

"When the agent runs out of Copilot Credits, it stops processing new emails but stays active and scheduled. When credits become available again, the agent automatically resumes and processes all unprocessed emails that accumulated during the outage."

It stops and then catches up — worth designing your review capacity around, because the backlog arrives at once.

And its reach has conditions. The feature "uses Microsoft Azure OpenAI Service, which is currently available for Business Central in some geographies", needing admin consent for data movement otherwise; it "was validated and is supported in specific languages only"; and mixed-language input "might result in lower-quality output because the system relies on pure string similarity."

So which request goes where?

The routing rule, and it is ours:

• Emailed, catalogue items, short line count, standard pricing → the shipped agent. It is integrated in ways nothing you build will match, and the review workflow is already there.
• Long schedules, charge or labour lines, variant-decided parts, portal or forwarded intake, negotiated pricing → your own build, running alongside rather than instead. The shipped agent keeps the requests it handles well.
• Anything needing the purchase side or a supplier answer → neither, yet. That is a different surface entirely, and pretending otherwise is how a quoting project acquires a second project.

The two are not rivals, and a shop can run both. One mailbox, one document scope, one set of permissions each — that is the sane arrangement, and it means the decision is per request shape rather than once and forever.

What it is not is a licence to build because building is interesting. That question — when the answer is to build nothing — is the next one, and it is the one worth being hardest about.

The routing decision is answerable from data you already have. Book a 15-minute call and bring last quarter's quote log — we will sort it against the published envelope and tell you what genuinely falls outside, including if the answer is nothing.

Sources

• FAQ for Sales Order Agent — Business Central
• Sales Order Agent overview — Business Central
• Item availability in Sales Order Agent (preview)

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