Last week at the TechCon 365 conference in Atlanta, I delivered a pair of workshops on Microsoft 365 Copilot extensibility options. In addition to my workshops, I also spoke with plenty of developers at the Ask The Experts booth and co-hosting a developer’s round table.
While my focus is primarily on full-stack web and pro-code developers, I was once again surprised by how many attendees had a limited understanding of their custom agent and Microsoft 365 Copilot extensibility options.
In many of their minds, the available options were far more restricted than they actually are.
This is incredibly frustrating to me… what’s causing this misunderstanding? Could it be that Microsoft’s marketing of Copilot Studio overshadows the other options?
After sitting through several presentations from Microsoft speakers and community members, something stood out. Working on a hunch, I conducted research over several days and believe I’ve identified the root cause:
Microsoft is omitting one option, maybe deliberately, that customers should absolutely be aware of.
At best, this is simply misleading marketing. At worst, it’s doing customers a genuine disservice.
Let’s examine the problem before I share what this other option is…
Root of the problem
I found numerous slides Microsoft has used in various sessions from Ignite 2024 and Build 2025 conferences—slides that were reused multiple times last week.
Hear me out…

The use of the Copilot Studio logo in the right-hand column implies you create agents with Copilot Studio.
By including the Copilot Studio logo the agents column, it implies that’s what you use to create agents for M365 Copilot. But… it’s only one option, not the only option.
But it get worse…

Apparently the only low-code custom agent option is Copilot Studio & the other side of the spectrum is going full code solutions for commercial solutions?
This slide is even more problematic! It presents only two options: Copilot Studio and pro-code solutions. The purple Visual Studio logo misleadingly implies these are complex, compiled solutions designed for enterprise-grade AI projects. This representation simply doesn’t reflect reality.
While this slide frustrates me, it’s not nearly as troubling as the next one:

If a slide is supposed to show detailed options, it should show the breadth of your options. This one omits another option that belongs in the middle.
These detailed comparison slides carry significant weight with customers. Imagine yourself in the position of someone deciding which option to use for creating custom agents for Microsoft 365 Copilot.
The slides present two options at opposite ends of the development spectrum.
Don’t get me wrong—these aren’t bad options. But Microsoft is being disingenuous by omitting the declarative agents option from their messaging.
What’s the problem? This marketing from Microsoft and their field teams guides customers toward a false choice… even developers are misled!
Most M365 customers and developers believe they have only two choices: the low-code/no-code approach with Copilot Studio, or building completely code-based agents using Azure AI Foundry with C# or Node.js.
This is particularly frustrating because these represent the extreme ends of the spectrum… while a much better option sits right in the middle, one that Microsoft rarely mentions.
Two agent options for Microsoft 365 Copilot
When building agents for Microsoft 365 Copilot, we need to consider two fundamental approaches:
Option 1: Extending Microsoft 365 Copilot
The first approach leverages the existing Microsoft 365 Copilot technology stack.
This includes using the foundational model (including its configuration) and the orchestrator Microsoft 365 has created. The orchestrator handles the critical workflow: it takes the user’s prompt, retrieves necessary information from your organization’s data, sends this to the LLM for generating responses or completing tasks, and finally delivers the results back to the end user. This is the “extensibility” approach where you extend how Microsoft 365 Copilot works.
This extensibility approach doesn’t mean pushing Copilot beyond its limits. Rather, it means using the existing stack to create more focused, scenario-specific agents. These agents can be limited in what knowledge they access, what actions they perform, and what instructions they follow, unlike the general-purpose Microsoft 365 Copilot app most users are familiar with.

Microsoft 365 Copilot - Custom Agents by Extensibility
Microsoft provides various ways to create custom agents by extending and customizing the Microsoft 365 Copilot platform. These options range from the simplest with less control (SharePoint Agents) to more complex with more control (Declarative Agents).
If you choose the extensibility path — leveraging the existing Microsoft 365 Copilot stack — you actually have three options: the Agent Builder app, Microsoft Copilot Studio (which I discussed earlier in this article), and Declarative Agents.
Let me explain more about the declarative agent option, as it’s the one customers are least familiar with and aware of.
Option 2: Owning your AI tech stack
The second approach involves creating your own AI infrastructure.
Here, you might use your own model, build your own orchestrator, or leverage off-the-shelf orchestration tools like Semantic Kernel (by Microsoft), LangChain, LangGraph (by LangChain), Swam (by OpenAI), or LlamaIndex. This includes cloud-native options like Azure AI Foundry, AWS Bedrock, or Google Vertex AI.
This is the pro-code approach, where you own and control the entire AI technology stack and implementation.

Create agents by implementing your own AI stack
For those who want full control with the most flexibility, you can implement your own AI tech stack. Use cloud-native platforms like Azure AI Foundry, AWS Bedrock, or Google Vertex AI. Create your own orchestrator with options like Semantic Kernel or LangChain and use existing services like Azure AI’s Agent Service or Azure AI Search.
What are declarative agents?
Declarative agents are fully supported by Microsoft. In fact, they provide the developer tools to build them!
Consider this: how do you think Microsoft creates their own first-party agents like the researcher assistant, sales assistant, or project manager assistant?
Surprisingly, they aren’t even pro-code solutions. You can build a declarative agent entirely with JSON and YAML files which positions them much closer to the low-code spectrum than you might expect.
With declarative agents, you can accomplish nearly everything possible in Copilot Studio. They even offer capabilities that Copilot Studio doesn’t support. This makes them an excellent option for both low-code developers seeking more control and pro-code developers wanting a streamlined approach.
Unlike Copilot Studio, declarative agents can be added to source control. That means you have version control & history built into your agent. In an AI world, being able to easily version and monitor changes to your agents over time measuring how your agent behaves to your changes is key. Agent development is a very iterative process and the ability to roll back or make slight modifications, all tracked in source control, is very powerful.
You aren’t limited to JSON & YAML…
If you want your declarative agent to do something that’s not possible with JSON or you want to do something very custom? That’s where the pro-code option factors in. In this scenario,
How to build declarative agents
You’ll build them using the Microsoft 365 Agents Toolkit for Visual Studio Code (ATK). It’s available as a FREE extension for VS Code:

Microsoft 365 Agents Toolkit for VS Code
At a high level, here’s how how the process works:
Step 1: Create a project with the M365 Agents Toolkit
Once you’ve installed the Microsoft 365 Agents Toolkit extension in VS Code, start by creating a new project Declarative Agent template:

Create new declarative agent project with the Microsoft 365 Agents Toolkit
This will create a declarative agent manifest JSON file that’s used to describe the agent. It includes it’s name, description, starter prompts, and pointers to the other things it can do. In this scenario, I’m creating an agent to help with personal time off (PTO) requests:
{
"version": "v1.4",
"name": "PTO Request",
"description": "Request personal time off (PTO), also known as vacation
requests, and generate a full itinerary for the requested
PTO destination.",
"instructions": "$[file('instruction.txt')]",
"capabilities": [ .. ],
"actions": [ .. ],
"conversation_starters": [
{
"title": "Vacation Request",
"text": "Apply for time off."
},
{
"title": "Vacation Request - Paris, France",
"text": "Request PTO for a long weekend in Paris starting next Friday."
},
{
"title": "PTO - Pyongyang, North Korea",
"text": "Request PTO in Pyongyang."
}
]
}
Step 2: Control how your agent works using custom instructions
Give your agent some character and define what it’s purpose is through instructions. If you’re familiar with prompt engineering, that’s where this factors in. The following instructions are a subset of the instructions
you see referenced in the above agent’s manifest’s snippet.
You will assist the user in submitting a valid personal time off (PTO)
request to their manager. The user will provide the required details. Once
the request has been submitted, you will create an itinerary for the user
for the location of their PTO.
## Instructions
1. Start by warmly greeting the user when they request PTO. Examples of PTO
requests include the following:
- "request pto"
- "vacation request"
Respond with "Sure, I can help you with your vacation request."
2. Collect the following required inputs. Try to determine the initial
request, but if they are missing or unclear, prompt the user with the
corresponding responses:
- {pto_start_date}: "When does your PTO start?"
- {pto_hours}: "How many hours of PTO do you want to take?"
- {pto_location}: "Where are you going on your vacation?"
3. Respond with "So... you want to go to..." and summarize the result of
using the PTO policy document listed as the "OneDriveAndSharePoint"
capability to check for policy restrictions for the PTO request that
starts on {pto_start_date} for {pto_hours} for an employee traveling
to {pto_location}.
Copilot Studio advocates often highlight their access to Topics & Entities features, claiming declarative agents lack these capabilities. However, as demonstrated in the second bullet point of the instructions above, you can achieve similar functionality using well-crafted instructions without needing Topics or Entities.
Notice how at the end of the instructions, the agent is directed to review the request against the company’s PTO policy?
That brings me to…
Step 3: Add or filter the knowledge your agent has access to
Just like other types of agents, you can expand or focus their knowledge to ensure they are fine tuned for a specific scenario.
In this case, the company’s PTO policy is defined in a Word document stored in a SharePoint Document library. You can control the agent’s available knowledge through the capabilities
part of the agent manifest.
For instance, the following snippet adds the unique ID of the PTO policy file in SharePoint to it’s knowledge:
{
"version": "v1.4",
"name": "PTO Request",
"description": "...",
"instructions": "$[file('instruction.txt')]",
"capabilities": [{
"name": "OneDriveAndSharePoint",
"items_by_sharepoint_ids": [{
"unique_id": "acab2bce-07b7-4a93-961a-e813b847df52"
}]
}],
"behavior_overrides": {
"special_instructions": {
"discourage_model_knowledge": true
}
},
"actions": [ .. ],
"conversation_starters": [ .. ]
}
For the OneDriveAndSharePoint
capability, you can specify a specific file as I’ve done, or all files in a document library, or all files in all document libraries in a site, or all files in document libraries in all sites within a site collection!
You aren’t limited to this one capability either. Other options include Dataverse tables, web search, Microsoft Designer for creating images, and more. You even have access to knowledge sources Copilot Studio based agents don’t have access to including Copilot Connectors (formerly known as Graph Connectors), email, Microsoft Teams messages, and people in your org
Similar to Copilot Studio, I can also instruct the model to always prioritize the knowledge I specify over it’s foundational knowledge gained from it’s initial training. That’s the behavior_overrides.special_instructions.discourage_model_knowledge
setting which is by default set to false
.
Step 4: Empower your agent to talk to external systems through APIs using actions
Similar to Copilot Studio, you can add additional grounding of your prompts and even perform tasks like creating new records in your ERP system or CRM system that’s not part of your Microsoft 365 tenant.
This is done through a plugin manifest. The manifest maps functions (aka: actions) in a supported runtime, like an OpenAPI compatible REST API.
The plugin manifest is referenced in the actions
property of the agent’s manifest…
{
"version": "v1.4",
"name": "PTO Request",
"description": "...",
"instructions": "$[file('instruction.txt')]",
"capabilities": [ .. ],
"actions": [{
"id": "ptoActions",
"file": "ptoActions-plugin.json"
}],
"conversation_starters": [ .. ]
}
The plugin file then lists the supported functions the agent has access to and maps the data returned from the API to well known M365 Copilot properties (in the capabilities.response_semantics
property), including specifying an optional custom rendering of the item using an Adaptive Card:
{
"schema_version": "v2.2",
"namespace": "ptorequest",
"name_for_human": "pto-request",
"description_for_human": "PTO Request Actions",
"description_for_model": "Plugin for submitting PTO requests, looking up
available PTO hours remaining, and updating the
master staff availability list.",
"functions": [{
"name": "ptoHours",
"description": "Returns details about an employee's remaining PTO hours.",
"capabilities": {
"response_semantics": {
"data_path": "$.employee",
"properties": {
"title": "$.hours_remaining",
"subtitle": "$.description"
},
"static_template": {
"file": "adaptiveCards/listRepairs.json"
}
}
}
}],
"runtimes": [ .. ]
}
That’s it! The last step is to package up the agent in an app package (a ZIP file containing the JSON, YAML, and images) that’s deployed to your tenant!
Why declarative agents matter
Don’t get me wrong - Copilot Studio isn’t a bad option.
My point is that it’s not the only option when you want to extend Microsoft 365 Copilot. Declarative agents can be a better, more lightweight solution for many scenarios.
The more people I show the declarative agent option to, the more interested they become. It solves frustrations and limitations they have with Copilot Studio while providing more control than the no-code approach allows.
Learn More About M365 Declarative Agents in My Live Workshop!
Want to learn more about declarative agents and how you can use them to extend Microsoft 365 Copilot?
Join me for my 2-day workshop… the next cohort is coming up on September 16-17, 2025!
▶︎ Workshop: Build Declarative Agents for Microsoft 365 Copilot
I had a fantastic experience at the workshop on declarative agents! It was one of the most engaging and useful courses I've ever attended. During the 6 (actually 7) hours, we covered so much information. While I need some time to process it all, the explanations were clear, and I never felt lost. Andrew is an excellent instructor—his demos were amazing, and the code examples were just the right level of complexity. I already want to rewatch the session because of how clearly everything was explained and how inspiring Andrew's teaching was. I’m excited to start experimenting with agents and can’t wait for the next opportunity to learn from Andrew!

Antanina Druzhkina
🚀 SharePoint Developer | Creating Bug-Free Solutions that Enhance User Experience | Sharepoint, Microsoft 365, SPFx, React, Power Platform, Azure | Microsoft Certified Professional

Moving forward with Microsoft 365 agent development
Microsoft’s marketing messaging creates a false dichotomy that limits how developers think about M365 Copilot extensibility. By highlighting only the extreme ends of the spectrum, they’re doing a disservice to the developer community and missing opportunities to showcase a powerful middle-ground solution.
If you’re a low-code developer, pro-code developer, or full stack developer who’s been frustrated with Copilot Studio’s limitations but doesn’t want to build everything from scratch with Azure AI Foundry, declarative agents might be exactly what you’re looking for.
Got questions about declarative agents? Want to learn more about extending Microsoft 365 Copilot?
This is where I spend a lot of my time these days! Drop a comment below or contact me through my contact form - I’d love to help you explore your custom agent options.

Microsoft MVP, Full-Stack Developer & Chief Course Artisan - Voitanos LLC.
Andrew Connell is a full stack developer who focuses on Microsoft Azure & Microsoft 365. He’s a 21-year recipient of Microsoft’s MVP award and has helped thousands of developers through the various courses he’s authored & taught. Whether it’s an introduction to the entire ecosystem, or a deep dive into a specific software, his resources, tools, and support help web developers become experts in the Microsoft 365 ecosystem, so they can become irreplaceable in their organization.