Microsoft 365 Copilot Agents - What Small Businesses Actually Need to Know
Microsoft is using the word 'agents' increasingly in its Copilot marketing, and the distinction between Copilot and agents is creating genuine confusion. They are related but meaningfully different. Understanding what agents are, what they can access, and what governance they require is important for any business planning a Copilot deployment - because agents introduce risks that base Copilot does not.
Copilot versus agents - the actual difference
Microsoft 365 Copilot, in its base form, is an AI assistant embedded in Microsoft 365 apps. You ask it a question in Teams, Outlook, Word, or the Copilot chat interface, and it responds using information from your Microsoft 365 environment. It responds to you directly, in the moment you are using it. It does not act without being asked.
Agents are different. An agent is an AI system configured to perform specific tasks, often autonomously, using a defined set of tools and data sources. An agent can be triggered by an event rather than a human question. It can take actions - creating files, sending emails, updating records - not just return information. It can be configured to run on a schedule or in response to a trigger rather than waiting to be asked.
Put simply: Copilot answers your questions. Agents act on your behalf.
Copilot vs agents at a glance
| Microsoft 365 Copilot | Copilot Agents | |
|---|---|---|
| Triggered by | A user asking a question | A user, an event, or a schedule |
| Actions | Returns information and drafts | Can take actions in connected systems |
| Data access | What the querying user can access | What the agent is configured to access |
| Autonomy | Fully user-directed | Can operate with minimal human involvement |
| Built by | Microsoft (built-in) | Microsoft (prebuilt) or custom-built |
| Governance requirement | Permissions and sensitivity labels | Permissions, labels, and agent-specific scoping |
Types of agents available in Microsoft 365
- 01
Microsoft-built agents
Microsoft ships several agents as part of the Microsoft 365 Copilot licence. These include agents for SharePoint (finding information across your document libraries), Teams (summarising meetings and managing follow-ups), and Planner (tracking tasks and priorities). These agents are ready to use with minimal configuration and operate within the boundaries of the user's existing permissions.
- 02
Declarative agents (custom, no-code)
Declarative agents are built using Microsoft Copilot Studio or SharePoint without writing code. You define the agent's purpose, its data sources, and the instructions it follows. A simple example: a 'HR Policy Agent' configured to answer employee questions using only the HR policy documents stored in a specific SharePoint library. Declarative agents are the right starting point for most small businesses.
- 03
Custom engine agents
Custom engine agents are fully custom-built AI applications that use Microsoft's development frameworks (Azure AI, Semantic Kernel) and integrate with Microsoft 365 as a surface. These are developer-built, require Azure infrastructure, and are generally beyond the scope of most small business deployments. They represent the ceiling of agent capability rather than the starting point.
What agents can access - and why this matters more than with Copilot
With base Copilot, data access is constrained by the querying user's permissions. The user can only get back content they already have access to. This is a meaningful natural limit.
Agents can be configured with their own access scope, separate from the querying user's permissions. A SharePoint agent can be given access to specific SharePoint sites regardless of whether the user asking the question has those permissions directly. An agent configured to access your full document repository has access to everything in that repository, not just what the current user can reach.
This makes agent data access a more deliberate governance decision than base Copilot access. You are not relying on existing permissions as a natural guardrail - you are actively configuring what the agent can reach, and that configuration needs to be intentional.
An agent configured to access 'all SharePoint content' in a tenant with unreviewed permissions is a significant exposure. The agent will traverse ownerless sites, sites with Everyone access, and all the accumulated permission debt in the environment. Agent deployment should follow, not precede, permission remediation.
What small businesses should actually do with agents
The most practical agent use cases for small businesses are narrow and well-defined. An agent that answers questions about your HR policies using a specific SharePoint library. An agent that summarises project status from your Planner boards. An agent that routes incoming support requests to the right team member. These are low-risk deployments with clear scope.
The mistake is deploying broad agents early - an agent with access to 'everything' asked to 'help with anything'. Broad scope creates broad risk, and the governance requirements for a broad agent are substantial.
Good starting agent use cases for SMBs
- HR policy agent - answers employee questions using only the HR policy document library
- Onboarding agent - guides new starters through their first week using onboarding documents and checklists
- Meeting summary agent - summarises Teams meeting recordings and creates action item lists in Planner
- Project status agent - pulls together status across Planner boards for a project summary
- Sales enablement agent - answers questions about products, pricing, and case studies using the sales library
Governance requirements for agent deployment
Agents require more deliberate governance than base Copilot for three reasons: they can act (not just respond), they can be given data access beyond the querying user's permissions, and they can operate autonomously.
Before deploying any agent, you should be able to answer these questions: What data sources is this agent accessing? Who configured those access permissions and when? What actions can the agent take and in which systems? Who is responsible for reviewing agent outputs? How is the agent's scope documented and approved?
For a declarative agent built on a specific SharePoint library, these answers are simple. For a broad agent with access to multiple systems, they require formal documentation and approval.
The licence question
Building and running agents requires a Microsoft 365 Copilot licence (AUD $68.50 per user per month at current pricing) for the users interacting with the agent. Building agents in Copilot Studio uses 'messages' that are consumed from a capacity pool - each licence includes 25,000 messages per month across your tenant, with additional capacity purchasable.
For small deployments with a clear use case and limited message volume, the included capacity is typically sufficient. For broad deployments or high-volume scenarios, model the message consumption before committing.
Sources & accuracy
Last reviewed: 5 October 2026 · Microsoft product capabilities, licensing and configuration options change regularly. Verify current details at learn.microsoft.com.
Next step
Copilot Readiness Assessment
The Copilot Readiness Assessment covers both base Copilot and agent deployment readiness - reviewing your permission environment, governance posture, and identifying the agent use cases most appropriate for your business.
Learn more