Copilot Studio Agent Suite

Executive Summary

Five Copilot Studio agents I designed, built and shipped are in production use every working day, covering helpdesk, sales, procurement, reporting and security. They are not pilots or demos. People open them instead of raising a ticket, hunting through a record, or interrupting a colleague.

They share one architecture. Every agent grounds its answers in real business data rather than in whatever the model happens to know, reasons over the request in the user's own words, and where it needs to change something, acts through a narrow set of operations that are defined in advance, permissioned, and logged. The model never writes to the database directly, not once, anywhere in the suite.

The Problem

The knowledge people needed was already in the business. It was just in places that required you to learn a system before you could get an answer: documentation nobody had time to read, Dataverse records behind forms and views that take training to navigate, and Power BI reports behind a filter pane. Every one of those is a toll booth between a simple question and its answer.

The obvious response, put a chat box on it, is also the easy way to build something worse than what you had. The failure mode of a bad business agent is not that it is unhelpful. It is that it is confidently wrong, because it answered from the model's general knowledge instead of your data; or that it quietly changed a record it should never have been able to touch.

So the design problem was never "can an agent answer this". It was: how do you make an agent that is only ever able to answer from what is actually true here, and only ever able to do the small number of things it is supposed to be able to do?

The Five Agents

Each agent owns one domain, with its own grounding sources and its own action surface. Keeping them separate is deliberate: a single do-everything agent has the union of every permission and every failure mode.

• Helpdesk. Grounded on internal documentation plus Dataverse. It answers "how do I" and "what is the process for" from the material the business has actually written down, and when the answer depends on a specific record, it looks the record up rather than generalising.
• Sales / CRM. The one that takes actions. It reads from Dataverse to answer questions about accounts and opportunities, and it writes back through Power Automate, updating records on request rather than making the user find the form.
• Procurement. Handles supplier and purchasing questions, so the routine "who do we buy this from, and what did we agree" traffic stops landing in someone's inbox.
• Reporting. Surfaces Power BI data conversationally. A question in plain English comes back as the number, instead of the user learning which report and which slicer combination produces it.
• Security. Triages security questions and reports, answers the routine ones, and escalates anything that looks like a genuine incident to a human. It is explicitly not allowed to close the loop by itself.

The Agent Pattern

Every agent in the suite runs the same three-stage pattern. Naming it made the suite maintainable; adding the fifth agent was mostly a matter of deciding what went into each stage.

• Retrieve. Pull from grounded sources: curated internal documentation, Dataverse records, Power BI datasets. Retrieval is scoped per agent, so an agent physically cannot answer from outside its own remit. If nothing relevant comes back, the correct behaviour is to say so, not to improvise.
• Reason. Interpret what the user actually asked, in their words, against what came back. This is the only stage where the model has real latitude, and it is deliberately the stage with no side effects.
• Act. Where a change is needed, invoke one of a small number of predefined operations. Each one is a Power Automate flow with a fixed contract: known inputs, validated, permissioned, and logged. The agent chooses which action to call and with what arguments, it does not get to invent an action.

The important property is that the blast radius of a reasoning mistake is bounded by the action surface, not by the model's creativity. A confused agent calls the wrong flow and fails a validation check. It cannot construct an arbitrary write.

Architecture

Users reach the agents through the channels they already have open. Each agent retrieves from its own grounded sources and, when it needs to change something, hands off to Power Automate, which is the only component in the diagram with write access to Dataverse. The security agent has one additional path that none of the others have: out to a human.

Splitting retrieval from action is what makes the suite auditable. Everything on the retrieve path is read-only by construction, so the entire question of "what is this agent allowed to change" reduces to one list: the flows on the act path. That list is short, it is reviewable, and it does not grow unless someone deliberately grows it.

Guardrails & Escalation

• No direct model writes. Every mutation goes through a Power Automate flow with a fixed contract. There is no path from a generated response straight into a record.
• Narrow action surface. Each agent gets only the operations its domain needs. The reporting agent cannot write at all; the helpdesk agent cannot touch opportunities.
• Scoped retrieval. Grounding sources are assigned per agent, so "out of scope" is enforced by what the agent can see rather than by asking it politely not to answer.
• Human escalation. The security agent routes anything resembling a genuine incident to a person. Speed is not the goal on that path; correct handling is.
• Say "I don't know". Agents are built to fail closed when retrieval comes back empty. A confident wrong answer costs far more trust than an honest miss, and trust is what decides whether people keep using it in week three.

Technologies

Results & Impact

The measure I care about is not accuracy on a test set; it is that these are open on people's screens on an ordinary Tuesday. Agents that survive contact with real users are the ones that are honest about their limits and boring about their permissions.

The pattern turned out to be the reusable part. Once retrieve → reason → act was established with the first agent, the remaining four were largely a question of choosing grounding sources and defining an action surface, which is exactly the shape you want, because it means the security properties are inherited rather than re-argued every time.