What Is a Copilot Knowledge Agent?
A Copilot Knowledge Agent — previously called a Declarative Agent — is a scoped version of Microsoft 365 Copilot configured to answer questions using a specific set of knowledge sources rather than the user's entire Microsoft 365 data corpus. Instead of Copilot searching across all of Exchange, OneDrive, Teams, and SharePoint visible to the user, a Knowledge Agent is pointed at designated SharePoint sites, Graph Connector data sources, or API plugins, and generates answers grounded exclusively in that curated content.
This scoping is the critical differentiator for enterprise use cases. When you deploy a "HR Policies Agent" scoped to the HR SharePoint site, employees get answers about leave entitlements, expense policies, and onboarding procedures sourced from authoritative HR documents — not from stale emails or personal documents that happen to mention related terms. The grounding constraint dramatically reduces hallucinations and makes the agent's outputs auditable: every answer cites the source document with a link, so employees can verify the response and HR can track which documents are being referenced most frequently.
Knowledge Agents are built and published through the Microsoft 365 Copilot Studio (formerly part of Teams App Studio) and distributed as Teams apps. From a developer's perspective, the agent definition is a JSON manifest declaring the knowledge sources, the agent's persona (name, description, system prompt instructions), and any plugins (API connectors for live data). The agent appears as a chat entity in Teams and can also be surfaced in SharePoint pages via a Copilot widget.
Licensing Requirements and Prerequisites
Copilot Knowledge Agents require a Microsoft 365 Copilot licence assigned to each user who interacts with the agent. As of mid-2025, this is the standard Microsoft 365 Copilot add-on (USD 30/user/month) applied on top of an eligible Microsoft 365 or Office 365 base plan. Admins building and publishing agents additionally require a Copilot Studio licence or the Copilot Studio capacity included with the Copilot licence — the exact entitlement depends on your tenant's agreement.
Before creating a Knowledge Agent, confirm these prerequisites in your tenant: Microsoft 365 Copilot is enabled and assigned to your test accounts; the SharePoint sites you want to scope are modern sites (classic sites are not indexed for Copilot); the user building the agent has the Teams App submission permission; and the Copilot Admin in the Microsoft 365 admin center has not blocked custom agents via policy. Missing any one of these prerequisites produces confusing error messages during agent creation that do not clearly indicate the root cause.
Graph Connector Setup for External Knowledge Sources
SharePoint and OneDrive content is indexed for Copilot automatically once the Copilot licence is assigned. External knowledge sources — ServiceNow articles, Confluence pages, custom databases, product catalogues — require a Microsoft Graph Connector to ingest and index the content into the Microsoft 365 search index. Microsoft provides pre-built connectors for dozens of popular platforms, and a custom connector framework (Graph Connector SDK) for bespoke sources.
Setting up a Graph Connector involves three phases: creating the connection in the Microsoft 365 Admin Center, configuring the schema (defining which external fields map to which Microsoft Search managed properties), and triggering the first full crawl. After the crawl completes, the indexed content is available to Microsoft Search — and therefore to Copilot — subject to the same permission trimming model as SharePoint content. External items can be given ACLs mapped to Azure AD users and groups, ensuring that Copilot only surfaces external content to users who have permission to see it.
{
"id": "hrknowledgebase",
"name": "HR Knowledge Base",
"description": "External HR policy articles from ServiceNow",
"schema": {
"baseType": "microsoft.graph.externalItem",
"properties": [
{ "name": "title", "type": "String", "isSearchable": true, "isRetrievable": true, "isQueryable": true },
{ "name": "content", "type": "String", "isSearchable": true, "isRetrievable": true, "isQueryable": false },
{ "name": "lastModified", "type": "DateTime", "isSearchable": false, "isRetrievable": true, "isRefinable": true },
{ "name": "category", "type": "String", "isSearchable": false, "isRetrievable": true, "isRefinable": true, "isQueryable": true }
]
}
}
Scoping Your Agent to Specific SharePoint Sites
In Copilot Studio, after creating a new agent, navigate to the Knowledge tab and click Add knowledge. Select SharePoint as the knowledge type and enter the URLs of the SharePoint sites or libraries you want the agent to use. You can scope to an entire site collection, a specific document library, or even a specific folder path. The agent will only retrieve answers from content within these scoped locations — content from other SharePoint sites, even if the user has permission to see it, will not be included in the agent's responses.
A practical scoping strategy for enterprise deployments: create one agent per domain (HR, IT, Finance, Legal) rather than one all-encompassing agent. Domain-specific agents produce more accurate answers because the language model can be given a more precise system prompt, the knowledge scope is tighter (less noise), and citation links go to department-specific documents that the target audience actually works with. The overhead of maintaining multiple agents is low — each is a JSON manifest with a Teams app package, and updates to the SharePoint content are automatically picked up on the next index crawl without requiring agent republishing.
Scoping an agent to a SharePoint site does not bypass SharePoint permission trimming. If a user asks a question whose answer is in a document they do not have read access to, Copilot will not surface that document or its content — even if the agent is "scoped" to include it. Access control is always enforced at query time.
Sensitivity Labels and Information Barriers
Microsoft Purview sensitivity labels applied to SharePoint documents and sites are honoured by Copilot at query time. If a document is labelled "Confidential" and the user's account does not meet the label's access policy, Copilot will not cite or summarise that document. This is enforced by the same Microsoft Information Protection (MIP) infrastructure used across the Microsoft 365 suite — there is no special Copilot-specific configuration required for label-based access control to work.
Information barriers add a second layer: they prevent users in defined segments from seeing content produced by or for users in other segments. When information barriers are active in a tenant, Copilot respects them — a user in the "Investment Banking" segment cannot receive answers drawn from content tagged to the "Retail Banking" segment. Verify your information barrier policies before deploying a Knowledge Agent to a department that handles sensitive or regulated information; barrier violations surface as unexpected answer gaps that are difficult to diagnose without understanding the underlying policy configuration.
Testing Grounded Answers vs Hallucinations
The most critical validation step before deploying a Knowledge Agent is confirming that its answers are grounded — sourced from the designated knowledge content — rather than hallucinated from the model's training data. Copilot Studio provides an integrated test panel where you can interact with the agent and inspect which knowledge sources were retrieved for each response. Every grounded response includes citations in footnote format; a response without citations is a signal that the model is answering from parametric memory, which means the answer may be outdated or fabricated.
Create a structured test matrix: select 20–30 representative questions employees would ask the agent, record the expected answer and its source document, then run each question through the agent and compare. Pay particular attention to questions where the answer exists in the knowledge base but is spread across multiple documents — these are the highest hallucination-risk scenarios. If the model synthesises an incorrect composite answer from partial matches, tighten the system prompt with explicit instructions: "Only answer from the provided knowledge sources. If you cannot find the answer in the knowledge sources, say so explicitly rather than guessing."
Add a "confidence disclaimer" instruction to your agent's system prompt: instruct it to prefix uncertain answers with "Based on the available documents..." and always end with the source document name. This trains users to check citations and builds appropriate trust calibration rather than blind acceptance of AI responses.
Monitoring Usage Analytics
Copilot usage analytics are available in the Microsoft 365 Admin Center under Reports > Copilot and in the Viva Insights Copilot dashboard. At the individual agent level, Copilot Studio provides a Analytics tab showing conversation volume, resolution rate (conversations where the user did not escalate or abandon), and the most frequently asked questions. These metrics are invaluable for identifying knowledge gaps — questions that consistently fail to resolve are topics you should add documentation for in your SharePoint knowledge source.
For compliance-heavy organisations, the Purview Activity Explorer logs all Copilot interactions — queries, responses, and cited documents — under the "Copilot Activities" workload. These logs can be retained, exported, and reviewed for compliance purposes, and they provide a detailed audit trail for sensitive agent deployments in Legal, Finance, or HR contexts. Set up a monthly review cadence where the agent owner reviews the top 20 questions, validates the answers against current policy documents, and updates any documents where the agent's response was found to be inaccurate.
Developer Extensibility: Plugins and API Actions
Knowledge Agents can be extended beyond static SharePoint content with API plugins — connectors that give the agent the ability to call live APIs in response to user questions. For example, an IT support agent scoped to the IT documentation site can also be given an API plugin that queries the ServiceNow REST API for live ticket status. When an employee asks "What is the status of my IT ticket #12345?", Copilot recognises the intent, calls the ServiceNow API via the plugin, and includes the live ticket status in the grounded response alongside any relevant documentation about the ticket process.
Plugins are defined as OpenAPI 3.0 specifications with a Copilot-specific x-ms-openai-data extension block that describes parameter semantics and response mapping. The Copilot orchestrator uses the operation descriptions in the OpenAPI spec to decide when to invoke the plugin — write these descriptions as natural language intent statements, not technical API descriptions, so the model can route user queries accurately. Authentication to the API can be delegated (using the user's own OAuth token), service-to-service (client credentials), or anonymous depending on the API's security model.
Key Takeaways
Knowledge Agents scope Copilot to designated knowledge sources, reducing hallucinations and making every answer auditable through source citations.
Deploy domain-specific agents (HR, IT, Finance) rather than one catch-all agent — smaller, focused knowledge scopes produce more accurate and trusted responses.
SharePoint permission trimming and Purview sensitivity labels are enforced at query time — Copilot will not surface content a user does not have permission to access.
Build a structured test matrix of 20–30 representative questions before launch and validate that every grounded answer includes a citation to a source document.
Extend agents with API plugins for live data queries — write OpenAPI operation descriptions as natural language intent statements for accurate Copilot routing.