AdamHarmetz I'm providing some (lengthy) feedback on SharePoint Agents - hope you don't mind.
Note that these are my thoughts on SharePoint Agents which may differ for others. I just wanted to share my experience to help to improve the overall agent experience.
We’re excited about the possibilities SharePoint Agents bring to the table—especially the insights they can provide into our documents and sites. However, the current implementation raises several significant concerns that prevent us from enabling them across our organization.
Below are the key issues we’ve encountered. Most of them have been raised since the early days of the private preview—not just by us, but by many others in the community.
We need the ability to disable SharePoint Agents at the tenant level and selectively enable them for specific users for testing. Currently, the only way we’ve achieved this is by requesting Microsoft to apply a backend configuration—an impractical and unsustainable workaround.
There should be native, admin-level toggles to disable or restrict access for large feature rollouts, much like what we’re requesting for Site Themes (which currently cannot be disabled despite conflicting with our brand strategy).
Although Microsoft suggests disabling access via Copilot licensing, doing so removes all Copilot functionality related to SharePoint—not just the agents. That’s too broad and makes the option unusable.
There is no way to enable SharePoint Agents for specific sites only. If enabled, agents are activated across all SharePoint sites in the tenant. With over 100,000 sites in our environment, a blanket enablement is out of the question.
Currently, anyone with Edit rights can create agents, not just site owners. On some sites, that can mean hundreds (if not thousands) of users could start building agents with no training or oversight.
We require:
- Creation rights limited to site owners or those explicitly granted access to create agents.
- Governance controls to ensure only trained individuals can build agents.
Each site gets a default agent, but there’s no way to edit or customize it. There are many scenarios where an agent should only focus on specific site content, and this lack of flexibility limits its usefulness.
When an agent is created—even just for testing—it automatically appears in the Recent section of the Copilot menu. Owners have no way to hide or remove it from there.
Similarly, “Recommended agents” are surfaced without any clear controls available to site owners.
The current approval mechanism is confusing and flawed:
- When an agent is approved, it’s moved to the “Approved” folder in the Site Assets Library (Site Assets > Agents > Approved). This can:
- Break inherited permissions
- Remove existing metadata
- Expose users to Site Assets (which we’d prefer to keep hidden)
- Confuse users when they can’t find the agent file in the original location with no idea where it was moved to
- There is no intuitive way to “un-approve” an agent other than manually moving it out of the Approved folder (you can’t un-approve from the UI).
- Any user—even non-owners—can move an agent into the Approved folder and that alone marks it as approved. This is a serious governance issue. They can also move an agent out of the Approved folder which will un-approve it (remember – this is just someone with edit rights on the site – not just the owners).
- Editing an approved agent does not revoke approval, meaning changes go live without re-validation.
There’s no way to hide the “Agent” option under the New menu. Even if you untick it, it reappears automatically. Microsoft is pushing agent creation aggressively, placing entry points in multiple places with no way to reduce visibility or access.
Why not limit agent creation to the SharePoint Agent panel instead of cluttering every interface? The more agents created by users – the more revenue for Microsoft – thoughts?
The Pay-As-You-Go (PAYG) pricing is problematic:
- It applies broadly across all agents and sites—there’s no scoping by site, agent, or workload.
- Costs can add up quickly (there is no effective way to forecast this accurately).
It’s unclear what content an agent is referencing. While they begin by drawing from a site or document library, they can be extended to pull data from other locations. Without proper governance, this becomes impossible to track—especially when users with Edit rights can build them freely.
Once an agent is extended with Copilot Studio, it falls under the Power Platform governance model, which adds another layer of complexity. The agent is no longer managed solely in SharePoint, creating a hybrid governance issue.
To make SharePoint Agents viable for large-scale, enterprise deployment, we recommend the following actions:
- Introduce a tenant-level toggle to disable/enable SharePoint Agents until we are ready.
- Enable selective rollout to specific sites only.
- Limit agent creation permissions to site owners or designated individuals.
- Allow customization of the default Site Agent to restrict scope and relevance.
- Fix the approval logic so only site owners can approve and can be un-approved via the UI.
- Don’t move the agent when it’s approved. Instead, signify an un-approved vs. approved agent with the file icon (as an example).
- Allow the site owner to manage both approved and recommended agents. If an agent shows as recommended (not sure what the algorithm is for determining this) the site owner should be able to mark it as not recommended.
- Remove the “Agent” option from UI menus (Context menu and Toolbar).
- Scope PAYG pricing by agent, site, or workload, and offer detailed cost tracking.
- Align governance and licensing for Copilot Studio-integrated agents.