Microsoft has recently introduced the Knowledge Agent in SharePoint (in preview as of September 2025), a new Microsoft 365 Copilot for SharePoint capability that brings some structured information management capabilities directly into end-users’ hands. The feature makes it possible to automatically generate columns, views, and rules that help organise content in document libraries. For technical and compliance teams, this marks an important shift: capabilities that were once controlled (although often through obscurity) by administrators or information architects can now be initiated by site owners and members with a Microsoft 365 Copilot license (check out the official Microsoft blog about the release here).
The implications are twofold.
On the one hand, Knowledge Agent has the potential to accelerate adoption of better metadata practices across large volumes of content within a list or a library. This is great for both our Atlas customers, but also for other organisations that have a good handle on their information architecture and governance.
On the other, for those that do not, it introduces governance challenges in areas such as change management, auditability, and standardisation. With tenant-wide enablement and relatively light configuration controls, organisations will need to consider carefully how to balance the power of automation with the need for oversight.
My aim is to provide guidance to help you make the Knowledge Agent sing as the feature matures over time! This blog unpacks the technical set-up, current limitations, and governance considerations of the Knowledge Agent in its preview release. I hope this helps to provide SharePoint administrators, compliance leads, and technical teams with a clear view of what the feature can (and cannot) do today, and to highlight the points where further preparation and guardrails may be required before general availability.
You will need to use PowerShell for this and authenticate with an account that has tenant-level SharePoint admin permissions.
Today in preview, you are limited to running the Knowledge Agent in three modes across your SharePoint tenant:
To be clear, it is not possible to turn the feature on against a list of sites to include. I.e. if you only want to run the Knowledge Agent in a single site, you will have to exclude all other sites. Keeping in mind that you can maximum exclude 100 sites.
For preview, Microsoft has released the admin toggle with the “KnowledgeAgent” parameter in SET-SPOTenant.
Tip: You will need to use SharePoint Online Management Shell (version 16.0.26413.12010 or later) which means that you need to run this in PowerShell 5 as far as I can tell (I am not a PowerShell guy though).
If you simply want to enable the Knowledge Agent for all sites, you run this command:
Set-SPOTenant -KnowledgeAgentScope AllSites
It is likely that you prefer to only run it – at least initially – for a few select sites. This is unfortunately not possible. You can however *exclude* it from up to 100 specific sites which you define in list of selected sites for exclusion. I hope this limitation is dealt with soon by Microsoft as it will limit most organisations from running small controlled trials.
You can create this list (an array) by adding the exclusion site, separated with commas into an array as follows:
Set-SPOTenant -KnowledgeAgentSelectedSitesList @("siteurlA", "siteurlB")
You can include the “append” option to the command it will add an additional site (or sites) into the array:
Set-SPOTenant ‘
-KnowledgeAgentSelectedSitesList @("siteurlC”) ‘
-KnowledgeAgentSelectedSitesListOperation Append
You can now enable the KnowledgeAgent to all sites, except those in the exclusion list as follows:
Set-SPOTenant -KnowledgeAgentScope ExcludeSelectedSites
Check the current configuration like this:
Get-SPOTenant | Select-Object KnowledgeAgentScope
And disable the Knowledge Agent (from all sites) again like this:
Set-SPOTenant -KnowledgeAgentScope NoSites
Microsoft’s full guidance is here: https://learn.microsoft.com/en-gb/sharepoint/knowledge-agent-get-started
Please see the most up-to-date list here: https://learn.microsoft.com/en-gb/sharepoint/knowledge-agent-organize-files#requirements-and-limitations
Important ones to note: Only *the first 100* terms of a mapped term set will be considered if you are using Managed Metadata columns.
Today, in preview, usage is included with Microsoft 365 Copilot license. Whether this shifts to a usage-based model later is not clear. (Please see Roadmap ID: 503145 which indicates support for Pay-As-You-Go for SharePoint Agents, which is slated for General Availability in October 2025. Microsoft 365 Roadmap | Microsoft 365)
To use the Knowledge Agent, you must have a Microsoft 365 Copilot license assigned and you will need to be a site-owner or a member to see the button for the Knowledge Agent.
In other words, any user with a Microsoft 365 Copilot license will see this feature in any site where they are an owner or a member. Assuming, of course, that the site is not on the Knowledge Agent exclusion list (see above).
The current version of Knowledge Agent for SharePoint is very light on governance. It is currently in preview, so I naturally expect some more controls to be implemented before General Availability. However, if Power Automate governance is anything to go by, organisations will need to quickly get their head around the power that is coming into end-user hands.
Action | Available controls |
---|---|
Set-up and deployment | Tenant wide by a SharePoint tenant admin through PowerShell (see above) |
Where can the Knowledge Agent run | There are three options when configuring at tenant level: No Sites, All Sites or All Sites except exclusion list |
Selected Sites for Exclusion | The exclusion list contains sites that are selected for exclusion (which is somewhat confusing). You can maximum exclude 100 sites - which is a serious limitation, even for a preview feature. |
Who has access to run the Knowledge Agent | Controlled by each site’s permissions (see above). In other words, this means that any Group/Site Owner and any Group/Site Member can see and submit the actions suggested by the Knowledge Agent. |
Restricting changes to specific content types | The columns only get applied to the default content type in the library. |
Creation of new suggested new columns | The current user, working within the Knowledge Agent, gets the opportunity to review and cancel or submit the suggested changes. There is no other governance of changes (i.e. multiple owners or members can carry out this action independent of each other). |
Creation of new suggested views. | There are no controls here for e.g. the Site Owner to control the views being created, although “personal views” are expected to be supported (and we assume become the default) in the future. |
Control of column types | There are no controls, e.g. to only allow “single line of text” columns. |
Naming of columns | There are no controls in place. For instance, many information architects and SharePoint professionals will ensure column names follow an internal naming pattern. This is not possible. |
Item level version control | When the Autofill for a column is turned on by the Knowledge Agent, the content for that column is likely to change when the Autofill process next runs against all or selected items in the list or library. It is important to note that any changes to column values are shown against the current version of the document or list item. In other words, if 10 columns are processed with Autofill, then these 10 columns values will be overwritten in the current version and it is not possible to revert to a previous version. |
Item level permissions | As far as I am aware and have seen, the Knowledge Agent does not make any suggestions with regards to item level permissions. |
Auditability | At the point of writing, I am not aware of any way to audit the actions carried out by the Knowledge Agent. Also see above regarding item level Version control. |
Data residency of processing | There is no documentation specifically related to the Knowledge Agent, but a fair assumption is that the data residency for processing will follow your tenant and your Microsoft 365 Copilot configuration. |
General lifecycle governance | There is currently – as far as I can see and have tested – no rollback or way to undo if a library has been “over-enriched” by the Knowledge Agent, by one or multiple users. |
A great new feature is the ability to automatically set-up rules. In preview this is however quite limited, but I would expect the capabilities to expand in short order.
In summary, you can create a rule to [carry out an action] under [specific conditions] when [a trigger] occurs.
Note the following key limitations for larger teams:
The combination of these two limitations makes the use of rules very limited for larger teams in collaboration within a single library or list.
Please see updated requirements and limitations here: https://learn.microsoft.com/en-gb/sharepoint/knowledge-agent-automate-workflows#requirements-and-limitations
What actually happens when you let the Knowledge Agent organize a library for you?
To find out, go to the library, click on the settings cog and select “Library Settings”.
(Note: In case you have previously used Syntex, ignore anything related to Microsoft Syntex settings.)
Then click the “More library settings”.
What you should now see is your library settings. If you are working in the default library for a site, you will see “Documents > Settings” up top.
In one of my tests, I was suggested to create “Case name”, “Judgment Date” and “Key Issues”.
Display name | Internal field name | Other settings |
---|---|---|
Case name | Case_x0020_name | Set as “Single line of text” with default options. |
Judgment date | Judgment_x0020_date | Set as “Date and Time” with default options. |
Key issues | Key_x0020_issues | Set as “Single line of text” with default options. |
The takeaway here is that while Knowledge Agent cleverly creates new columns, the columns are unlikely to follow typical enterprise standards for column naming and configuration.
As far as our initial tests have shown, the new columns that are created become searchable, but no other changes are made to the search schema. In other words, the Knowledge Agent doesn’t magically create new search schema settings.
Apart from the Rules that can be suggested and created using the Knowledge Agent, there are no specific Knowledge Agent triggers or actions available for Power Automate integration. On the as-soon-as-possible-wish-list would be a trigger to initiate a Power Automate workflow when changes have been made using the Knowledge Agent. At least then the Administrators and Site Owners can be notified if new columns have been created.
The Knowledge Agent for in SharePoint is still at an early stage, but it already introduces significant capabilities that will shape how content is structured and managed in SharePoint. For technical teams, the immediate priority is understanding how to enable and configure the feature at tenant level, and where the current limitations sit. For compliance teams, the focus should be on recognising the governance gaps: limited auditability, lack of standardisation controls, and the risk of inconsistent application across sites.
In practical terms, organisations should test the feature in controlled environments, establish internal guidance for site owners and members, and plan for monitoring once Knowledge Agent is more widely deployed. Keeping track of Microsoft’s roadmap and updates will also be critical, as the preview functionality is likely to expand rapidly.
It goes without saying that enterprise-wide governance of your information architecture, your taxonomy and how tags are applied has become more crucial than ever. If you want Microsoft 365 Copilot and Knowledge Agent in SharePoint to sing, you need to orchestrate it well.
By preparing now, technical and compliance teams can ensure they are ready to harness the benefits of Knowledge Agent, while also protecting against the risks that come with putting new automation tools directly into the hands of end users.