Not everything fits a visual canvas. Two code-level extension points matter, and then there is a platform choice that decides whether you should be in Copilot Studio at all.

• Declarative agents — you describe the agent in a manifest file: its instructions, which knowledge it may use, which actions it may call. Microsoft's orchestrator and models do the work. You are configuring a runtime, not writing one.
• Custom engine agents — you bring your own orchestration and your own model, and surface the result inside Microsoft 365. Full control, and correspondingly more to build and operate.

The tooling is the Microsoft 365 Agents Toolkit — previously the Teams Toolkit, another rename to recognise in older tutorials — with an accompanying SDK. A declarative agent is essentially a JSON document:

{
  "$schema": "https://developer.microsoft.com/json-schemas/copilot/declarative-agent/v1.0/schema.json",
  "version": "v1.0",
  "name": "Expenses Helper",
  "description": "Answers questions about the company expenses policy.",
  "instructions": "You answer questions about the expenses policy using ONLY the linked SharePoint site. If the answer is not there, say so and point the user at #ask-finance. Never estimate a limit you cannot cite.",
  "conversation_starters": [
    { "title": "Mileage", "text": "What is the mileage rate for own-car travel?" }
  ],
  "capabilities": [
    { "name": "OneDriveAndSharePoint",
      "items_by_url": [ { "url": "https://contoso.sharepoint.com/sites/finance-policy" } ] }
  ]
}

Read the instructions field again. The valuable part is not the persona — it is saying what to do when the answer is not there. An agent that admits ignorance and routes onward is more useful, and far safer, than one that produces a plausible expenses limit it invented.

Your policies may live in Confluence, ServiceNow or a bespoke system. A Microsoft Graph connector indexes that external content into the tenant's semantic index, so Copilot can ground on it exactly as it does on SharePoint. This is the mechanism that turns Copilot from a Microsoft-content assistant into one that covers the estate — and it inherits everything from chapter 8, because whatever permissions you map in are the permissions Copilot will honour.

Interaction history is available through Graph, which is how you build your own adoption reporting rather than relying on the built-in dashboards:

GET https://graph.microsoft.com/v1.0/copilot/users/{userId}/interactionHistory/getAllEnterpriseInteractions
Authorization: Bearer {token}

# Every prompt and response is also written to the unified audit log
# automatically, which is what makes eDiscovery -- finding and preserving
# everything relevant to litigation or a regulator -- possible over Copilot.

Microsoft's own guidance is unusually clear, and worth quoting: use Copilot Studio when governed workflow, connectors, approvals, and channel reach matter as much as the chat experience; do not use it for engineering-first scenarios that require custom model choice, runtime hosting, private networking, or deep orchestration.

Copilot Studio versus Power Platform is not a real rivalry — the first is part of the second. The genuine dividing line: if there is a conversation, Copilot Studio; if it is a form, an approval or a scheduled job with no chat interface, Power Apps or Power Automate. Production systems commonly use both, with deterministic steps running as flows behind a conversational front end.

Two facts to plan around. First, most licensed users can already build some kind of agent: the lightweight in-chat Agent Builder defaults to all users, works without any Copilot licence for web-grounded agents, and everyone is automatically a member of the tenant's Default environment, which administrators cannot revoke.

Second, Data Loss Prevention enforcement in Power Platform is mandatory and tenant-wide with no exemption since early 2025. Connectors classify as business, non-business or blocked, and policies gate which knowledge sources, connectors and channels an agent may use. Enforcement is real-time and blocks publishing.

Note there are two separate DLP systems with two separate admin centres: Power Platform DLP governs what an agent may connect to; Purview DLP can block SharePoint-grounded agents from processing labelled content. People conflate them and then cannot find the setting.

Microsoft uses the term agent sprawl in its own architecture guidance — uncontrolled agent sprawl, inconsistent architectures, and critical security gaps. The first lockdown step it recommends is securing that Default environment with DLP, since you cannot remove people from it. Restricting environment creation to administrators is the second.