AI Agents on DR.365

Microsoft's AI Strategy Roadmap from an operator's view: what holds up and what regulated organizations must add

Tue, 20 Oct 2026 07:00:00 +0200

In July 2026 Microsoft published a 66-page e-book called The AI Strategy Roadmap, subtitled How organizations are achieving Frontier Transformation. As service owner for Digital Workplace & AI at an IT service provider whose customers mostly work in regulated sectors (KRITIS, NIS2), I read it with one question: what holds up in operations, what is marketing, and what’s missing?

“Frontier Transformation” is Microsoft’s term for moving from isolated AI use cases to AI that is built into core business processes.

What the e-book is based on

The recommendations draw on 70 interviews of 30 to 45 minutes with IT and business decision-makers, conducted by Emerald Research Group on Microsoft’s behalf between 23 February and 13 March 2026. Microsoft’s own internal rollout, where it acts as “customer zero”, is the second source.

The opening table lists seven typical hurdles: too many ideas and no clear starting point, ROI that stays abstract, fragmented data, compliance reviews that slow expansion, scaling without clear responsibility, users who don’t trust the agent, and missing skills. The answers attributed to “Frontier Firms” mostly say the same: start narrow, measure early, expand one use case at a time.

The e-book then defines five overall readiness stages (Exploring, Planning, Implementing, Scaling, Realizing) and gives each of its five value drivers its own five-level maturity model.

Five drivers across five stages: my condensed reading of the e-book’s maturity models, in my own words.

The five drivers as a self-check

Each driver in short, with one question for your own organization. The questions target stage 3, where most of the work between pilot and production happens.

1. Business strategy. AI work is tied to business goals, funded deliberately and managed as a portfolio. The e-book wants one narrow, measurable use case first, prioritized with a consistent framework. It names the Microsoft AI Decision Framework, also known as the BXT framework (business, experience, technology). Stage 3 check: Do AI KPIs show up in your regular business planning, or only in the project status report?

2. Technology and data. Data readiness is a prerequisite, and a shared, managed platform replaces a new build for every pilot. Cost management is part of the design from the start. Stage 3 check: Can you name the data sources a production agent may use, and who owns each one?

3. AI strategy and experience. Pilots are instrumented from day one, and what works becomes templates and patterns for the next team. GenAIOps practices such as versioned prompts and continuous testing turn experiments into operations. Stage 3 check: When the prompt or model of a production agent changes, is there a test run before it goes live?

4. Organization and culture. A Frontier Center of Excellence (CoE) sets standards and guardrails without owning every solution, backed by champions and role-based training (the e-book points to AI Skills Navigator, which now surfaces in the Learning agent in Copilot as a preview). According to Microsoft’s 2026 Work Trend Index, cited in the e-book, organizational factors drive 67% of the realized value from AI. Stage 3 check: Does your CoE have a mandate, a budget and a named lead, or is it a recurring meeting?

5. Governance and security. Governance is built into the agent lifecycle: identities, least privilege, monitoring, an inventory of all AI systems and a review before every deployment. Stage 3 check: Can you list every agent in production today, with owner and permissions, without asking around?

Microsoft Learn has a related agentic AI adoption maturity model with almost the same five pillars and levels 100 to 500. For an assessment workshop I’d use that one: each pillar has its own detailed page.

What holds up in operations

Data hygiene is the critical path. Microsoft’s own lesson as customer zero: when data is poorly classified, duplicated or overshared, agents amplify the problem. The line I’d show any steering committee: “For agents, data quality becomes action quality.” With Copilot we see the same: oversharing that existed for years becomes visible the day an agent can search it. My pre-rollout playbook on oversharing covers the concrete steps.

The safe path has to be the easy path. When IT makes approved routes slow, people move to public tools and take company data with them. The e-book recommends building guardrails into the tools that make experimenting easy and moving IT from owning every solution to governing platform and data. In my experience that’s the only thing that works against shadow AI over time. Bans age quickly.

Agents need identities and a lifecycle register. The e-book wants permissions, lifecycle controls and monitoring per agent, plus a register that tracks each one from approval to retirement. In Microsoft 365 that maps to Microsoft Entra Agent ID and the agent registry in Agent 365. I’ve written about the lifecycle side and about delegated permissions at runtime.

Every agent should get a safety evaluation before deployment. Security teams test before production, and continuous monitoring looks for prompt injection and unsafe tool calls afterwards. That’s the Measure stage from Microsoft’s four-stage model for responsible generative AI, and it belongs in the release gate.

Reuse works best when guardrails come with it. Templates and pattern libraries should contain the governance, data handling and evaluation requirements, so a new team inherits the controls. Microsoft describes its own agents as “graduating” from personal to enterprise-wide use, with validation, security review and integration hardening before they scale. Whether you build with Agent Builder, Copilot Studio or Foundry decides how much of that you can enforce centrally.

IT acts as curator instead of gatekeeper. At Microsoft, IT exposes certified data sources and runs agent memory and integrations (APIs, MCP, connectors). The CoE started in 2023 as an advisory group and moved to coordination, reviewing ideas against four pillars: strategy, architecture, roadmap and culture. A “fast train” gives a trusted group early, broad access under clear guardrails. I’d copy that model and keep the trusted group small.

Where it’s too smooth

The ROI message contradicts itself. The hurdles table says it’s hard to convince leaders that hard ROI evidence isn’t the goal. A few pages later, readers are told to pick use cases that show ROI early. In a mature program both can be true. A steering committee that hears both will pick the one it prefers.

Agents are enablers, or they replace capacity. Change management should make clear that agents are enablers and not job threats. Yet the target state for driver 1 says growth is no longer constrained by headcount, and the benefits list promises scaling without proportionally more staff. Employees and works councils read both statements. If you use the e-book internally, decide which message you mean and stick to it.

The evidence is thin. Seventy vendor-commissioned interviews plus the vendor’s own rollout describe patterns but prove no effects. The 67% figure comes from Microsoft’s own Work Trend Index. That’s fine for orientation and weak as a business case.

Cost management stays vague. The e-book wants cost efficiency designed in early and names cost modeling as a scaling gap, without saying how: no chargeback model, no unit cost per agent, no guidance on consumption-based billing. For a service provider, this is where pilots stall.

What’s missing for Europe

The regulatory map in driver 5 shows the EU AI Act, the NIST AI RMF, ISO 42001, ISO 23894 and frameworks from several other countries. The GDPR gets one mention, next to HIPAA. Three things that shape every AI project in a regulated German organization don’t appear. What follows is my professional view, not legal advice.

Co-determination. Under Section 87(1) no. 6 of the German Works Constitution Act (BetrVG), the works council has a say in technical systems designed to monitor employees’ behavior or performance, and courts read “designed” broadly: being objectively suitable is enough. Copilot and agents that log usage will usually meet that test. Since 2021, Section 90 explicitly includes AI among the planned work processes the works council must be informed about. That belongs in driver 4: involve the works council when you plan the first use case and treat a works agreement as part of the roadmap.
NIS2. For entities in scope, an agent is an IT system like any other. Risk management, incident reporting and management accountability apply. In driver 5, the agent inventory and the incident process have to cover agents.
DORA. Financial entities have been subject to DORA since 17 January 2025, including ICT risk management and a register of contractual arrangements with ICT third-party providers. Every AI platform and external model is a candidate for that register, which touches driver 2 (platform choice) and driver 5 (evidence).

How AI Act, GDPR, NIS2 and ISO controls overlap for agents is the topic of my compliance map for Microsoft 365 agents.

What I’d take from it

For an organization at Planning or Implementing:

Start with one measurable use case and a human in the loop. Define the KPI before building and keep the approval step in the workflow until the numbers justify removing it.
Set up the agent inventory before the second agent: owner, purpose, data sources, permissions, next review date. Retrofitting it at agent 30 is a project of its own.
Turn the CoE into a “Center of Acceleration”, a term the e-book uses itself. Measure it by how fast a team gets a safe template and a decision, not by how many requests it turns down.
Bring data protection, the works council and information security to the table when the first use case is chosen. At go-live, all they can do is say no.

Where do organizations in KRITIS and NIS2 environments tend to get stuck? I’d place most of them between Planning and Implementing: the first use case is defined, but not yet in production. The brake is usually drivers 4 and 5 together. Nobody decides with authority what an agent may access, and the works council and information security join late, so every approval starts from zero. That’s why steps 2 and 4 come before the second agent.

Conclusion

The five drivers give you a shared vocabulary for a maturity check; the Microsoft Learn model adds the detail.
The strongest content is operational: data hygiene, an agent inventory, predeployment evaluation and guardrails built into templates.
Read the ROI and headcount statements critically, and the evidence as vendor research.
In Europe, add co-determination, NIS2 and DORA to drivers 4 and 5 yourself.

References

Microsoft: The AI Strategy Roadmap: How organizations are achieving Frontier Transformation (e-book, PDF, July 2026)
Microsoft Learn: Agentic AI adoption maturity model
Microsoft Learn: Build an agentic Center of Excellence
Microsoft Learn: Evaluate and prioritize an AI use case with business envisioning (BXT)
Microsoft Learn: Agent registry in the Microsoft 365 admin center
Microsoft Learn: What are agent identities? (Microsoft Entra Agent ID)
Microsoft Learn: Manage AI Skills Navigator
Works Constitution Act: Section 87, Section 90 (gesetze-im-internet.de, German)
EUR-Lex: NIS2 Directive (EU) 2022/2555, DORA Regulation (EU) 2022/2554

Built for human pace: what Anthropic's source control rewrite means for enterprise IT strategy

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

In May 2026, Anthropic merged about 2,500 code changes per day into its monorepo. By September it was more than 30,000. Git and the mirror infrastructure around it could not keep up, so a team of seven built its own version control system and moved the entire monorepo onto it in five months (Anthropic Engineering).

Almost nobody reading this will build a version control system. That isn’t the point of the story. Every organization runs processes that were sized for the speed of people: change advisory boards, four-eyes approvals, access reviews, CI pipelines, budgets calculated in person-days. Once agents do a large share of the work, those processes become the bottleneck, and the question is which of them you redesign before they break.

TL;DR

Agents are becoming the main consumers of your systems. Architecture decisions should assume machine clients that are always online and call APIs at high volume.
Review and approval have to move from “a human looked at everything” to rules that decide where a human must look.
Every agent needs an identity, an accountable person and a cost center. Without those three you can neither govern nor budget agent work.

What Anthropic actually changed

The headlines say “Anthropic threw out Git”. The engineering post is more careful. The new system is called Scion, the review tool Antique. Anthropic explicitly says Scion is not a general replacement for git, because that would mean replacing the whole development toolchain. They published the design so that git platforms can adopt parts of it.

The numbers explain why they did it anyway. The main branch history is almost 100 GB, a compressed working copy more than 25 GB, and CI runs roughly 25 million checkouts per day. Git is designed for distributed clients that work offline. Anthropic’s clients are almost entirely agents and jobs that are always online. Scion moves the expensive work to the server: commits, merges, rebases, history and blame happen there, clients get sparse, virtualized checkouts that load files on demand, and much of the functionality is available through an API without any local repository. According to the post, the new infrastructure uses about 200 times less CPU and memory than the old git mirrors, and CI checkouts take seconds instead of minutes.

Three decisions in the post matter beyond source control:

There is no merge queue with a global lock. Anthropic invested in post-merge and pre-deploy testing instead. Conflicts between concurrent changes happen, and Claude usually fixes them faster than a human would notice them.
Antique can express semantic rules for approvals. A comment-only change gets treated differently from a change to sensitive logic, so human reviewers spend their time where it counts.
Access control at repository and directory level was built in from the start, not added later.

Agents are the new primary client

The first lesson is about architecture. Most enterprise systems assume a person in front of a screen. Agents behave differently: they poll, they run in parallel, and they don’t take lunch breaks.

In Microsoft 365 you can see this today in Microsoft Graph throttling. Microsoft lists two typical causes: many requests across all applications in a tenant, and many requests from one application across tenants. Polling a resource and repeatedly scanning collections are named as patterns that lead to throttling. The recommended alternatives are delta queries and change notifications, and for bulk extraction Microsoft points to Graph Data Connect instead of the REST APIs (Microsoft Learn). SharePoint Online goes one step further: an application that keeps exceeding limits can be blocked entirely (Microsoft Learn).

That guidance was written for integration developers. It now applies to every agent that reads mailboxes, sites or Teams channels on someone’s behalf. When I evaluate an agent scenario, I now ask how it detects changes before I ask what it does. An agent that rescans a document library every ten minutes works fine in the pilot and becomes a problem when 40 departments copy it.

For your own systems the same principle applies in the other direction. If agents are going to be the main consumers of an internal platform, give it a proper API, change feeds and per-client limits. A web UI with a scraping agent in front of it is the git mirror of your organization: it works until the volume grows tenfold.

Review by intent instead of line by line

The second lesson concerns control processes. The Anthropic team still reviews every change, but they review the intent, not every line. Their main job, as they describe it, is telling Claude “no”: when it violates system constraints, or when it over-engineers in response to hypothetical concerns.

In regulated environments this is the uncomfortable part. Many change processes implicitly promise that a qualified person checked everything. At 30,000 changes per day that promise can’t be kept, and honestly it often wasn’t kept at 30 per week either. The CAB that approves a stack of changes in 45 minutes is mostly checking that the form is complete.

In my experience, auditors want evidence that changes are controlled and traceable. NIS2 asks for risk management measures that include security in development and maintenance; it does not prescribe that a human reads every line. That leaves room for a model that ITIL already knows as standard changes, applied to agent output:

Low risk (documentation, tests, formatting, configuration within defined guardrails): automated checks, no mandatory human review, full logging.
Medium risk (business logic, integrations): human review of intent and test evidence, with the agent’s summary as input.
High risk (authentication, permissions, data flows across trust boundaries, anything regulated): line-level review by a named person, the way it has always been.

What decides the tier has to be a rule, not a gut feeling. Anthropic models this in the review tool, and you can model it in branch protection rules, CODEOWNERS files or a Power Automate approval flow. The rule itself is the control that an auditor will want to see.

I would be careful with one part of the Anthropic approach: moving checks after the merge. For an internal developer platform that is a reasonable trade. For a system in a KRITIS environment where a faulty change can reach production directly, I wouldn’t do it. The safeguard has to sit before deployment, even if it no longer sits before the merge.

Every agent needs an identity and an owner

Anthropic built access control into Scion from day one, down to the directory level. In Microsoft 365 the equivalent is the identity layer for agents. Microsoft Entra Agent ID gives agents their own identities in the directory, created from agent identity blueprints. Every agent identity requires a human sponsor who is accountable for purpose, lifecycle and access reviews. If the sponsor leaves, sponsorship transfers to their manager. Conditional Access and access packages from entitlement management apply to agents as well (Microsoft Learn). As of October 2026, identity governance for agents is labeled preview, and the licensing depends on Microsoft 365 E7 or Agent 365 licenses; check the current terms before you plan with it.

On top of that, Microsoft Agent 365 provides the registry as one inventory of Microsoft and non-Microsoft agents, including counts of agents without owners (Microsoft Learn). I described the governance side in more detail in the post on the agent lifecycle.

The strategic point: an agent that runs under a shared service account or a person’s delegated credentials cannot be distinguished in the audit log, cannot be throttled separately and cannot be billed separately. Fixing that later for hundreds of agents is the kind of project nobody wants to fund.

Measuring agent work

The budget side breaks in the same way. Controlling in most IT organizations still calculates in person-days, and that model has no line for agent work. A practical way to close the gap is to route agent sessions through an AI gateway, so that every token and every hour of runtime can be assigned to a project and a repository and priced at real cost.

A feature that needed 20 days last year and 3 days of review plus agent runtime this year doesn’t fit that model. Counting agent hours is a start, but hours are an input metric. What you want to know is the cost per accepted change: tokens and runtime plus the human time for review, rework and the cases where someone had to say “no”. Without the human share, agent work looks cheaper than it is.

For Microsoft agents, Agent 365 observability collects activity data and is meant to support business metrics like usage and time savings (Microsoft Learn). That covers part of the picture. Coding agents outside Microsoft 365 need their own attribution, and that is where the gateway approach comes in.

Decisions for the next twelve months

Anthropic expects other organizations to run into this class of problem within the next six to twelve months. Even if your timeline is longer, these are the decisions I would make now:

Inventory human-paced controls. List every approval, review and pipeline step that assumes a person and a working day. Mark which ones would break at ten times the volume.
Introduce risk tiers for changes. Write down which changes need a human, which need a human for intent only and which need logging only. Make the rule machine-readable.
Give agents their own identities. No shared service accounts, every agent with a sponsor, permissions through access packages with an expiry date.
Design integrations for machine clients. Delta queries, change notifications and API budgets instead of polling and scraping.
Attribute agent cost. Tokens and runtime per project, plus the human review time, from the first productive agent onward.

What I wouldn’t do is copy Anthropic’s tooling. Their problem was 25 million checkouts a day. Yours is more likely a change process that takes two weeks for a configuration change an agent prepared in ten minutes. That is the place to start.

References

Anthropic Engineering: Redesigning source control at Anthropic (October 13, 2026)
Microsoft Learn: Microsoft Graph throttling guidance
Microsoft Learn: Avoid getting throttled or blocked in SharePoint Online
Microsoft Learn: Governing agent identities
Microsoft Learn: Manage agent registry in Microsoft 365 admin center
Microsoft Learn: Agent 365 observability
EUR-Lex: Directive (EU) 2022/2555 (NIS2), Article 21

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

RAG for agents: where a plain agent falls short and what Foundry IQ changes

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

This week (October 12–14, 2026) I’m sitting in the AI-103 course, Developing AI Apps and Agents on Azure. One slide compared a plain agent with a RAG agent: five limitations on the left, five fixes on the right. The slide is correct. As service owner for M365 collaboration and Copilot at a service provider with customers in regulated sectors (KRITIS, NIS2), I read it with SharePoint, permissions and governance in mind, and from there several of the fixes look like new work for the people who run the data.

TL;DR

RAG makes an agent only as current, correct and safe as the content and permissions behind it. Oversharing and stale documents in SharePoint turn directly into bad answers.

Foundry IQ gives you one shared knowledge base for many agents, built on Azure AI Search agentic retrieval. That fixes the “every team builds its own pipeline” problem.

As of October 2026, the parts you’d want for SharePoint in a regulated tenant (both SharePoint knowledge sources, LLM query planning, permission enforcement) are still in preview.

RAG in a few sentences

A language model only knows its training data. Retrieval augmented generation (RAG) adds a step before the answer: the agent searches connected sources for passages that fit the question, puts them into the prompt and lets the model answer on that basis, ideally with a reference to where each statement came from. The model stays the same; the material it works with changes.

Five limits of a plain agent

Limit of a plain agent	What happens without RAG	What RAG changes
Knowledge cutoff	Answers reflect the state of the training data, so policies and products can be months or years out of date.	Current documents are pulled from connected sources at question time.
No access to private data	The agent can only offer general knowledge, not your process, contract or system.	Internal knowledge bases become searchable for the agent.
Missing organizational context	Advice ignores your approval chains, workflows and security policies.	Answers are based on the policies and procedures that were retrieved.
Made-up answers	Plausible but wrong statements become a compliance risk.	Answers point to the source they’re based on, so people can check them.
Scaling	Every team builds and runs its own RAG pipeline with its own index, chunking and permission logic.	One shared knowledge platform serves many agents, for example Foundry IQ.

Where the slide gets too optimistic

“Always current” means “as current as the index”

Foundry IQ distinguishes two kinds of knowledge sources. Indexed sources copy content into an Azure AI Search index: chunking, embeddings, metadata, optionally permissions. They’re as fresh as the last indexer run, and you set that schedule yourself. Remote sources store nothing and query the source system on demand at retrieval time, so the content is current by design.

Permissions follow the same logic, and that’s the part I’d watch more closely than content. For indexed SharePoint with ACL ingestion (preview), Microsoft documents that item-level permission changes are picked up on the next indexer run. Changes on a parent scope (site, library, folder) are not; those need an explicit resync. Until then, the index serves stale permissions. If your offboarding or need-to-know process relies on removing someone from a site, that gap belongs in your risk assessment.

A citation doesn’t make an answer correct

A source reference proves that a passage was retrieved. It doesn’t prove the passage was the right one, still valid, or reproduced faithfully. RAG reduces hallucinations; it doesn’t eliminate them. The model can still combine two correct passages into a wrong conclusion, or quote the 2023 version of a policy because it ranked higher than the 2026 one. Citations make errors easier to find, but someone still has to look.

RAG turns SharePoint hygiene into agent quality

With RAG, the agent’s answers are a direct function of what’s in the sources. Everything that already bothers you in SharePoint ends up in the answers:

Oversharing: content shared too broadly is found and quoted, as permission enforcement works with the permissions that exist, not the ones you intended.
Stale documents: an outdated policy that nobody archived competes with the current one.
Duplicates: three copies of the same process description in three versions give the retrieval engine three options to choose from.

Permissions and sensitivity labels become quality controls. Scoping a knowledge source to the right sites, removing “Everyone except external users” shares and archiving outdated content directly improve the answers.

An agent only knows the approval chain that’s written down

RAG can only ground answers in approval chains and security policies that are documented somewhere the agent can reach. In many organizations, the real approval chain lives in people’s heads or in a Teams chat from 2022. In practice, a RAG project often starts as a documentation project.

Foundry IQ in short

Foundry IQ is the managed knowledge layer in Microsoft Foundry (formerly Azure AI Foundry). It consists of three building blocks, all running on Azure AI Search:

Knowledge base: the top-level object. It groups one or more knowledge sources and controls retrieval behavior. Multiple agents can share one knowledge base.
Knowledge sources: connections to indexed or remote content. As of October 2026, Microsoft Learn lists, among others, search index, Azure Blob, OneLake, Azure SQL, file upload, indexed and remote SharePoint, Fabric data agents and ontologies, MCP servers, Work IQ and Bing web grounding.
Agentic retrieval: the retrieval engine. With an optional LLM, it breaks a question into subqueries (query planning), picks the relevant sources, runs searches in parallel, reranks the results and returns extracted content with references. The retrieval reasoning effort controls how much LLM work goes into this: minimal uses no LLM (up to 10 sources), low allows three sources and three subqueries, medium five of each plus an iterative pass.

Agents connect via the knowledge base’s MCP endpoint: in Foundry Agent Service (as an MCP tool), with Microsoft Agent Framework, or in any custom app via REST and SDKs. Copilot Studio reaches a knowledge base indirectly: you connect a Foundry agent that uses the knowledge base to your Copilot Studio agent (preview).

Foundry IQ is one of three “IQ” workloads. Work IQ provides collaboration context from Microsoft 365 (documents, meetings, chats). Fabric IQ models business data in Microsoft Fabric. Foundry IQ connects enterprise knowledge across Azure, SharePoint, OneLake and the web. The three are independent but combinable; Work IQ is even available as a Foundry IQ knowledge source.

SharePoint as a knowledge source

For SharePoint, you have two options, both in preview as of October 2026:

Indexed SharePoint generates an indexer pipeline and copies the content into Azure AI Search. Permissions only apply if you configure ACL ingestion and pass the user token at query time. The documented limitations are worth reading first: sharing links scoped to “Anyone” or “People in your organization” aren’t supported, Entra groups nested inside SharePoint groups aren’t expanded, and the SharePoint indexer page states that tenants with Conditional Access enabled aren’t supported. For most regulated tenants I know, that last point alone is a show-stopper.

Remote SharePoint uses the Copilot Retrieval API and queries SharePoint live on behalf of the user. Nothing is copied; the Retrieval API enforces SharePoint permissions and Microsoft Purview sensitivity labels itself. Microsoft recommends this path for custom RAG apps on SharePoint. The trade-offs: every user needs a Microsoft 365 Copilot license or Retrieval API pay-as-you-go (preview, requires at least one Copilot license in the tenant). There’s a limit of 200 requests per user per hour and a maximum of 25 results per query, OneDrive content isn’t included, and only text is retrieved.

If your users already have Copilot licenses, I’d make remote SharePoint the default: no second copy of your data, no second permission model to keep in sync.

What this means in regulated environments

Permission-aware retrieval isn’t automatic. Microsoft’s docs are explicit: without the user’s token in the request, permission-enabled sources return results unfiltered. If an agent calls the knowledge base with its own managed identity, every user gets the same result set. Build and test the token passthrough before the first pilot, not after.
Traceability is a real benefit. References with URLs and sensitivity label information show which documents an answer was based on. For audit questions, that beats “the model said so”, provided your logging captures it.
Check the preview status line by line. With the stable API version 2026-04-01, only search index, Azure Blob, OneLake and web knowledge sources are generally available, with minimal reasoning effort. Both SharePoint sources, LLM query planning, answer synthesis and the permission features are preview, without an SLA and not recommended for production. The Foundry portal and the Azure portal expose all agentic retrieval features as preview only. For a KRITIS customer, that’s a pilot, not a production service.

In my post on Microsoft’s four-stage model for responsible generative AI, grounding is the third of four mitigation layers, alongside the system message. Foundry IQ is a concrete way to build that layer. It doesn’t remove the need for the other three.

Takeaways

Clean up before you connect. Oversharing, stale documents and duplicates in SharePoint become agent errors. A site cleanup is the cheapest quality improvement you’ll get.
Prefer remote SharePoint if users have Copilot licenses. No second copy, permissions and labels enforced at the source, no ACL sync to monitor.
Test the user token path explicitly. Without it, permission-enabled sources return unfiltered results, and every user sees the same content.
Treat Foundry IQ on SharePoint as a pilot for now. Plan production use once the SharePoint knowledge sources and permission features reach general availability.