Microsoft 365 Copilot on DR.365

Team knowledge base in SharePoint: Copilot compiles it, agents ground on it

Wed, 14 Oct 2026 07:00:00 +0200

On October 14, 2026, Microsoft announced a “team knowledge base” on the SharePoint blog. Copilot compiles a team’s content into a knowledge base of its own: a library of linked Markdown files that people can read and agents use for grounding. It starts as a Frontier preview and runs on usage-based billing.

This is the most interesting SharePoint announcement I’ve seen in a while, because it changes what an agent bases its answers on. It’s also the one I have the most questions about.

What’s actually new

Until now, grounding in Microsoft 365 meant retrieval. Copilot or an agent looks for passages in the original documents that match the question and builds an answer from them. The Knowledge Agent in SharePoint improved those documents with metadata and structure, but the answer still came from the originals.

The team knowledge base adds a layer in between. Copilot reads the team’s content and compiles it into a separate knowledge base: a special library of Markdown files that link to each other and are structured so agents can work with them easily. The component doing the compiling is the “Knowledge Compilation Engine”, part of Work IQ. If you want a quick refresher on where Work IQ sits, I covered it briefly in my post on RAG and Foundry IQ.

With retrieval, the knowledge is reassembled from raw data on every request. In the knowledge base, it already exists as a processed artifact you can open, read and correct. An agent no longer has to piece its answer together from twenty versions of the same slide deck.

How it works

It starts with a deliberate choice by the team: members pick the emails, chats, meetings and site content they want to contribute. The Knowledge Compilation Engine turns that into linked Markdown files, and from then on Copilot keeps them up to date. Both Copilot and agents can create, extend and curate the knowledge base, so think of it as a living library that keeps changing after the first run.

You can attach a knowledge base to any SharePoint site, including sites behind Teams channels and Microsoft 365 groups. In most tenants, that’s where the real teamwork happens.

There are two ways in: Copilot in SharePoint, and the Autopilot in the new Copilot app. Through the Autopilot you can also reach it from Teams, or simply send the Autopilot an email. The Autopilot rolls out separately, though, so turning on the knowledge base doesn’t mean your users have it.

On performance, Microsoft quotes its own internal tests from October 2026: agent responses up to 4x faster and 30% more token-efficient with the knowledge base. Those are vendor numbers. I wouldn’t put them into a business case before reproducing them with my own content.

Microsoft’s example scenarios cover three teams. Legal gets a knowledge base around its contracts. Engineering gets context for coding agents and an easier onboarding path for new team members. Sales gets account snapshots. The engineering case is the one I find most compelling: a coding agent that knows the architecture decisions from the Teams channel should write more useful code than one that only sees the repo.

Availability and licensing

As of today, the team knowledge base is available only in the Frontier preview and only for users on usage-based billing. Admins control it in the Microsoft 365 admin center. Microsoft says explicitly that the billing terms may change before general availability.

In practice, there’s no fixed per-license price, cost depends on usage, and the rules for that usage aren’t final yet. For a pilot, I’d pick a team with a manageable, well-maintained set of content. The department site with ten years of leftovers is a poor place to start.

Roadmap

Microsoft has announced several next steps, none of them with dates:

knowledge bases in Cowork, in Copilot in Teams and in Copilot Studio agents
deeper Microsoft 365 group integration, including bootstrapping a knowledge base from channels and mail
automatic curation through Copilot Studio agent flows
scaling to larger content sets with an approach called “Corpus Map”
integration with CLIs and coding agents through Work IQ

The same announcement bundled a handful of other SharePoint updates. Copilot in SharePoint is now generally available and the SharePoint tools in Work IQ are available. On top of that come a SharePoint Admin Agent, catalog management, a file-level permissions report for EEEU (“Everyone except external users”), insights into agent access, and a governance hub for site owners. I’d look at the EEEU report and the agent access insights first. They help you find overshared content before it ends up in a knowledge base.

My take: the open questions

Many of the organizations I work with are in regulated sectors, either critical infrastructure (KRITIS in Germany) or in scope for NIS2. For them, a feature like this stands or falls on questions the announcement doesn’t answer. I’m framing them as questions on purpose, because I don’t know the answers yet.

Permissions. The Markdown files are new files in a library. Do they inherit the permissions of their sources, or those of the library? What happens when an email goes in that only part of the team was allowed to read? Does the whole team then see the summary derived from it?

Sensitivity labels. Does a file compiled from a document labeled confidential carry that label? And which label applies when one file merges content from several sources with different labels? Mail and chats make this harder, because labeling there often works differently than in document libraries.

Retention. Mail, chats and site content are often covered by different retention policies. When the original is deleted at the end of its retention period, is the derived content removed too? Or does it live on in the knowledge base under the library’s rules? For deletion obligations and eDiscovery, that’s a big difference.

Cost control. If Copilot keeps the knowledge base current in the background, how much consumption does that generate when nobody is asking questions? Can you cap usage per site or per team, and how well can you estimate up front what a pilot will cost?

One tool already exists: in the Microsoft 365 admin center, Copilot > Cost Management lets you set spending policies with organization-level and per-user limits (Microsoft Learn). The “Auto-apply new services” setting is on by default, so newly supported services fall under existing policies automatically. The announcement doesn’t say whether the knowledge base shows up there as a service of its own. If you want to review new features before they’re covered, turn that setting off in the relevant policies.

Until those are answered, I wouldn’t attach a knowledge base to any site holding regulated or personal data. A pilot with non-sensitive content is a different matter, and I’d start one.

Conclusion

The team knowledge base is a real architectural shift: agents ground on a curated, readable layer instead of going straight to raw documents. Whether that holds up in practice depends on how permissions, labels and retention carry over. That’s where I’d look first in the preview, ahead of the performance numbers.

References

Agent lifecycle: how much governance does a Copilot agent need?

Mon, 12 Oct 2026 07:00:00 +0200

📝 This series has been extended

In October 2026 this series gained an introductory part. This post was originally part 1 and is now part 2. Part 1 sorts Agent Builder, Copilot Studio and Foundry by who carries the risk.

Building an agent with Agent Builder in Microsoft 365 Copilot takes a few minutes. Getting rid of it takes forever in many tenants, because nobody feels responsible. The colleague who built an agent for the travel expense policy last spring has moved to another department. The agent keeps answering questions anyway, based on a policy that has been out of date since July.

That is the problem an agent lifecycle solves. In this post I describe how I would set up a lifecycle for agents built with Agent Builder and Copilot Studio, and which tools Microsoft now provides for it. My take: not every agent needs the full process. Every agent does need an owner, and that only works for agents that are registered. What does not show up in the agent registry cannot be assigned to a person, reviewed or switched off.

The lifecycle by platform

Part 1 covers which tool fits which builder and who carries the risk. For the lifecycle, the phases stay the same, but where they happen depends on the platform.

IT manages Agent Builder agents (intrinsic model, the platform sets the boundaries) in the Microsoft 365 admin center: visibility, sharing, owners, blocking and deletion. There are no versions and no environments, so the lifecycle here is mostly about sharing, ownership and cleanup.

Copilot Studio (configurable model, the administrator sets the rules) uses application lifecycle management with separate development, test and production environments. Data policies, connector rules and publishing approval are tied to those environments (Microsoft Learn).

Foundry (explicit model, the organization owns model and code) follows your own engineering process: versioning, evaluation and publishing run through the development team’s tools and pipelines (Microsoft Learn). Published Foundry agents appear in the agent registry, and admins can stop them there (Microsoft Learn). The rest of this post focuses on Agent Builder and Copilot Studio. Foundry goes through the same phases, implemented with conventional software engineering.

The bridge between Agent Builder and Copilot Studio is the copy feature: an agent from Microsoft 365 Copilot can be copied to Copilot Studio once it needs more than a personal helper can offer. In lifecycle terms, that is the moment an agent changes zones.

Three zones instead of one process for everything

A single approval process for every agent fails on two sides. An IT review is overkill for the personal agent that summarizes my own meeting notes. A click on “Share” is not enough for an agent that answers payroll questions for 3,000 employees.

Microsoft addresses this with a zone model (Microsoft Learn). In zone 1, anyone can build agents for personal or team productivity, grounded in content they can already access. In zone 2, makers approved by IT build agents for other teams. These agents go through an IT review and are deployed to environments that IT manages. Zone 3 is reserved for organization-wide agents that are treated like any other enterprise application. The current whitepaper Administering and Governing Agents is now structured along the same personal, team and enterprise levels.

Microsoft now maps tools to zones more tightly: zone 1 for Agent Builder and SharePoint agents, zone 2 for Copilot Studio, zone 3 for Foundry and Copilot Studio in professional development. I still allow Agent Builder agents in zone 2 as long as they only read content the team can already access. For me, reach decides the zone, not the tool.

For the lifecycle, the zone decides how many phases an agent goes through and how strict they are. An agent in zone 1 takes the short path. As soon as its reach, data access or criticality grows, it moves to the next zone and into a stricter process.

The seven phases at a glance

The diagram builds on a lifecycle model that has been circulating online. I extended it with the zones, the specific Microsoft tools for each phase and a separate decision gate.

1. Identify

Everything starts with a real problem. Ideas go into a backlog, for example a SharePoint list or a Planner board. Each idea gets a short profile with the problem, the target audience and an accountable owner. Without an owner, the idea goes no further.

2. Assess and prioritize

This is where the most important decision of the whole lifecycle happens: which zone does the agent belong in? I look at value and effort, but mostly at the data. Which knowledge sources will the agent use, who is allowed to read them, and should the agent trigger actions in other systems? The answers also determine the tool. Agent Builder covers many zone 1 and 2 scenarios. Once actions, connectors to line-of-business apps or a broad rollout come into play, the path leads to Copilot Studio. If the agent needs its own model or orchestration, it ends up in Foundry and in the development team’s process.

3. Design and prototype

Success criteria come before building. What does the agent need to answer, and how will I know it does that well? Only then does a prototype take shape: directly in Agent Builder for zone 1, in a Copilot Studio development environment for zones 2 and 3. Microsoft recommends environment routing to send makers to personal developer environments automatically, so not everything ends up in the default environment (Microsoft Learn).

4. Validate and decide

This phase finally has a proper tool. Agent Evaluation in Copilot Studio has been generally available since the end of March. It lets you create test sets, choose evaluation methods and repeat runs across agent versions. A Power Automate connector and a REST API (currently in preview) make it possible to include evaluations in CI/CD pipelines (Microsoft Learn).

Security and data protection belong in this phase too: which data can the agent see, which identity does it run under, and do its permissions match the intended audience? If the agent calls other agents or tools, add a second question: do they act with the user’s permissions or with their own, possibly broader credentials? In Copilot Studio this is set per tool, and a connected agent does not inherit the setting of the agent that calls it. The phase ends with a deliberate decision.

The gate: Go, Change, Hold or Stop

The decision after phase 4 has four possible outcomes. Go leads to production. Change sends the agent back to phase 3 because quality or design still fall short. Hold parks it in the backlog, for example because a data source is not yet properly permissioned. Stop ends the idea in a controlled way.

Many organizations underestimate Stop. An agent that fails its tests should not stay in the tenant as a half-finished prototype.

5. Deploy and scale

In zone 3, nobody edits an agent directly in production. Microsoft recommends packaging agents as managed solutions and promoting them from development through test to production with Power Platform pipelines (Microsoft Copilot Blog). That gives you versioning, an auditable change history and the option to roll back.

Publishing to the organization runs through the Microsoft 365 admin center, where admins can approve or reject submitted agents. A gradual rollout follows. User training belongs in the same plan, otherwise even a good agent goes unused.

6. Operate and monitor

Operations is about usage, quality and cost. Copilot Studio provides analytics, Purview covers audit and data protection, and since May 2026 Agent 365 adds a dedicated control plane for agents. Copilot Studio agents appear in its agent registry once they are made available in Microsoft 365. The same agent can show up more than once, for example as a shared and as a published version (Microsoft Learn). Governance actions are logged in Purview.

Two things are a fixed part of operations for me: keeping knowledge sources current so the agent does not answer from outdated documents, and recertifying permissions on a regular schedule. Anyone working with customers in regulated industries knows this principle from identity management. It applies to agents in the same way.

7. Evolve or retire

Every agent ends at some point, either as a new version or through retirement. New versions go through the lifecycle again, starting at phase 2 or 3 depending on the scope of the change.

The admin center now includes the most important actions for retirement (Microsoft Learn). Admins can assign a new owner to Agent Builder and Copilot Studio agents, even when an agent is already ownerless. The new owner gets full edit and delete permissions plus access to the previous owner’s files, and the previous owner loses all access. Agent Builder agents can now have several owners, which admins can add or remove. Agents without a future can be blocked and deleted, with a 30-day window to restore them.

Microsoft’s Zero Trust workshop sums up the idea well: a lifecycle policy that nobody enforces remains a document (Zero Trust Workshop). Without this cleanup, the number of agents only ever grows.

Guardrails across all phases

Underneath the cycle sit six topics that apply in every phase and every zone: identity and ownership, data protection and compliance, permissions and sharing, environments and ALM, inventory and transparency, and quality and cost. In the diagram I mapped each topic to the tools available for it today, from Entra Agent ID through Purview to the agent registry.

Where it still falls short

The picture is not complete yet. Agent Builder agents have no real ALM with environments and versions. If you want to run one of them seriously, moving it to Copilot Studio is hard to avoid.

Copilot Studio has gaps as well. The built-in evaluations live in the cloud, not in source control, which makes automated quality gates in a pipeline harder than in classic software development. In an ESPC webinar, Stephan Bisser presented a CLI tool that versions test cases as YAML files to close that gap.

Finally, licensing: many registry features are available in the admin center. Risk signals in the registry and the advanced security and compliance capabilities of Agent 365 require Microsoft 365 E7 or an Agent 365 license (Microsoft Learn). Clarify this before you roll out.

Five things you can check tomorrow

Open the agent registry in the Microsoft 365 admin center and filter for agents without an owner.
Check whether environment routing sends Copilot Studio makers to their own developer environments, or whether everyone builds in the default environment.
Define the criteria that move an agent from zone 1 to zone 2, and write them down.
Create a first test set in Agent Evaluation for your most important agent.
Decide who takes over the agents of people who leave the organization.

What happens when an approved agent calls tools and hands work to other agents at runtime is the topic of part 3.