Problem statement

In wholesale scenarios, the Item No. is often only an internal system identifier.

Customers, sales, and purchasing primarily work with:

• Manufacturer Code
• Manufacturer Item No.

In our solution, the Item table is extended with:

• Manufacturer Code
• Manufacturer Item No.

The Sales Line is also extended accordingly.

For our customers, the combination of Manufacturer Code + Manufacturer Item No. is the business‑relevant key, while the internal Item No. is irrelevant.

Current limitation

We attempted to surface this information in the “SOA Multi Items Availability” page.

However:

• The page is not extensible
• We therefore added it via customizations to the Sales Order Agent role center
• Despite this, the Sales Order Agent does not understand or use this information

Example user request the agent fails to handle correctly:

Hello, I require a quotation for a lamp with the manufacturer part number 2721 from manufacturer BOSCH.

The agent appears to rely strictly on Item No.‑based logic and ignores manufacturer‑based identification, even though this data is available in the system.

Assumed root cause

The Sales Order Agent likely operates with strict internal rules and a fixed prompt, defining:

• Which tables
• Which fields
• Which identifiers

are considered during interpretation and execution.

Since:

• The prompt is not visible
• The agent cannot be extended
• Prompt events are not exposed, even with Agent Playground enabled

there is currently no way to teach the agent that Manufacturer Code + Manufacturer Item No. is a valid and primary item identifier in wholesale scenarios.

Requested improvements / ideas

1. Extensibility of the Sales Order Agent

• Allow partners and ISVs to extend:
• Recognized identifiers
• Field mappings
• Item resolution logic

2. Prompt visibility or extension hooks

• Similar to Agent Playground, but for system agents
• At least allow registering:
• Additional semantic keys
• Alternate item lookup rules

3. Ability to clone the Sales Order Agent

• Copy the default agent
• Customize the prompt and behavior
• Keep access to:
• Mailboxes
• Sales documents
• Business Central context

4. Mailbox access for custom agents

• Currently, custom Agent Playground agents cannot access mailboxes
• This is a blocker if the default agent cannot be extended

Business value

Without this extensibility:

• Wholesale customers cannot use the Sales Order Agent effectively
• Real‑world item identification (manufacturer‑based) is ignored
• Partners are forced into fragile workarounds or cannot adopt the agent at all

Making the Sales Order Agent extensible would significantly increase its adoption, accuracy, and industry relevance, especially in wholesale and manufacturing scenarios.

Technical context & reasoning (additional, optional section)

This part is not part of the idea text, but helps explain why your assumption is very likely correct:

• The Sales Order Agent is almost certainly:
• Prompt‑driven
• Backed by fixed semantic mappings
• Restricted to a known schema (Item No., Variant, etc.)
• If Manufacturer Item No. is not part of:
• The retrieval schema, or
• The tool function definitions
• then the LLM literally cannot reason with it, even if it exists on pages.
• UI customizations alone don’t help, because:
• Agents operate on data contracts, not UI
• Non‑extensible pages = non‑extensible agent context

Your proposal is therefore architecturally sound and not a misunderstanding.