Why You Should Create Custom Agents for M365 Copilot

If your organization is paying for Microsoft 365 Copilot licenses and your people are just using the default chat experience, you’re leaving money on the table. And honestly? You’re probably part of the reason the adoption numbers look so rough right now.

Let me explain… the fix is straightforward: stop relying on the generic Copilot chat and start building custom agents tailored to your specific business scenarios. Custom agents let you bake in instructions, point at specific knowledge sources, and connect to external systems so your people get repeatable, useful results instead of generic AI responses.

The default Copilot experience isn’t cutting it

Earlier this year, the Wall Street Journal published a piece that, to be blunt, was not a good look for Microsoft. The article cited a survey of 150,000 users conducted from July 2025 through January 2026, and the numbers were telling. The percentage of Microsoft 365 Copilot subscribers using the product as their primary AI tool dropped from 18% down to 11%. Users cited poor experience and restrictive limits as reasons they moved to alternatives like ChatGPT and Gemini.

Here’s the thing that really jumped out at me: some companies are using only about 10% of the Copilot seats they’re paying for. Think about that for a second. You’re dropping $21-$30 per user per month on Copilot licenses and only a fraction of people are actually using them. If you’re in leadership looking at those renewal numbers coming up, that’s a massive churn risk indicator.

I’ve been seeing this firsthand. When I ran a workshop in Dublin back in December with 120 attendees, you could pick up on the frustration from some of the attendees. People aren’t satisfied with the results they’re getting. But here’s what I told them, and what I’ll tell you: the problem isn’t that Copilot is bad. The problem is that a generic chatbot isn’t equipped to handle your specific business scenarios.

Why generic chatbots fall short

When you’re using Microsoft 365 Copilot, or ChatGPT, or Claude, or Gemini, or any other AI chatbot out of the box, you’re using the default agent. It’s a general-purpose tool that tries to be helpful across every possible scenario. And that’s exactly the problem.

I like to think about it this way. Would you walk up to the receptionist at the front desk of a large corporation and ask them to help you with a VBA script error in Excel? Of course not. You’d go find someone on the Excel team who actually knows that stuff. You’d want to talk to an expert with the right context.

That’s what creating a custom agent gives you. Instead of a general-purpose assistant that knows a little about everything, you get a purpose-built expert that knows exactly what it needs to about your specific scenario.

Have you ever found yourself doing any of these things?

• Typing the same setup prompt every single time you start a conversation: “You are an expert SEO consultant following Google’s best practices, help me write the title and description for this article…”
• Referencing the same knowledge sources repeatedly: “Make sure you refer to the corporate PTO policy document…”
• Telling Copilot not to do something over and over: “Don’t use data from that list, the team maintaining it has no idea what they’re doing…”
• Wishing Copilot could connect to an external system or take an action on your behalf

If any of that sounds familiar, you need a custom agent.

What a custom agent actually gives you

A custom agent lets you create a repeatable, specific, tailored experience for a particular business scenario. You’re essentially narrowing down (or expanding) the chatbot’s knowledge to specific things, and coaching it with your own instructions about what it should and should not do.

Let me give you a real example from my own business. I run a training company, and occasionally a student will contact me because they have two accounts in my system: their personal Gmail and their corporate email. Merging those accounts means I need to check my CRM, my payment processing in Stripe, QuickBooks, my membership system, and my email marketing platform. That’s five different systems I need to search through for every email address they’ve used.

Or I go to my merge agent, give it a list of email addresses, and let it do the work. It knows where to look, it knows which systems support merging and which require a copy-and-delete workflow. I told it exactly what to do, pointed it at the data sources it needs, and now a task that used to eat 30 minutes of my day takes about 30 seconds.

That’s the power of a custom agent.

The pitch for your organization

If you’re trying to justify the investment in building custom agents to your leadership team, here’s how I’d frame it: you’re already paying for Microsoft 365 Copilot. The question is whether you’re getting real value from that investment.

The data from that Wall Street Journal piece backs this up. People aren’t abandoning AI. They’re abandoning generic AI experiences that don’t deliver results specific to their work. When you create custom agents tailored to your organization’s business processes, you transform Copilot from a nice-to-have into an indispensable tool that people actually want to use.

That’s what drives adoption. That’s what reduces churn risk. And that’s what turns your Copilot investment from an expense into a competitive advantage.

Your agent options

… it’s not as binary as Microsoft suggests

Here’s where I need to call Microsoft out a little. To be clear, I think Microsoft is pretty disingenuous when they present your agent-building options. They’ll show you a slide that essentially says: “Use Copilot Studio for everything, and if that’s not enough, go build your own full AI stack from scratch.” As if there’s nothing in between.

That’s not accurate.

Your options for creating agents within the Microsoft 365 Copilot ecosystem actually break down into four approaches, ranging from simple to powerful: SharePoint agents (point at a document library), Agent Builder (lightweight visual builder inside Copilot), Copilot Studio (full low-code/no-code builder in Power Platform), and declarative agents (pro-code option built with VS Code and the M365 Agents Toolkit).

Here’s how each one works:

SharePoint agents are the simplest option. You point an agent at a document library, give it a name and some instructions, and that’s it. No skills, no actions, no way to package or deploy it broadly. But for a non-technical user in the marketing department who just needs an agent to answer questions about the files in their library? It might be all they need.

Agent Builder gives you a bit more functionality. Think of it as a lightweight version of Copilot Studio, available right inside of Copilot when you create a new agent. You get access to some Power Automate flows and connectors, and some basic sharing capabilities. It’s a step up, but still fairly limited.

Copilot Studio is Microsoft’s full low-code/no-code agent builder with the most features in a visual designer. Triggers, autonomy, a wide range of connectors and capabilities. But keep in mind that everything in Copilot Studio lives in Power Platform and Dataverse, which is a fundamentally different world from the rest of Microsoft 365 (M365). That distinction matters more than you might think, and I’ll explain why in a moment.

Declarative agents are what I’d call the pro-code-minded option, though calling it “pro code” is a stretch. You build them using Visual Studio Code (VS Code) with the Microsoft 365 Agents Toolkit (ATK), and at their core, they’re just JSON and text files. No code required for most scenarios. If you want to connect to external APIs, you’ll write some YAML to describe those endpoints, but you can authenticate and talk to Microsoft Graph without deploying a single line of code.

Each of these options has trade-offs around capabilities, knowledge access, deployment scope, and the skill set required to build them. There’s no universal “right answer” here since it’s a conversation that depends on your specific requirements.

The hidden stuff Microsoft doesn’t tell you

Here’s where it gets really interesting. And by interesting, I mean the part where you need to pay attention because this will save you a ton of frustration.

Not all orchestrators are created equal. When you create an agent, the tool you use determines which orchestrator processes your prompts. Declarative agents built with the ATK in VS Code use Microsoft’s first-class orchestrator (internally called “Sydney”), the same one that powers Microsoft’s own agents like Researcher and Analyst. Agents built with Copilot Studio or Agent Builder use a different orchestrator.

Why does this matter? I had a conversation with someone who told me Copilot was only returning three SharePoint documents when they knew there were more. They’d built their agent in Copilot Studio. I had them rebuild the exact same agent, same instructions, same knowledge sources, as a declarative agent. Ten files came back. Same agent, different orchestrator, dramatically different results.

The semantic index access is different too. The Copilot Studio orchestrator accesses the semantic index through something called the retrieval API, which has its own limits. Declarative agents have more direct access to the semantic index without those same constraints.

External connections work differently. If you create a Microsoft Graph connector in the Microsoft Admin center, that content is available to declarative agents, Microsoft Search, and the default Copilot experience. But Copilot Studio can’t see it. And if you create connections in Copilot Studio, they live in Dataverse and aren’t available to the rest of your M365 tenant. There’s a significant boundary between Power Platform and M365 that catches a lot of people off guard.

New features hit declarative agents first. Microsoft regularly adds capabilities to the Sydney orchestrator before they’re available in Copilot Studio, but they don’t announce them until Copilot Studio catches up. If you know where to look in the JSON schemas, you can start using new capabilities well before they’re officially documented.

So where do you start?

The answer depends on your organization, your team’s skill set, and what you’re trying to accomplish. There’s no flowchart that gives you the perfect answer (despite what Microsoft’s marketing materials might imply).

Extending Microsoft 365 Copilot: Declarative Agent Alternative to Copilot Studio

The overlooked middle-ground solution for Microsoft 365 Copilot extensibility: declarative agents offer powerful capabilities beyond Copilot Studio without custom code.

https://www.voitanos.io/blog/microsoft-365-copilot-extensibility-options-declarative-agents-copilot-studio/

But I’ll tell you this: if you’re a developer or part of a development team building agents for enterprise use, I’d strongly encourage you to look at declarative agents. You get the most capable orchestrator, the best access to your organizational data, true source control with proper versioning, and a real software development lifecycle (SDLC). These are the same types of agents Microsoft builds internally, and there’s a reason for that.

Want to learn how to build declarative agents?

If you’re a developer looking to get hands-on with building declarative agents for Microsoft 365 Copilot, I have an upcoming virtual workshop that walks you through the entire process using VS Code.

The next cohort of my live workshop, Build Declarative Agents for Microsoft 365 Copilot, is April 28-30, 2026. This is a multi-day, hands-on workshop held , where you’ll learn how to create, configure, and deploy declarative agents using the Microsoft 365 Agents Toolkit. We’ll cover everything from custom instructions and knowledge configuration to connecting to external APIs and packaging your agents for enterprise deployment.

Workshop: Build Declarative Agents for Microsoft 365 Copilot

Get the most from your Microsoft 365 Copilot investment with declarative agents, bringing data from LOB systems, and apply instructions for unique scenarios.

https://www.voitanos.io/workshop-microsoft-365-copilot-build-declarative-agents/

For anyone looking to quickly grasp the intricacies of declarative agents for Microsoft 365 Copilot, Andrew's "Build Declarative Agents" course on Voitanos is an absolute must. Andrew provides an incredibly detailed exploration of practical use cases, crucial decision-making processes, and the hands-on execution of building agents. The course is packed with valuable information, prompting me to revisit the material multiple times. Thanks to Andrew's expert guidance, I'm now confidently on track to build my first agent this quarter. Highly recommended!

Mohammed Rehmatullah

The best part? Early bird pricing is available right now, saving you $50 off the regular price. These workshops fill up, and the early bird pricing won’t last forever, so if this is on your radar, I’d grab your seat sooner rather than later.

Register now and save $50 with early bird pricing!

What do you think? Are you already building custom agents for Copilot, or are you still trying to figure out where to start? I’d love to hear about your experience in the comments.

author

Andrew Connell

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 22-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.

Feedback & Questions