One orchestrator, three specialist agents for product questions

The situation

The data was already unlocked. A previous project had produced two searchable indexes — ERP article master data with stock, orders and sales, and product content with multilingual copy and document links — along with a backend exposing an endpoint already shaped for connecting an agent.

What was missing was natural-language access. Anyone wanting to know whether an article is available, when replenishment arrives and which safety datasheet belongs to it still had to operate the interface and know where to look. On top of that sat a third source that was in neither index: documents in SharePoint.

The obvious next step was one agent that answers everything.

The approach

What was built instead is a structure of four agents in Copilot Studio.

A parent agent receives the question and decides which expertise it needs. It answers nothing substantive itself — its job is routing and, when the answer comes back, composing it into a single reply.

Beneath it sit three specialist agents, cut along source-system lines:

• one for ERP article data — stock per location, open purchase orders and replenishment, sales
• one for product content — descriptions, classifications, multilingual copy and the linked documents
• one for SharePoint as a knowledge source — documents that live in neither index

The first two do not touch the data warehouse; they call the endpoint the article search already exposed. They therefore inherit its daily index rebuild, its collapsing to one document per article and country — and the field selection that is already decided server-side there.

Where it could have gone the other way

One agent with three knowledge sources would have been the obvious build. The split was made along source systems instead.

Copilot Studio readily allows several knowledge sources to be attached to a single agent. That is the default path, and it has a specific failure mode: the sources compete inside the same context window. A SharePoint presentation mentioning an article and an ERP record for that same article look similarly relevant to the retrieval mechanism — but they are not interchangeable. One is current and structured; the other is a document of unknown vintage.

Splitting them turns that distinction into an architectural decision rather than a retrieval probability. Each specialist has exactly one source, its own instructions, and its own behaviour when it does not know. And they can be evaluated separately: if stock answers are wrong, it is known which agent produced them.

The price is real and belongs in the description. Routing is an extra step that can itself decide wrongly — a question that sounds like product content but needs stock data lands at the wrong agent. And a question spanning two systems requires the parent to query both and merge, where a single agent would simply have had both in context.

The result

Four agents, three connected source systems, no new data storage. The most expensive part of a solution like this — making SAP and product-system data reliably available, daily, in queryable form — was already built and was reused. This project’s effort went into the cut and the routing logic, not into data acquisition.

Read-only by design: no agent writes back to a source system. Ordering, stock transfers and master data maintenance still happen where they belong.

The inherited limits of the data layer apply unchanged and are worth stating: the index is rebuilt once a day, so this is not a real-time availability check, and because it is overwritten on each run no agent can say what changed since yesterday. The SharePoint agent does not have that constraint — but it has the inverse one: it answers from documents whose currency nobody guarantees.