8.3 Build, Buy, or Extend Copilot
Key Takeaways
- Microsoft’s July 22, 2026 AB-731 skills list includes "Identify when to build, buy, or extend, including the Microsoft 365 Copilot extensibility framework": buy Copilot as shipped, extend it with knowledge and skills, or build a custom engine / Foundry application when extensibility cannot meet the process.
- Buy means licensed users work in Microsoft 365 Copilot, Copilot Chat, Researcher, Analyst, and in-app Copilot without adding connectors, plugins, or custom agents.
- Extend means plugins and actions, Microsoft 365 Copilot connectors (synced into Graph or federated), declarative agents, and Copilot Studio agents that add instructions, knowledge, and tools while still using Copilot’s orchestrator and models.
- Build means a custom engine agent or Microsoft Foundry app with your own orchestrator, models, hosting, and Responsible AI burden when Copilot’s orchestrator, channels, or models cannot run the process.
- Leaders decide with four criteria—time-to-value, data gravity, security and compliance inheritance, and maintenance staffing—not with a preference for writing code; AB-731 does not expect candidates to write code.
8.3 Build, Buy, or Extend Copilot
Quick Answer: Buy Microsoft Copilot and use it as shipped. Extend it with the Microsoft 365 Copilot extensibility framework: connectors, plugins / actions, declarative agents, and Copilot Studio agents that add knowledge and tools while Copilot still hosts the model and orchestrator. Build a custom engine agent or Microsoft Foundry application when that framework cannot meet the process—custom orchestration, specialty models, extra hosting, proactive autonomy, or channels outside Copilot. Decide with time, data, security, and maintenance. Do not write code for this exam; name the decision.
Microsoft Learn’s extensibility documentation is the owner page for this skill. Microsoft 365 Copilot already helps users query data and draft in the flow of work. Organizations still need extra knowledge, extra skills, and sometimes an entirely different engine. Extending Copilot is how you keep users in Copilot. Building is how you leave Copilot’s engine when you must.
Buy: use Copilot as it ships
Buy is not “never configure anything.” It is “the process is already a Copilot process.” Licensed users draft in Word, summarize in Teams, analyze a workbook with Analyst, or commission a cited research pack with Researcher. You assign Microsoft Copilot licenses (Microsoft’s licensing article describes Copilot as an add-on to eligible Microsoft 365 plans; Copilot Chat web grounding can exist without the same work-grounding license). You set tenant basics: privacy, web search, agent blocks. You do not invent a connector, plugin, or custom agent for a job Copilot already does.
Buy is the right first answer when:
- The artifacts are already in Microsoft 365 and the signed-in user is allowed to see them.
- The output is a document, mail, meeting recap, spreadsheet insight, or research report—not a write-back to an unsourced system of record.
- Time-to-value must be days, not a release train.
- Security wants Microsoft 365’s existing boundary, DLP, and Copilot’s documented non-training stance on Graph-accessed data, without a new hosted model you must attest.
In practice: An HR vice president wants offer-letter drafts from a standard template in Word. That is buy. Building a Foundry app to draft offer letters is theater unless legal has a requirement Copilot cannot meet.
Microsoft also ships prebuilt agents (Microsoft and partners) for functions such as onboarding, IT helpdesk, sales, and service. Microsoft’s extensibility overview says you can deploy them as-is or further customize them. Deploying a prebuilt Sales Agent with light knowledge is still closer to buy / light extend than to a custom engine.
Extend: stay on Copilot’s orchestrator, add knowledge and skills
Microsoft’s Extend Microsoft 365 Copilot overview lists the extensibility kit:
- Agents that retrieve insights and act for users.
- Microsoft 365 Copilot connectors that bring organizational data into Copilot and Microsoft Search.
- Microsoft Work IQ API for applications that reason over Microsoft 365 work context inside the trust boundary.
- Microsoft 365 Copilot APIs (Retrieval, Search, Chat, Interaction Export, AI Meeting Insights) when you need Copilot capabilities inside another app—still not “write a model from scratch.”
Microsoft’s Agents for Microsoft 365 Copilot page splits agents into two families. Extend in AB-731 language is almost always the first family:
Declarative agents configure Copilot for a scenario. You provide:
- Custom instructions (purpose and constraints).
- Custom knowledge (Teams, SharePoint, OneDrive, Copilot connectors, uploaded files).
- Custom actions (APIs / plugins for live systems).
They use Copilot’s orchestrator and foundation models. No extra hosting of the brain. Tooling can be low-code (Agent Builder, Copilot Studio) or pro-code (Microsoft 365 Agents Toolkit). They run in Microsoft 365 Copilot and apps such as Teams, Word, Excel, and Outlook. They inherit Microsoft 365 compliance, Responsible AI, and security patterns Microsoft documents for Copilot. Admin visibility and distribution sit in the Microsoft 365 admin center.
Connectors widen knowledge:
- Synced Copilot connectors ingest and index external content into Microsoft Graph (the former Graph connectors name still appears in Graph docs).
- Federated connectors retrieve in real time using Model Context Protocol (MCP) without indexing into Graph.
Microsoft’s Copilot Studio knowledge article (connectors versus Power Platform connectors) is the leader distinction: Copilot connectors are best for broad, searchable knowledge with semantic indexing and citations across Copilot and Search (ServiceNow KB, Jira, Confluence, GitHub). Power Platform connectors are best for live facts and transactions—“what is ticket 1234?” or “create a case”—including custom OpenAPI connectors.
Plugins / actions: Microsoft’s extensibility FAQ says an action is a single API call (close ticket 1234); a plugin is a set of functions. Actions give declarative agents skills. Copilot Studio can build actions from Power Platform connectors; Agents Toolkit can package API plugins from an OpenAPI definition.
Copilot Studio is also how many organizations extend Microsoft 365 Copilot: Microsoft’s Studio overview says you can customize Copilot with instructions, tools, and knowledge, or create a standalone custom chat experience. Studio is low-code; it is still extend when the agent rides Copilot’s chat harness or Copilot’s orchestrator. Microsoft’s agents-overview table is explicit: Copilot Studio can even host some custom engine patterns—those count as build once you bring your own orchestrator or models rather than declaring on Copilot’s.
Microsoft’s planning guide maps business needs to extensibility approaches:
| Business need (Microsoft’s planning guide) | Extensibility approach |
|---|---|
| Better decisions, summarizations, recommendations | Enhance Copilot’s reasoning (instructions, scoped agents) |
| Organizational knowledge in databases, documents, or APIs | Let Copilot access and use external data (connectors, knowledge) |
| Reduce manual tasks | Automated workflows |
| Secure Copilot capabilities inside your own applications or custom agents | Microsoft 365 Copilot APIs |
When extend is enough
Extend when the user should stay in Copilot or Teams, the model Copilot already uses is good enough, and the gap is what it knows or what it can call. Microsoft’s examples: IT self-help on SharePoint; a hospital declarative agent on policies plus an API plugin for live order status; a project agent that reads Jira and GitHub through connectors and plugins.
Microsoft’s licensing FAQ for developers (not an invitation to invent prices): you can build declarative agents grounded on web search with limited capabilities without a Microsoft 365 Copilot license; with that license you do not need extra licenses for declarative agents that use Copilot connectors and plugins. Grounding Studio agents on organizational data may need a Studio license or consumption metering. Custom engine agents built with Teams SDK are billed on Azure consumption, not a Copilot license, per that FAQ. Teach the idea—extend can have license and meter implications—not a dollar figure Microsoft does not put on the AB-731 page.
Build: custom engine and Microsoft Foundry when extensibility cannot meet the process
Build means you no longer only configure Copilot. You supply custom orchestration, custom models, extra hosting, and you own Responsible AI, security, and compliance that declarative agents would have inherited.
Microsoft’s agents-overview table is the decision gate:
| Feature | Declarative (extend) | Custom engine (build) |
|---|---|---|
| Use case | Focused Copilot scenarios | Complex workflows or advanced integrations |
| Customization | Limited to Copilot’s orchestrator and models | Fully customizable models and orchestration |
| Proactive interactions | User-initiated | Can trigger without direct user input |
| Hosting | Hosted in Microsoft 365 | Extra hosting (Azure / Foundry) at additional cost |
| Compliance | Inherits Microsoft 365 Copilot standards | You must ensure compliance, RAI, and security |
Microsoft says build a custom engine agent when you need custom orchestration (loan-approval style rules and multiple credit systems), your own or domain-specific models, group collaboration around one agent, an existing assistant outside Copilot that you want to bring in, channels outside Microsoft 365, or proactive messaging.
Microsoft’s extensibility FAQ is equally blunt about Foundry: Azure AI Foundry / Microsoft Foundry is not the tool for extending Microsoft 365 Copilot’s model and orchestrator. If you want Azure AI services, Microsoft recommends custom engine agents, not declarative agents. Foundry is the build platform: agents, 10,000+ models in the catalog as Foundry currently describes it, tools, tracing, RBAC, networking. Copilot Studio is low-code inside the Copilot / Power Platform world; Foundry is the application platform.
In practice: A law firm wants a case-law model that is not Copilot’s orchestrator and must call external legal databases. That is Microsoft’s own legal research AI example: custom-trained model plus API plugins—build. A factory wants IoT sensor scoring that pages engineers in Teams when a machine drifts—build a Foundry or custom engine agent. A consultant portal that must use the Copilot Retrieval API inside a non-Copilot UI is still using Copilot capability, but the application is a build that calls APIs.
If Copilot plus connectors plus a declarative agent can complete the process, do not build. Build is how programs go over budget while users still live in Outlook.
Leader decision criteria: time, data, security, maintenance
Score the options in a steering committee. AB-731 will not grade your spreadsheet. It will grade whether you know why a CFO, CISO, and operations VP disagree.
- Time-to-value. Buy wins on days. Extend wins on weeks if a prebuilt connector or Agent Builder is enough. Build wins only when the calendar still fits a hosted application and you have makers. Microsoft’s agents overview says declarative agents are the faster / low-code path; custom engines vary from Studio to advanced pro-code.
- Data gravity. If the truth already lives in Microsoft 365, buy or a SharePoint-grounded declarative agent. If the truth lives in ServiceNow or Salesforce as documents to search, a Copilot connector (extend). If the truth is a live balance or ticket to update, a plugin / Power Platform connector (extend). If the truth is IoT, a fine-tuned industry model, or a corpus that must never enter Graph, you are often in Foundry / custom engine (build) or in Azure AI Search under a Foundry app.
- Security and compliance. Declarative agents inherit Copilot’s RAI validation and Microsoft 365 data protections Microsoft documents. Custom engines require you to staff filters, identity, network isolation, evaluation, and logging. Work IQ and Copilot APIs exist so some builds can still reason inside the Microsoft 365 trust boundary instead of copying mail to a rogue vector store. Security will often prefer extend-on-Copilot over a new hosted model until there is a hard requirement.
- Maintenance. Connectors need index quota, crawl health, and an owner. Plugins need API contracts and secrets rotation. Studio agents need instruction owners and evaluation. Foundry agents need platform engineering, model updates, tracing, and on-call. If you cannot name the maintenance team, you are not ready to build, and you may not be ready to extend either—buy and wait.
Use this ordered list in an architecture review:
- Prefer buy until a named process fails in shipped Copilot.
- Prefer extend until Copilot’s orchestrator, models, channels, or compliance inheritance actually block the process.
- Build only with an owner, a budget for hosting, and a Responsible AI plan you do not pretend Copilot will carry for you.
Legal and security scenario. Counsel wants a Copilot-looking assistant that answers only from the policy library and can fetch a live matter number from the docket system. That is extend (declarative agent + knowledge + plugin). Counsel wants a model trained on privileged case law hosted in a locked subscription with a custom planner that starts work when a filing lands—build. The CISO’s question is the same in both cases: who can see the data, who attests RAI, and who gets paged when it is wrong.
CFO scenario. Token and Copilot seat cost for buy/extend is usually clearer than a Foundry estate. Custom engines add Azure consumption Microsoft’s FAQ tells you to estimate with the Azure pricing calculator. Do not quote a fake USD fee on AB-731. Do say: build introduces a second meter.
What this skill is not
It is not a mandate to customize Copilot. It is not a mandate to use Foundry for email drafts. It is not an invitation to write Python on the exam. Microsoft’s AB-731 audience profile says candidates are not expected to write any code. Your job is to identify when to buy, extend, or build, and to use Microsoft’s names: declarative agent, custom engine agent, Copilot connector, plugin / action, Copilot Studio, Microsoft Foundry.
Official pages opened for this section
- Study guide for Exam AB-731 — skill Identify when to build, buy, or extend, including the Microsoft 365 Copilot extensibility framework
- Extend Microsoft 365 Copilot
- Microsoft 365 Copilot extensibility documentation hub
- Agents for Microsoft 365 Copilot
- Declarative agents for Microsoft 365 Copilot
- Microsoft 365 Copilot extensibility planning guide
- Microsoft 365 Copilot extensibility FAQ
- Overview of Microsoft Copilot Studio
- What is Microsoft Foundry?
- License options for Microsoft Copilot
In the buy / extend / build decision Microsoft’s Copilot extensibility docs support, which scenario is buy?
When does Microsoft’s agents overview point a leader toward a custom engine agent or Microsoft Foundry-style build rather than a declarative agent?
A hospital wants an assistant that looks like Microsoft 365 Copilot, uses Copilot’s models, answers from SharePoint policies, and calls an API plugin for live order status. Which decision is that?