Eleven Agents Over a Multi-Terabyte Document Estate
A large international research programme could no longer find its own engineering knowledge. Eleven Copilot Studio agents, three retrieval modes side by side, and one orchestrator that makes the split invisible.
Project details
- Microsoft Copilot Studio
- Microsoft Teams
- Copilot Connectors
- Graph RAG
- Text-to-SQL
- Dataverse
- Power Automate
The problem
Tens of terabytes of technical documentation, accumulated over decades by a large international scientific research programme, and legacy tools that no longer let engineers find critical information.
This is not a proof of concept on a demo SharePoint. The corpus is the real one, the users are engineers with deadlines, and the failure mode is not a bad answer. It is an engineer giving up and asking a colleague instead.
Three retrieval modes, because there are three questions
The single most consequential design decision was refusing to pick one retrieval architecture. Users ask three different kinds of question, and they do not have the same answer shape:
- "Where is this written?" goes to semantic search through a Copilot Connector over the technical documentation.
- "Explain this to me" goes to Graph RAG over the unstructured documents.
- "How many?" goes to a text-to-SQL agent over the data warehouse.
The user never chooses. The orchestrator does, and it holds no knowledge of its own: its entire value is picking the right specialist and recomposing one answer.
Two questions, two routes
The same orchestrator sends “Where is this written?” to the connector and “How many?” to the text-to-SQL agent. The user never picks.
The hard part was the process, not the search
Alongside the knowledge agents sits a procurement orchestration running across nine coordinated agents, covering request through to payment with multi-step approvals. That is an end-to-end business process, not an FAQ, and it is where most of the engineering time went.
Around it: HR, IT support, quality and audit agents, all narrow by design. A narrow scope means short instructions and a limited source set, which is what makes the answers correct.
Reported outcomes
Figures below are reported by the client on active users, not instrumented telemetry. I would rather say that than present them as measured.
- 2 to 4 hours saved per user per day, reported by the client.
- 5+ business lines covered by pilots: risk, procurement, HR, engineering.
- 11 agents live in Microsoft Teams, where the users already are.
“Thanks to these agents, our staff query the internal databases directly, in seconds.”
Governance was day one, not day ninety
The governance rail runs across the whole architecture rather than being retrofitted: DLP policy per environment and tested, service accounts instead of named credentials, a three-tier ALM sandbox, managed environments, and a decision log recording who decided what and from which source.
On a programme this size the cost moves from the prompt to the governance. That is where agentic programmes fail, and it is the part nobody budgets for at the start.
Graph RAG lost, and we only knew because we measured
Graph RAG turned out to perform worse than connector-based semantic search on this corpus. We measured it against real question sets from real users, not against intuition, then moved most of the search onto the connector.
A RAG architecture is tested against the real corpus. It is not chosen on principle, and it is not chosen because it is the interesting option.
Split before you orchestrate
A generalist agent answers badly. A narrowly scoped agent answers correctly. The orchestrator exists to make that split invisible to the user, and it must itself know nothing: the moment an orchestrator starts holding knowledge, you have rebuilt the generalist you were trying to avoid.
Want to talk about it?
The client is anonymised here. I can talk about the architecture, the retrieval comparison and the governance model in detail without naming anyone.
