Playbook

Building SharePoint and Copilot Studio knowledge agents

Updated August 2026

A working playbook from the iNDustry Labs team, written for companies considering this pattern and for the teams who will maintain an agent after it launches.

What this agent is

A conversational agent, built in Microsoft Copilot Studio, that answers questions from an organization's own curated documents and refuses to speculate beyond them. It is reachable through a browser, whether that is a shared kiosk, an intranet page or a channel like Microsoft Teams.

By default there is no open-internet access: the connected knowledge base is the agent's entire source of truth. That is what makes the pattern well suited to policy, HR and compliance questions, where a wrong or fabricated answer is costly.

That closed-book behavior is a setting, not a limitation of the technology. The ability to search the web or draw on general knowledge can be turned on if a project calls for it. The restriction is a deliberate scoping choice, and one worth revisiting explicitly with stakeholders rather than leaving in place by default.

This pattern comes up most often for HR knowledge agents, but the same approach applies to any bounded, document-grounded use case: IT policy, safety procedures, benefits, onboarding.

When it is the right fit

Good fit

A bounded, curated document set, policies, handbooks, SOPs, that someone owns and keeps current.
Repetitive questions whose answers already live in documents. "How much vacation do I get?" rather than "What should I do about my manager?"
The organization is already on Microsoft 365, since SharePoint and Copilot Studio are the native stack this pattern leans on.

Poor fit

Questions that need individual records rather than policy. "What is my current balance?" needs a system of record, not a document agent.
Content that changes constantly or has no clear owner. If nobody keeps the library current, answers go stale fast.
The organization is not on Microsoft 365, or wants a public-facing assistant with open, general knowledge.

How it is built

The build runs in three phases, and each phase has exit criteria worth honoring before moving to the next.

1. Discovery and setup

Lock in the document set with the content owner and get explicit sign-off before building. Each agent can hold a maximum of 500 knowledge objects, which can be files, folders, knowledge articles or websites, and an agent can draw on only five different source types at a time.
Sort out licensing. Pay-as-you-go gives agent access to team members without a Copilot account, and is unnecessary if everyone already has a license. Either way, one team member needs a full Copilot Studio license to build and configure the agent.
Confirm the compliance posture up front if the company is in a regulated industry.

2. Development

Once the knowledge source is confirmed, make sure files are current and unrelated files are excluded. In SharePoint, stand up a site and a dedicated document library, then upload text-based PDFs or Word documents. Avoid image-only scans, which will not index for retrieval. Up to 15 document libraries can be connected.
Create the agent and point its knowledge source at the library. Choose an orchestration mode: classic is predictable, trigger-phrase based and easiest to audit; generative is more flexible and reasons over context, but is less predictable. This decision shapes everything else about how the agent behaves.
Write clear instructions covering persona and tone, response formatting, scope boundaries, fallback behavior, and guardrails against prompt injection or attempts to reveal the agent's instructions.
Create topics for anything that needs a defined path rather than just an answer. Topics are pre-built conversation flows triggered by specific phrases or intents: use them for multi-step processes, escalation to a person, or any interaction that needs consistent steps. Well-named topics with clear trigger phrases also help route questions correctly.
Some system topics are populated automatically and cannot be deleted. They cover essentials such as greetings, requests to speak to a person, and ending a conversation, and their trigger phrases can be customized.
Build a broad set of test questions aimed at probing the agent's boundaries, confirming it declines out-of-scope questions rather than answering them. As a baseline, the agent should decline to interpret policy beyond what the source documents state, and should never surface individual personal records.

3. Deployment and handoff

Publish the agent. It cannot be shared until it is published, and publishing pushes the update to every connected channel at once.
Choose the deployment channel deliberately. An embedded SharePoint page, Teams, Microsoft 365 Copilot and a live website each have a different access model and a different way people get added or locked out.
Test in the real channel, not just the builder's test pane. Formatting, tables and images can render differently in production.
Hand off a plain-language maintenance guide so the team that owns the content can add, update or remove documents without outside help, and run a short post-launch monitoring window before winding down support.

Lessons that save time

What we learned the hard way

Re-indexing takes time. Documents added after the agent is created will not surface until the library is reindexed. Treat re-indexing as the second half of every content change, and budget up to 24 hours for larger libraries.
"No data" errors are rarely a file-format issue. If the agent finds a document but cannot read it, check that search indexing is enabled and trigger a manual reindex before blaming the file.
Test in the real channel. Formatting that renders fine in the test pane does not always survive the move to Teams or SharePoint.
Choose an orchestration mode deliberately. Compliance-sensitive use cases usually favor classic, since generative depends heavily on well-written descriptions.
Grounding must be tested, not assumed. Deliberately try to break the agent with out-of-scope and edge-case questions before rollout, and confirm it refuses rather than speculates.
Publishing is all-or-nothing across channels. There is no way to update one channel without it going live everywhere, so re-test every channel after each publish.
Keep different content types in separate agents. When two sources carry different authority, official policy versus informal notes for instance, blending them in one agent hides which source an answer came from.

Helpful resources

Microsoft's own documentation is the reference to keep open throughout a build:

iNDustry Labs runs the AI Executive Group alongside the AI Leaders of Tomorrow fellowship at the University of Notre Dame.

All AI updates →