Why Most Copilot Agent Projects Fail Before They Ship#

The problem is rarely the technology. It is almost always the preparation.

I have seen a lot of agent projects over the past year. Some shipped successfully, many didn’t. And here is the pattern I keep noticing: the ones that fail almost never fail because of a technical limitation. They fail because of things that should have been sorted out before anyone started building.

That’s frustrating, because most of these failures are entirely preventable.

The Demo Trap#

Let me start with the most common failure driver: unrealistic expectations.

We have all seen the keynote demos. Someone describes what they want in natural language, an agent gets built in minutes, it connects to enterprise data, and it delivers perfect results. The audience applauds. The executives get excited. And then someone in the organization says: “Let’s build that.”

The problem is that the demo showed the happy path of a carefully prepared scenario. It didn’t show the weeks of data preparation. It didn’t show the prompt engineering iterations. It didn’t show the edge cases that break the agent. And it certainly didn’t show the governance review that needs to happen before anything goes to production.

When teams start an agent project with demo-level expectations, they are setting themselves up for disappointment. Not because the technology is bad — it is genuinely impressive — but because the gap between a demo and a production-ready agent is much larger than most people think.

The Three Reasons Agent Projects Stall#

In my experience, agent projects that fail before shipping almost always hit one of these three walls:

1. The Platform Was Not Ready#

This one is painful because it is often outside your control. You start building an agent on a platform, and halfway through you realize that a critical feature is missing, still in preview, or doesn’t work the way the documentation suggests.

This happened a lot in the early days of Copilot Studio’s agent capabilities, and it still happens today when teams try to use cutting-edge features that are not yet generally available. The platform is evolving fast, which is great — but it also means that what worked in a demo environment last month might not be production-ready this month.

2. The Data Was Not There#

This is the one that frustrates me the most, because it is the most preventable. An agent is only as good as the data it can access. If your knowledge sources are outdated, poorly structured, incomplete, or scattered across systems without proper indexing, your agent will deliver poor results — no matter how good your instructions are.

I have seen teams spend weeks crafting perfect agent instructions, only to realize that the SharePoint library the agent is grounded on hasn’t been maintained in two years. The agent works technically. It just returns useless information.

Data quality is not an agent problem. It is a prerequisite. And it needs to be reviewed before you start building, not after.

3. The Wrong Platform Was Chosen#

The Microsoft ecosystem offers multiple ways to build agents — Agent Builder, Copilot Studio, Microsoft Foundry, the Agents SDK, and more. Each targets a different audience and a different level of complexity. Choosing the wrong platform for your use case is a recipe for frustration.

I have seen citizen developers struggle in Copilot Studio with scenarios that really needed Microsoft Foundry. And I have seen pro developers over-engineer solutions in code when a declarative agent in Copilot Studio would have been done in an afternoon.

The platform decision should be one of the first things you make — and it should be based on the complexity of your use case, not on which tool your team happens to be familiar with.

Three Things to Do Before You Build Anything#

If I could give every team starting an agent project just three pieces of advice, it would be these:

Define a clear goal and concept first. What exactly should this agent do? What is the specific use case? Who is the user? What does success look like? If you can’t answer these questions in one paragraph, you are not ready to build. Too many projects start with “let’s build an agent for HR” instead of “let’s build an agent that helps new hires find answers about onboarding policies in their first week.” Specificity matters.

Choose the right platform deliberately. Don’t default to the tool you know. Evaluate your use case against the capabilities of each platform. Does it need real-time API integrations? Does it need complex orchestration? Can it be solved with a simple declarative agent? Match the platform to the problem, not the other way around.

Review your data quality before you start. Go look at the actual data sources your agent will use. Are they current? Are they well-structured? Are there duplicates or contradictions? Is access properly configured? This review takes a day or two at most, but it can save you weeks of debugging an agent that “doesn’t work” when the real problem is the data underneath.

When Failure Is Actually Fine#

I want to be clear: not all failure is bad. If you are experimenting with cutting-edge technology — trying something that hasn’t been done before, pushing the boundaries of what the platform can do — then failure is part of the process. That is how we learn, and that is how the ecosystem moves forward.

The failure that bothers me is the preventable kind. Teams that skip the basics, get burned, and then conclude that “agents don’t work” — when the agents were never given a fair chance in the first place.

It Will Get Better#

The good news is that the failure rate for agent projects will come down over time. The platforms are maturing rapidly. The community is building up knowledge. Organizations are learning from their early experiments. Every failed project teaches someone what not to do next time.

But we can accelerate this by being honest about why projects fail. It is not because the technology is not ready. In most cases, it is because we were not ready — we didn’t define the goal clearly enough, we picked the wrong platform, or we didn’t check the data. Those are human problems, not technology problems. And human problems have human solutions.

What was the biggest lesson you learned from an agent project that didn’t go as planned?

Agent Governance Is the Next Big Bottleneck#

Everyone is building agents. But who decides what they are allowed to do?

Here’s an irony I keep seeing: organizations that don’t have agent governance in place don’t end up with chaos. They end up with nothing. Because when there are no clear rules about what people can and cannot do with agents, IT does the only rational thing — they block everything.

And I get it. If you’re responsible for security and compliance, and suddenly business users start building agents that connect to your ERP, your CRM, and your internal databases without any oversight, your instinct is to shut it down. The problem is that blocking everything is just as damaging as allowing everything. You’re just trading one risk for another.

The Real Problem Is Not Tooling#

When people talk about agent governance, the conversation usually jumps to platform features — admin centers, policies, DLP rules. And yes, those matter. But in my experience, the real bottleneck is much more fundamental: most IT departments don’t have the knowledge to think about agent governance holistically, and most organizations don’t have a dedicated person who owns this topic.

Think about it. Agent governance sits at the intersection of IT security, data governance, application lifecycle management, and business process design. That’s a lot of domains to cover. And right now, in most organizations, nobody owns this intersection. Security owns their piece. IT ops owns their piece. The business owns their piece. But nobody is looking at the full picture.

That’s how you end up with either total lockdown or total chaos. There’s no middle ground without someone actively designing it.

The Six Pillars of Agent Governance#

If I had to help an organization build an agent governance framework from scratch, these are the six areas I’d focus on:

None of these are revolutionary ideas individually. But most organizations I talk to haven’t thought through even half of them. And without all six in place, you’re flying blind.

Shadow Agents Are the New Shadow IT#

Remember when business users started spinning up their own cloud services without IT knowing about it? We called it Shadow IT, and it took years to get under control. The same thing is happening with agents right now — I’d call it Shadow Agents.

Without governance, two things happen consistently:

Teams build duplicate agents. The marketing team builds an agent for content creation. The communications team builds a different agent for the same thing. Nobody knows the other exists. You end up with redundant work, inconsistent outputs, and wasted effort.

Agents access unauthorized systems. Someone builds an agent that connects to a data source or system that IT hasn’t approved. Not maliciously — they just didn’t know they needed to ask. But now you have an agent pulling data from a system without proper access controls, and nobody in security is aware.

This is exactly the pattern we saw with Shadow IT, just on a new level. And the solution is the same: you don’t fix it by blocking everything. You fix it by creating a clear framework that makes it easy to do the right thing.

You Need a Dedicated AI Lead#

The single most impactful thing an organization can do for agent governance is to create a dedicated role — someone who owns agent governance end to end. And this person needs to be a bridge between IT and business.

Not a pure IT role. Not a pure business role. Someone who understands the technical possibilities of agent platforms, but also deeply understands the business processes and use cases. Someone who can translate between the security team saying “we need to control data access” and the business team saying “we need agents that actually do useful work.”

Where this person sits in the org chart matters less than the mandate they have. They need the authority to define policies, the technical depth to evaluate agent implementations, and the business acumen to prioritize the right use cases. It’s a rare combination, but it’s the role that makes everything else possible.

Microsoft Is Building the Control Plane#

To be fair, Microsoft isn’t ignoring this. With Agents 365, they’re building a control plane for agents where governance topics are increasingly being addressed. Centralized management, visibility into what agents exist and what they do, policy enforcement — these capabilities are coming.

But here’s what I keep saying: governance is primarily an organizational challenge, not a technology challenge. The best admin center in the world doesn’t help if nobody has defined the policies it should enforce. Microsoft can build the tools, but organizations need to do the thinking.

The platforms will keep getting better. Agents 365 will mature. Copilot Studio will add more governance features. But the organizational work — defining roles, establishing processes, building the knowledge in your IT team — that’s on you. And the sooner you start, the less painful it will be.

The Bottom Line#

Agent governance is going to be the defining factor that separates organizations that successfully adopt agents from those that don’t. Not because governance is exciting — it’s not. But because without it, you either get paralysis (IT blocks everything) or chaos (shadow agents everywhere). Neither gets you to the agentic organization.

The good news: you don’t need to have everything figured out on day one. Start with the basics — a role model, an approval process, an agent inventory. Then iterate. But start now, because every week without governance is a week where the gap between what’s being built and what’s being managed grows wider.

Does your organization have a dedicated person or team responsible for agent governance — or is it still everyone’s and nobody’s job?

Testing AI Agents Is a Problem Nobody Wants to Talk About#

Everyone is building agents. Almost nobody is testing them properly.

Here’s something that’s been bugging me for a while: in classical software development, testing is non-negotiable. Nobody would ship a production application without at least some level of automated testing, code reviews, and quality gates. It’s fundamental. And yet, when it comes to AI agents, testing is often completely neglected. It’s like we collectively decided that the rules don’t apply anymore.

I think it’s time we talk about this.

Why Agent Testing Falls Through the Cracks#

The main reason is actually straightforward: the people building agents today aren’t necessarily developers. Microsoft has done an incredible job democratizing agent development — from Agent Builder to Copilot Studio, anyone can build an agent without writing a single line of code. And that’s genuinely great for innovation.

But here’s the flip side: many of these builders have never been exposed to the discipline of software testing. They don’t know what a test plan looks like. They’ve never written a test case. Not because they’re not smart — they absolutely are — but because testing was never part of their world. When a business analyst builds an agent in Copilot Studio, their definition of “done” is usually “it works when I try it.” And that’s not the same as “it’s been properly tested.”

Deterministic Testing Doesn’t Work Here#

Even if you do come from a development background, you’ll quickly realize that classical testing approaches don’t translate well to AI agents. In traditional software, you test deterministically: given input X, you expect output Y. If the output matches, the test passes. Simple.

With AI agents, that model breaks down completely. Ask the same agent the same question twice, and you might get two different answers — both of which could be perfectly correct. The underlying language model is non-deterministic by nature. So if you try to apply unit test thinking to agent testing, you’ll either go crazy or give up. Neither is helpful.

What we need is a fundamentally new testing mindset.

New Categories for a New Paradigm#

Instead of testing for exact outputs, I think we need to focus on qualitative evaluation categories that actually matter for agents:

These categories shift the focus from “is the output identical?” to “is the output good?” — and that’s exactly the shift we need.

What State-of-the-Art Looks Like Today#

The good news is that tooling is catching up. Here’s what I see as the current state-of-the-art for agent testing:

Evaluation frameworks like Azure AI Evaluation SDK or DeepEval can automatically score agent responses on metrics like groundedness, relevance, and coherence. Essentially, you use one LLM to evaluate the output of another. It’s not perfect, but it scales.

Golden datasets — curated sets of question-answer pairs that serve as benchmarks. The key difference to classical test data: you don’t check for exact matches but for semantic similarity. The agent doesn’t need to produce the same words, just the same meaning.

Tool call assertions — verifying that the agent invokes the correct tools for a given input, regardless of the textual response. If someone asks “What’s my leave balance?”, the agent should call the HR API, not the finance API. This is actually quite testable.

Red teaming — deliberately trying to break the agent. Can you make it hallucinate? Can you trick it into revealing information it shouldn’t? Can you push it off-topic? This adversarial approach catches issues that happy-path testing never will.

Human-in-the-loop evaluation — running example conversations and having humans manually assess the quality. This is labor-intensive but catches nuances that automated metrics miss.

The Platform Gap#

Here’s something worth noting: not all Microsoft platforms are equal when it comes to testing support. Microsoft Foundry already offers a solid evaluation toolkit — you can run evaluations against datasets, measure quality metrics, and integrate this into your development workflow.

Copilot Studio and Agent Builder? Not so much. If you’re building agents in these platforms, you’re largely on your own when it comes to structured testing. I hope this gap closes soon, because these are exactly the platforms where citizen developers build agents — the same people who need testing guidance the most.

Make Testing Non-Optional#

If there’s one practical takeaway from this post, it’s this: don’t make agent testing a recommendation — make it a requirement.

Organizations need to establish an ALM (Application Lifecycle Management) process for agents that explicitly includes testing as a mandatory step. Not a “nice to have.” Not a “we’ll add testing later.” A hard gate that every agent must pass before it reaches production.

This means:

• Define minimum testing criteria for every agent before it gets deployed
• Provide testing templates — example conversations, evaluation rubrics, tool call checklists — so that citizen developers have a starting point
• Build testing into the approval workflow — no test results, no deployment

Yes, this adds friction. But it’s the same kind of friction that prevents broken software from reaching production in every other part of your technology stack.

The Bottom Line#

Agent testing is where software testing was 20 years ago — everyone knows they should do it, but many organizations are still figuring out how. The difference is that we’re building agents at a pace that’s far faster than we ever built traditional applications, which means the gap between what’s being shipped and what’s been properly tested is growing quickly.

I believe agent testing will eventually become as natural as unit testing is today. The tools will improve, the platforms will integrate better evaluation capabilities, and organizations will develop testing muscle through experience. But we can’t just wait for that to happen. We need to start now — with the tools we have, with the frameworks that exist, and with the mindset that agents deserve the same quality standards as any other piece of software we put in front of our users.

How does your organization handle agent testing today — and do you have a process in place, or is it still the wild west?

The Agentic Organization — When Agents Become Part of the Team#

We’ve been talking about agents. It’s time to talk about what happens when they join the org chart.

The word “agentic” is everywhere right now. Every platform, every keynote, every product update — everything is suddenly “agentic.” But here’s what I’ve noticed: everyone uses the term, and everyone means something slightly different by it. So before we talk about the agentic organization, I think we need to take a step back and create some clarity.

Where We Are Today#

Right now, most interactions with AI agents follow a simple pattern: one person, one agent, one task. You ask your Copilot agent a question, it gives you an answer. You trigger a workflow, the agent executes it. It’s a 1:1 relationship — useful, productive, but fundamentally still a tool interaction.

And that’s fine. That’s the current state for most organizations, and there’s a lot of value in getting this right. But I don’t think this is the end state. I think the next logical step on our agentic AI journey is something bigger: organizations where people and agents work together in teams. Not as tool and user, but as teammates with different roles and responsibilities.

That’s what I mean when I talk about the agentic organization.

The Agentic Maturity Model#

To make this more tangible, here’s how I see the journey from “we just got Copilot” to a fully agentic organization. Most companies will recognize themselves somewhere on this scale:

Most organizations I talk to are somewhere between Stage 1 and Stage 2. A few ambitious ones are approaching Stage 3. And that’s perfectly fine — but it helps to know where you’re heading.

What Stage 5 Actually Looks Like#

Let me make this concrete, because “people and agents working together” can sound abstract.

Finance & Controlling. Imagine agents handling the data analysis — pulling numbers, identifying anomalies, running comparisons across periods. The humans on the team don’t spend their time building spreadsheets anymore. Instead, they review the agent’s findings, add context that only they have (“this spike is because we acquired a company last quarter”), and make the decisions. The agent does the heavy lifting. The human does the thinking.

Marketing. Agents manage the channel execution — scheduling posts, adapting content for different platforms, monitoring engagement metrics. They report back to the team with performance data and recommendations. The humans focus on strategy, creative direction, and the decisions that require judgment and brand understanding.

Value-creating processes in general. The pattern is the same across domains: agents execute, humans supervise and decide. It’s a fundamental shift from “the human does the work and the agent helps” to “the agent does the work and the human steers.”

That’s the real transformation. Not just using agents as better tools, but integrating them as team members with defined responsibilities.

The Trust Question#

I know what some of you are thinking: “Can we really trust agents to do the work while we just supervise?” And yes, there are enough skeptics out there — and healthy skepticism isn’t a bad thing.

But I think we should approach this positively rather than letting fear block progress. The key is finding the right balance. You don’t hand over your entire financial reporting to an agent on day one. You start small, build trust through experience, and gradually expand the agent’s responsibilities as you learn what works and what doesn’t.

This is no different from onboarding a new team member, honestly. You wouldn’t give a new hire full autonomy on their first day either. You’d start with defined tasks, review their output, and expand their scope over time. The same principle applies to agents.

Start Now — Even on Stage 1#

Here’s the thing: you don’t need to be on Stage 4 to start thinking about Stage 5. In fact, the organizations that will get to the agentic organization fastest are the ones that start building the foundation now.

What does that mean practically?

Foster curiosity. Give your people the space and permission to experiment with agents today. Not in a formal “innovation lab” that nobody takes seriously, but in their actual daily work. Let them try things, let them fail, let them learn. That’s how organizational capability is built.

Think about your processes. Look at your workflows and ask: which of these could be restructured so that agents handle the execution while humans handle the decisions? You don’t need to implement this tomorrow, but starting to think this way changes how you approach every process improvement from now on.

Don’t wait for perfection. The tools will keep evolving. The governance frameworks will mature. But the organizational learning — understanding how your teams can work with agents, what works in your specific context, what doesn’t — that only comes from doing.

The Bottom Line#

The agentic organization isn’t science fiction. It’s the logical next step in a journey that many organizations are already on. We went from “AI as a feature” to “Copilot as an assistant” to “agents as tools.” The next step is “agents as teammates.”

I believe this will affect every organization to some degree. The question isn’t whether the agentic organization is coming — it’s whether your organization will be ready when it arrives.

Where is your organization on the agentic maturity scale today, and what’s your next step to move forward?

The Real ROI of Microsoft 365 Copilot Extensibility#

When does extending Microsoft 365 Copilot actually pay off? Here are my thoughts.

I’ve been consuming a lot of content around Microsoft 365 Copilot extensibility lately. And while the community is doing a great job producing tutorials, samples, and getting-started guides, I noticed something: there’s a ton of Hello World-style content out there, but very little about the actual return on investment. So I wanted to share my personal take on when extensibility is worth it — and what the real value looks like.

Are You Even Ready?#

Here’s the thing: many organizations I talk to are still in the middle of rolling out Microsoft 365 Copilot to their users. They’re figuring out adoption, licensing, governance — the basics. And that’s totally fine. But for these organizations, extensibility shouldn’t be the priority yet (even though the conference demos make it look like everyone should be building agents right now).

To me, the “extensibility moment” comes when you’ve reached a certain maturity. You’ve got a Copilot rollout going. Your users are actively working with it. You’ve identified use cases that work out of the box. And then — this is key — you start noticing the gaps. The moments where users need data or processes from third-party systems, LOB apps, or your ERP that Microsoft 365 Copilot simply can’t reach by default.

That’s when extensibility becomes relevant. Not because a demo looked cool, but because your users actually need it.

It’s About Personalization, Not Just Time Savings#

When people talk about ROI for extensibility, the conversation usually goes straight to time savings. “The agent saves 15 minutes per day.” And sure, that’s measurable. But to me, that misses the bigger picture.

The real value of Microsoft 365 Copilot extensibility is personalization. Out of the box, Microsoft 365 Copilot is a powerful but generic tool. It works the same for every organization. But it doesn’t know your ERP system. It doesn’t understand your specific business processes. It can’t interact with the industry-specific applications your people use every day.

Extensibility changes that. It transforms Microsoft 365 Copilot from a general-purpose assistant into something that understands and operates within your specific context. And that’s where the real productivity and efficiency boost comes from.

From Information to Delegation#

Let me make this concrete (because I think this example explains it best):

Without extensibility, a user asks Microsoft 365 Copilot: “How do I submit a purchase order in our ERP system?” — and Copilot tells them which screens to navigate and which fields to fill in. Useful? Yes. Better than a manual? Definitely.

With extensibility, the same user asks: “Submit a purchase order for 500 units of component X from supplier Y.” — and an agent connected to the ERP actually does it. Validates the request, triggers the process, confirms completion. The user didn’t get information about how to do their job. The agent did the job on their behalf.

That shift — from information to action, from assistance to delegation — is where the ROI becomes obvious. Not in minutes saved, but in entire process steps eliminated.

Start Small, Please#

One thing I’ve seen way too often: organizations approaching extensibility with too much ambition too early. They want an agent covering 20 processes across five systems on day one. And these projects tend to stall.

What works better (and I can’t stress this enough): start with an MVP. Pick one process. One integration. One use case where the current workflow is painful. Build something simple. Ship it. Learn. Iterate. Then expand.

Measuring What Actually Matters#

If you’re going to invest in extensibility, you should know whether it’s working. And “users like it” is not a metric. Here’s what I think you should be looking at:

Especially that last one is often overlooked. When a new hire needs to learn complex ERP processes, an agent that can guide or even execute these processes dramatically shortens the learning curve. That’s a powerful ROI argument.

So, What’s Your Extensibility Moment?#

I’m not saying every organization needs Microsoft 365 Copilot extensibility right now. Many don’t — yet. But I do think everyone should be actively thinking about it.

Look at your users’ daily workflows. Where do they leave Microsoft 365 to get things done? Where are processes slow or error-prone because the tools aren’t connected? Those are your extensibility opportunities.

Which processes in your organization do you think could get a real boost from Microsoft 365 Copilot extensibility?

The Citizen Developer Promise for Copilot Agents is an Illusion#

Low-code doesn’t mean low-complexity. Here’s where the line really is.

Microsoft has been telling a beautiful story: business users can describe what they want in natural language, and Agent Builder in Microsoft 365 Copilot will create an agent for them. When they outgrow the basics, they can seamlessly move to Copilot Studio with one click. No code required. Anyone can build an agent.

I’ve been watching this narrative evolve for over a year now, and I think it’s time for a reality check. The citizen developer promise for Copilot agents, as it’s currently marketed, is an illusion. Not a lie — an illusion. There’s an important difference.

The Happy Path Works Beautifully#

Let me be fair first. If you want to build a declarative agent that answers questions based on a curated set of SharePoint documents, Agent Builder does a genuinely impressive job. You describe the agent’s purpose, point it at your knowledge sources, maybe adjust the instructions, and you have something functional in minutes. For this specific use case — essentially a scoped Q&A bot over your own content — the citizen developer story absolutely holds up.

The problem starts the moment you need anything beyond that happy path.

Where Things Fall Apart#

The moment you need real integrations. Your HR manager wants an agent that doesn’t just answer questions about company policies but actually checks leave balances in Workday and submits time-off requests. That requires MCP server connections, authentication configuration, understanding OAuth flows, and dealing with connector infrastructure. I’ve watched technically savvy business analysts — people who are genuinely good with Power Automate and Power Apps — hit a wall when they try to configure MCP authentication with dynamic client registration. These aren’t concepts that a weekend workshop prepares you for.

The moment you need nuanced instructions. Agent instructions look simple — you’re just writing natural language, right? But crafting instructions that reliably produce the right behavior across edge cases is essentially prompt engineering. It requires understanding how the underlying model interprets ambiguity, how grounding works, what happens when the agent can’t find an answer, and how to handle multi-step reasoning. This is a skill that takes practice to develop, and most business users don’t have the feedback loops to develop it.

The moment you need to debug. Something isn’t working. The agent is returning wrong information, or it’s not calling the right MCP tool, or the authentication keeps failing. Where do you even start? Copilot Studio’s tracing and analytics have improved significantly, but interpreting activity maps, understanding tool invocation patterns, and diagnosing orchestration failures requires a developer mindset. There’s no low-code way to debug a complex agent.

The moment you need governance. Your citizen-developed agent works great in testing. Now it needs to go through the approval workflow in the admin center. IT needs to review the data sources, security needs to assess the permissions model, and compliance needs to verify the agent doesn’t expose sensitive data. The citizen developer built the agent — but they can’t shepherd it through enterprise governance alone.

The “Copy to Copilot Studio” Gap#

Microsoft’s answer to the complexity cliff is the “Copy to Copilot Studio” feature. Start simple in Agent Builder, then graduate to the full platform when you need more power. It sounds seamless, but it creates a handoff problem that nobody talks about.

The business user who built the prototype in Agent Builder understands the business logic. The developer who takes over in Copilot Studio understands the technology. Neither fully understands the other’s domain. The result is usually one of two things: the developer rebuilds from scratch (wasting the prototype work), or the developer tries to extend the existing agent without fully understanding the business intent (leading to subtle bugs that only surface in production).

This isn’t a new problem — it’s the same gap that has plagued every low-code-to-pro-code transition since the concept was invented. But it’s being presented as solved, and it isn’t.

What Would Actually Work#

I’m not arguing against democratizing agent development. I think it’s the right direction. But I think we need a more honest model of what citizen development looks like for agents:

Tier 1: Genuine citizen development. Q&A agents over curated content. Simple declarative agents with file-based knowledge. This is where business users can truly self-serve, and we should encourage it. But let’s be clear that this is the scope.

Tier 2: Guided development. Agents that need integrations, complex logic, or multi-step workflows. This requires a “buddy system” — a business user who understands the process working alongside a developer or a power user who understands the platform. Neither can do it alone effectively.

Tier 3: Professional development. Agents with custom MCP servers, complex authentication, multi-agent orchestration, or enterprise-scale governance requirements. This is developer territory, full stop. Pretending otherwise sets everyone up for frustration.

Invest in the middle tier. Most organizations focus on either the self-service story (Tier 1) or the pro-dev story (Tier 3) and completely ignore Tier 2. But Tier 2 is where the most valuable agents live — the ones that are specific enough to a business process to be truly useful, but complex enough to need some technical guidance.

Create feedback loops. The biggest gap in the citizen developer experience isn’t tooling — it’s learning. When a business user builds an agent that doesn’t work well, they rarely know why it doesn’t work well. Build internal communities of practice where people share what worked, what didn’t, and why. This accelerates learning far more than any tutorial.

Redefine success. If your measure of citizen developer success is “business users building production agents independently,” you’ll be disappointed. If your measure is “business users prototyping agent ideas that can be quickly validated and refined with technical support,” you’ll be much happier — and you’ll ship more useful agents.

The Bottom Line#

The tools Microsoft is building are genuinely impressive. Agent Builder, Copilot Studio, the MCP ecosystem — these are powerful platforms that lower the barrier to agent development significantly. But “lower the barrier” is not the same as “eliminate the barrier,” and the marketing often conflates the two.

The organizations that get the most value from Copilot agents won’t be the ones where everyone builds their own agents. They’ll be the ones that create the right collaboration model between business expertise and technical capability, with clear expectations about what each tier of development can realistically deliver.

Let’s stop selling the illusion and start building the support structures that make citizen-involved agent development actually work.

Have you tried building Copilot agents as a non-developer? Or are you a developer supporting citizen developers? I’d love to hear about your experience.

Microsoft 365 Copilot Extensibility: Navigating the Possibilities and Pitfalls#

As organizations rush to adopt Microsoft 365 Copilot, a critical question emerges: How do we extend Copilot to work with our unique business data and processes? The answer lies in understanding the three extensibility pillars—Connectors, Agents, and APIs—and knowing when (and when not) to use each. And that’s why I created an infographic for that:

Understanding the Anatomy of Microsoft 365 Copilot#

Before diving into extensibility, let’s understand what we’re extending. At its core, Microsoft 365 Copilot consists of:

The Core Engine#

• Orchestrator: The traffic controller that manages data governance, safety, and responsible AI (RAI) policies
• Foundation Models: The AI backbone powered by GPT-4o, GPT-4.1, and newer models like o1 and o3-mini

Where Extensibility Plugs In#

Copilot’s architecture exposes three key areas for extension:

The Three Extensibility Pillars#

1. Connectors: Bringing External Data to Copilot#

Direction: External Data → Copilot

Graph Connectors allow you to ingest and index external data into Microsoft Graph, making it available for Copilot to reason over.

What you get:

• 100+ prebuilt connectors for popular systems
• Custom connector development via Graph API
• Support for CRM, ERP, databases, and file systems

Best for:

• Making enterprise data searchable and available to Copilot
• Connecting line-of-business applications
• Enabling Copilot to answer questions about your proprietary data

⚠️ Pitfall: Connectors only provide read access. If you need Copilot to take actions in external systems, you’ll need Agents.

2. Agents: AI Assistants That Do Work#

Direction: AI Assistants ↔ M365 (Bidirectional)

Agents are specialized AI assistants that can automate workflows and perform tasks. They’re the most powerful—and most complex—extensibility option.

Inside Agents: Core Components#

Every agent consists of three parts:

1. Knowledge: Data sources like SharePoint, OneDrive, Graph Connectors, and web content
2. Instructions: Custom persona, tone, scope limits, and behavioral guardrails
3. Actions: Real-time API calls that let the agent do things

⚠️ Critical Insight: Actions ONLY work inside Agents! You cannot add actions to base Copilot—they must be wrapped in an agent.

Two Types of Agents#

Three Ways to Build Actions#

3. Copilot APIs: Embedding Copilot in Your Apps#

Direction: Your Apps → Copilot

Copilot APIs let you programmatically access Copilot’s capabilities from your own applications.

Available APIs:

Best for:

• Building custom applications that leverage Copilot
• Integrating AI capabilities into existing line-of-business apps
• Creating specialized user experiences

Common Pitfalls and How to Avoid Them#

Pitfall #1: Using Connectors When You Need Actions#

Symptom: “I connected my CRM data, but Copilot can’t create new records.”

Solution: Connectors are read-only. To write data back, create an Agent with Actions that call your CRM’s API.

Pitfall #2: Building Custom Engines When Declarative Would Suffice#

Symptom: Spending months building a custom AI engine for a simple Q&A bot.

Solution: Start with Declarative Agents. They deploy faster and Microsoft handles the AI infrastructure. Only go custom when you need specific models or complex orchestration.

Pitfall #3: Ignoring Data Governance#

Symptom: Copilot surfaces sensitive data to unauthorized users.

Solution: Connectors and Agents respect Microsoft 365 permissions. Ensure your data sources have proper access controls before connecting them.

Pitfall #4: Overlooking the Actions-in-Agents Requirement#

Symptom: “I built an OpenAPI action but can’t find it in Copilot.”

Solution: Actions must be deployed within an Agent. Create a Declarative Agent, add your action, and deploy the agent to Teams or M365.

Decision Framework: Choosing the Right Approach#

Do you need Copilot to access external data?
├── Yes → Use Graph Connectors
│   └── Do you also need to write back?
│       └── Yes → Add an Agent with Actions
└── No
    ↓
Do you need Copilot to perform tasks?
├── Yes → Build an Agent
│   ├── Simple tasks, quick deployment → Declarative Agent
│   └── Complex logic, custom AI → Custom Engine Agent
└── No
    ↓
Do you need AI in your own app?
├── Yes → Use Copilot APIs
└── No → You might not need extensibility!

Getting Started#

Tools You’ll Need#

Recommended Learning Path#

1. Start with Copilot Studio to understand agent concepts visually
2. Build a Declarative Agent with knowledge sources
3. Add an OpenAPI Action to perform a simple task
4. Explore MCP for more dynamic scenarios
5. Graduate to Custom Engine Agents when you hit limitations

Conclusion#

Microsoft 365 Copilot extensibility is powerful but requires understanding the architecture. Remember:

• Connectors bring data IN (read-only)
• Agents enable bidirectional interaction with Actions
• APIs let you bring Copilot OUT to your apps
• Actions only work inside Agents—this is the #1 gotcha

Start simple, validate your approach, and scale from there. The extensibility landscape is evolving rapidly, with MCP and new APIs in preview that will expand what’s possible.

Have questions about Copilot extensibility? The patterns and pitfalls shared here come from real-world implementation experience. Your mileage may vary, but understanding these fundamentals will set you on the right path.

Introduction#

Today we live in an era of constant change. Technology changes, mindset changes and vision changes. It started out with a bunch of Generative AI tools fueled by LLMs. These AI Tools now do not only offer the access to LLMs itself, but also give you the chance of creating and using agents. These agents give you two extra-assets:

• Consistency
• Scope

My friend Thomy wrote about the topic of AI Agents at Process Handovers: Where Consistency Matters More Than Intelligence , so if you want to know about why consistency matters, please read that first.

But with the introduction of agents, we also started shifting into an “Agent-Centric Workplace”. And I started to feel this myself rather quick: For every platform, for every service and for every use case, an agent could be built to assist me throughout my workday. To me, using agents goes beyond using Copilot. It’s more a concept of delegating work to my digital teammates = agents. And with all the recent announcements and udpates published by Microsoft around topics like autonomous agents, I do not think that this concept is going to vanish in the future. More likely, we will see the transition going from prompt-based assistants to goal/task-oriented, multi-step reasoning systems more and more over the course of the next weeks, months and years.

Ecosystem#

The Microsoft platforms offers a sophisticated ecosystem when it comes to building (and yes you may think why is he not writing “developing” instead of building, but we’ll come to that in a second) agents of many kinds. You can build agents in a variety of places with a variety of tools like:

• SharePoint
• Copilot Studio lite
• Copilot Studio full
• Microsoft Fabric
• M365 Agents Toolkit & SDK
• Azure AI Foundry
• Agent Framework
• …

And all of these platforms and frameworks target a specific agent builder audience, from low-code to pro-code. Eventually I will write another blog post, or even a series, about which platforms should be leveraged by which audience. But the good news here is, that there is at least one tool or platform for everyone, no matter which skills you have when it comes to building or developing an agent. And many of the agents built with these platforms can then be again consumed from one central place: Microsoft 365 Copilot. Therefore, the platform will likely evolve and governance aspects will also be covered more and more as more and more people will not only be using agents, but will also be building agents, either for their personal use, for their team or for the whole organization.

Multi-Agent Collaboration#

With the variety of tools and frameworks, the necessacity of introducing a concept called “Multi-Agent Collaboration” grew. Satya Nadella once said in a keynote of a big conference that “Copilot is the UI for AI”. Thinking about this message, I thought that this is the beginning of the Multi-Agent Collaboration era, where Microsoft 365 Copilot itself is also an agent, having the skills of orchestrating and collaborating with other agents.

But for me personally, hearing this message was not the first time for me personally to think of multi-agent scenarios. Looking back at my blog post on Microsoft Build 2019 updates on Conversational AI , the concept of Skills was introduced. And this to me was the first step towards a multi-agent collaboration era, because skills in the realm of the Microsoft Bot Framework where chatbots itself, which other chatbots would call to solve specific tasks.

Human-Agent Collaboration Patterns#

In the future, we might see a shift from “Copilot in apps” to “Copilot across work” as this may be something that people need more urgent. In my idea, I think an agent like a “Project Planning Agent” might be more helpful when integrated in all of my work apps, than an agent like the Copilot in Word. Because I want to perfectly do my project planning, which involves multiple platforms and services, so this agent should be accessible and integrated in all of the places where I do my work and is still specifically tailored to one specific goal (here we are again at consistency and scope).

This shit may also require us to rethink productivity rituals, like how do we manage meetings or how do we do reporting or how do we share knowledge when agents are our digital teammates, as they also need to be integrated into these rituals.

Future look#

With things like MCP, multimodal models and agents and the convergence of local and cloud intelligence, I do think that agents will play an important role in our future workplace. In the future we might not be talking “Copilot Adoption” but “Agent lifecycle management”, as I strongly believe that the introduction of “goal-oriented agents” will be a huge boost in the enterprise, to increas both our productivity as well as the quality we deliver our work with. Therefore I encourage everyone reading this, to experiment with agents and especially with multi-agent scenarios as this will likely hit us sooner or later and furthermore, think about this: “What’s your vision for the agentic workplace?” and let me know what’s your opinion!

Introduction#

Microsoft is pushing the boundaries of how business processes can be automated with its Copilot Studio—a cloud-based, low-code platform that empowers organizations to build AI agents. In its latest release, Microsoft has introduced autonomous agent capabilities aimed at enabling agents to proactively respond to events, orchestrate tasks, and integrate seamlessly with enterprise data sources. However, while these functionalities open exciting prospects, in my opinion, they currently feel quite basic—likely reflecting their preview status.

Autonomous Agent Capabilities at a Glance#

With Copilot Studio, Microsoft now provides tools to build autonomous agents that can:

• Monitor & React: Automatically respond to business signals or triggers to initiate tasks.
• Execute Business Processes: Leverage AI orchestration to run rule-based workflows and automate repetitive tasks.
• Integrate with Data Sources: Connect to Microsoft Graph, Dataverse, and other connectors to pull in context.
• Enhance Productivity: Offer a low-code way for teams to extend Microsoft 365 Copilot with personalized AI agents.

Fundamental Architecture Diagram#

A core element of understanding autonomous agents in Copilot Studio is their underlying architecture. Below is a diagram which displays a visual representation of the system:

Figure 1: Fundamental Architecture for Autonomous Agents in Microsoft Copilot Studio

This diagram illustrates how user interactions are processed through Copilot Studio, which utilizes an orchestration engine to understand the trigger and inputs along with building and executing a plan. The agents then access context-rich data from secure sources to generate responses.

The Preview Nature: Opportunities and Limitations#

While the preview release is promising, the current autonomous agent capabilities appear somewhat basic:

• Limited Customization: The workflow options and decision-making granularity are still evolving.
• Early-Stage Integrations: Integrations with external systems work at a basic level—expect enhancements with additional connectors and refinements.
• Dependence on User Feedback: Early adopters find that while the automation framework offers efficiencies, further adjustments and human oversight are needed to handle complex real-world scenarios.

These observations suggest that the preview is an important first step, setting the stage for further refinements as Microsoft iterates based on customer feedback.

Looking Ahead#

Microsoft’s vision for transforming business processes with AI is clear. As additional features and deeper integrations are developed, we can expect:

• More advanced decision-making capabilities.
• Enhanced automation for complex workflows.
• Greater interoperability across the Microsoft ecosystem.

Even though the functionality now might seem basic, it represents a foundational step towards a future where AI agents can autonomously handle a wide array of business tasks with minimal human intervention.

What do you think about the current state of autonomous agent capabilities in Copilot Studio? Do you see this basic functionality as laying the groundwork for a more advanced, fully autonomous future?

Setup#

You obviously need to create or already have an agent in Microsoft Copilot Studio. If you don’t have an agent already follow this tutorial to create a new custom engine agent in Copilot Studio.

After you have created an agent go to your settings page of the agent and then under “Generative AI” you can enable the checkmark on “Use deep reasoning models”:

When you now send a prompt to your agent you should see that the agent is using deep reasoning to generate the answer:

What’s interesting is that you can also see what the agent does take into account when doing the reasoning:

As you can now also add your custom engine agents built with Copilot Studio to your Microsoft 365 Copilot you can use this method to add deep reasoning to Microsoft 365 Copilot:

Considerations#

This feature is currently in preview so be careful when to enable this (maybe not the best idea to use this for all production agents already). Another requirement is that your agent needs to be created in a US-based Power Platform environment and the agent’s language should be English, otherwise you’ll see the setting, but the agent will not use deep reasoning unfortunately.