One of the most underestimated tools in the Microsoft 365 Copilot ecosystem right now is Agent Builder: the in-context agent creation experience embedded directly inside Copilot Chat. It sits quietly in the right rail of the M365 Copilot app, and if you haven’t explored it carefully yet, there’s a good chance you’ve been reaching for heavier tooling when you didn’t need to.
This post is a technical deep dive aimed at architects. We’ll cover what Agent Builder actually is under the hood, how it relates to the broader agent hierarchy, what it can and can’t do, the knowledge source architecture, the governance and sharing model, the licensing implications, and most critically, when it’s the right tool versus when you need to graduate to Copilot Studio.
What Agent Builder Is (and What It Isn’t)
Agent Builder is Microsoft’s in-context, no-code entry point for creating declarative agents within the M365 Copilot experience. You access it directly from the M365 Copilot app: look for “New Agent” under the Agents section in the navigation pane, or “Create an agent” in the right rail of Copilot Chat.
The key architectural point to internalise: Agent Builder creates declarative agents. It does not create custom engine agents, it does not expose an orchestration layer, and it does not allow you to swap out the underlying LLM. What it does is let you configure a specialised version of M365 Copilot: define what it knows, how it behaves, and who it talks to.
The agent you build here runs entirely on Copilot’s own AI infrastructure, model, and orchestrator. Your job is to shape the experience via instructions, knowledge sources, and starter prompts: not to build processing logic.
Formerly Known As…
You’ll see Agent Builder referred to in older documentation as “Copilot Studio Lite” or the “lightweight builder experience.” Microsoft has since unified the naming, but understanding the lineage matters architecturally: Agent Builder was purpose-built as a simplified front-end for creating declarative agents that live entirely within the M365 Copilot surface, without requiring any Power Platform involvement or Copilot Studio subscription overhead.
The Build Experience: Natural Language First
Agent Builder offers two paths to create an agent:
1. Natural language (Describe tab): the recommended path. You describe your agent in plain language (“Build me a SharePoint intranet expert that answers HR policy questions and surfaces relevant documents”) and Copilot generates the agent name, description, system instructions, suggested knowledge sources, and starter prompts for you. You can then refine everything conversationally: “Update the agent to also handle IT helpdesk queries” or “Change the tone to be more formal.”
2. Manual configuration (Configure tab): a direct form interface where you explicitly set the agent name, description, instructions, knowledge sources, capabilities, and starter prompts yourself. Use this if you want precise control over instructions from the outset, or if natural language authoring isn’t available in your tenant’s configured language.
Both paths land you in the same declarative agent manifest. There’s no architectural difference in the resulting agent: only in how you got there.
Knowledge Sources: The Architecture That Matters Most
The knowledge source model is where architecture decisions in Agent Builder have the most impact on agent quality. Understanding what you can ground an agent against, and the constraints that apply, is essential.
What’s Available
Agent Builder supports the following knowledge source types (availability varies by licence: see Licensing below):
- SharePoint sites and libraries: the primary enterprise knowledge source. Ground the agent against specific SharePoint URLs to scope it to relevant content. The agent retrieves content within the user’s existing permissions: it cannot surface documents the user doesn’t already have access to.
- Microsoft 365 Graph Connectors: if your tenant has Copilot connectors configured (e.g., for ServiceNow, Confluence, or custom data sources), those connector indexes are available as knowledge sources, subject to admin policy.
- Teams chats: personal Teams chat messages can be included as a knowledge source, enabling agents grounded in conversational context.
- Outlook email: the agent can reason over the user’s email data.
- Web content: public website URLs can be added as knowledge sources, subject to the tenant’s “Allow web search in Copilot” admin policy. If an admin has disabled web content at the tenant level, this toggle remains visible in the UI but doesn’t work: the admin policy takes precedence.
- Uploaded files: users can upload files directly as knowledge sources (doc/docx, ppt/pptx, xls/xlsx, pdf, txt, csv). The maximum is 20 files, with size limits of 512 MB for pptx/pdf/docx and 150 MB for other formats. Critically, only the text content of uploaded files is used for grounding: embedded images are not extracted. Uploaded files are stored in tenant-owned SharePoint Embedded (SPE) containers, manageable from the SharePoint Admin Center.
Permissions and Sensitivity Label Inheritance
This is the governance behaviour architects need to understand clearly.
The agent respects the calling user’s permissions at query time. If User A builds an agent grounded in a SharePoint library and shares it with User B, User B can only get answers based on content they have permission to read. The agent does not run as the creator’s identity: there is no privilege elevation.
For uploaded file knowledge sources, sensitivity labels are inherited. The agent is automatically assigned a sensitivity label based on the highest-sensitivity label present across its uploaded knowledge sources. A user who doesn’t have permission for that label cannot open the agent. This label-based access control applies on top of the standard sharing model.
Capabilities Beyond Knowledge
Beyond knowledge grounding, Agent Builder lets you enable specific capabilities in the Configure tab:
- Code interpreter: enables the agent to solve complex maths problems, analyse structured data, and generate visualisations. Useful for agents that need to process numerical data or tabular content on demand.
- Image generation: enables the agent to generate images from natural language prompts within a conversation.
- Starter prompts: up to 10 suggested prompts that appear when a user opens the agent, guiding them towards the agent’s intended use cases. These are particularly important for driving adoption: a well-designed set of starter prompts dramatically reduces the “I don’t know what to ask” friction for end users.
What you can’t do in Agent Builder is add Actions: Power Automate flows, API calls, or external system integrations. If your scenario requires the agent to write back to a system, trigger a workflow, or call an external API, Agent Builder is not sufficient and you need Copilot Studio.
The Sharing and Lifecycle Model
Once built, you have several distribution options:
Personal use: the agent is available only to you in your Copilot Chat experience. This is the default state before any sharing occurs.
Share via link: you can generate a sharing link that gives other users in your organisation access to the agent. Recipients can use the agent in their own Copilot Chat. They cannot modify the agent’s configuration unless they are the creator.
Organisational publishing: for broader deployment, agents built in Agent Builder can be published through the Microsoft 365 admin centre. Admins can make agents available to the whole organisation or specific user groups, and can block or remove agents that are deemed non-compliant or unsafe.
Upgrade Path to Copilot Studio
There is a deliberate one-click upgrade path from Agent Builder to Copilot Studio. When your agent has outgrown Agent Builder’s capabilities (you need Actions, more complex orchestration, additional channels, or advanced connectors), you can promote it to a full Copilot Studio agent without rebuilding from scratch. The manifest carries over. This is the intended architectural progression: build quickly in Agent Builder, graduate to Studio when the use case demands it.
Licensing: What You Get and When It Costs More
The licensing model for Agent Builder agents has two tiers that architects need to design around from the start:
Included with M365 Copilot licence (no additional cost): Declarative agents grounded in instructions and public website content are available at no additional cost within the M365 Copilot licence. Building and using agents via Agent Builder is covered under the standard licence.
Metered consumption (pay-as-you-go): Agents that access shared tenant data (SharePoint content, Graph Connector indexes, Teams chats, email) are billed based on metered consumption. These agents are off by default for Copilot Chat users. To enable them, admins must configure either pay-as-you-go billing through the Microsoft 365 Admin Center, or allocate prepaid capacity through the Power Platform Admin Center against a Copilot Studio subscription.
The practical implication: an agent grounded only in a public website is free to use. An agent grounded in your SharePoint intranet consumes metered credits. Design your knowledge source strategy accordingly, and make sure your billing setup is in place before users start creating SharePoint-grounded agents at scale.
Admin Governance Controls
From the Microsoft 365 Admin Center, administrators have the following controls over Agent Builder and the agents it produces:
- Enable/disable Agent Builder: admins can turn off the Agent Builder experience entirely for the tenant, preventing users from creating new agents.
- Web content policy: the “Allow web search in Copilot” policy controls whether web URLs can be used as knowledge sources in agents. This is a tenant-wide control that overrides the in-agent UI toggle.
- Agent inventory: the M365 Admin Center’s Agents page shows all shared agents in the tenant, including creator, creation date, host products, and availability status. Admins can search, filter, block, or remove agents.
- Shared agent lifecycle: admins can view agents shared by creators and take lifecycle actions, including blocking agents that don’t meet policy requirements. Ownerless agents (where the creator has left the organisation) can be identified and managed.
- SPE container management: uploaded file knowledge sources land in SharePoint Embedded containers. Admins can manage these from the SharePoint Admin Center or via PowerShell, giving full visibility and control over the underlying storage.
When Agent Builder Is the Right Tool (and When It Isn’t)
Based on the capability model above, here’s the decision logic:
Use Agent Builder when:
- The use case is entirely within the M365 data perimeter (SharePoint, Teams, email, Graph Connectors)
- No write-back or external API integration is needed
- The agent will be consumed within the M365 Copilot surface (not Teams bots, external portals, or custom apps)
- Speed of delivery matters: Agent Builder agents can go from idea to shared within minutes
- The creator is a business user or power user, not a developer
Graduate to Copilot Studio when:
- The agent needs Actions: Power Automate flows, external API calls, write operations
- You need to deploy to additional channels (Teams bot, SharePoint embedded agent with custom UI, external website)
- The scenario requires multi-agent orchestration or conditional logic
- You need fine-grained control over system instructions that exceed what Agent Builder exposes
- The agent needs to trigger proactively (event-driven, scheduled) rather than purely responding to user queries
The wrong answer is building a Copilot Studio custom engine agent for something Agent Builder handles perfectly. Custom engine agents are expensive to build and maintain. Agent Builder agents are production-grade, fully governed, and require zero engineering investment.
A Practical Starting Point
If you’re advising an organisation on where to start with M365 agents, Agent Builder is the answer for the majority of knowledge-and-retrieval use cases. The typical journey:
- Identify a high-value, high-frequency information retrieval use case (IT policy queries, HR FAQ, project status summaries from Teams transcripts).
- Ensure the relevant SharePoint content is well-organised and has appropriate permissions. Agent quality is directly proportional to the quality and structure of the knowledge sources.
- Build the agent in Agent Builder using natural language on the Describe tab. Test thoroughly on the Try it tab before sharing.
- Enable metered consumption billing if the agent accesses SharePoint or tenant data.
- Share via link for a pilot group before broader organisational publishing.
- Monitor usage via the Copilot Dashboard in the M365 Admin Center.
The platform is mature, the governance model is solid, and the upgrade path to Copilot Studio is there when you need it. There’s no reason to wait.
Got questions about your organisation’s agent strategy? Drop a comment below or find me on LinkedIn.