Building Declarative Agents for Microsoft 365 Copilot - A Practical Guide
If you've been using Microsoft 365 Copilot for a few months, you've probably hit the same wall most of our clients hit. It's great at summarising meetings. It can draft a passable email. But ask it something specific to your business - "What's the warranty status on order #4521?" or "What's our standard onboarding process for contractors in Queensland?" - and you get a polite but useless response.
That's where declarative agents come in. And having built quite a few of these across different Australian organisations over the past year, I think they're the most practical extension point Microsoft has offered for Copilot to date.
What Are Declarative Agents, Really?
Strip away the marketing language and a declarative agent is a scoped version of Copilot that you configure for a specific job. You tell it what it should know about, what it can do, and how it should behave. It then runs on the same infrastructure as regular Copilot - same AI models, same security layer, same orchestrator - but it stays in its lane.
The "declarative" part matters. You're not writing code that handles every interaction. You're declaring the agent's purpose, its knowledge sources, and its available actions. Microsoft's platform handles the actual reasoning and response generation. Think of it like configuring a specialist rather than building one from scratch.
Microsoft's official documentation on declarative agents covers the technical specifications, but let me share what actually matters when you're planning a deployment.
Why They Work Better Than Generic Copilot
The biggest win is scope. Generic Copilot tries to be everything to everyone, which means it's middling at most things. A declarative agent knows its boundaries. We built one for a mid-size logistics company that only handled freight rate queries. It pulled from their rate cards in SharePoint and connected to their TMS through an API plugin. Staff who previously spent 20 minutes looking up rates and doing manual calculations could get answers in seconds.
The key difference from just "asking Copilot a question" is that the agent has context by default. You don't need to explain what system you're talking about or which SharePoint site has the information. The agent already knows. It's the difference between calling a general helpline and calling someone who already has your file open.
Users interact with declarative agents right inside the Copilot interface - in Teams, Word, PowerPoint, or the Copilot chat. They pick the agent from a side panel, see conversation starters that the agent offers, and start asking questions. No new app to install. No new interface to learn. That adoption piece is underrated. I've watched beautifully built custom apps collect dust because nobody wanted to switch to yet another tool.
The Building Blocks
A declarative agent package has four parts:
The app manifest defines your app's metadata - name, description, icons, required permissions. If you've built any Teams app before, this is familiar territory.
The declarative agent manifest is where the real work happens. This is where you write the agent's instructions, define its conversation starters, and configure what knowledge sources and actions it can access. Version 1.5 of this manifest is the current standard and it's well-structured.
App icons - you need a colour icon and an outline icon. Seems minor but do not skip this. Agents without proper icons look unfinished and users don't trust them as much. I've seen adoption rates differ noticeably between polished and rough-looking agents.
Plugin manifests (optional) connect your agent to external systems. If your agent needs to pull data from an API or trigger actions in another system, plugins are how you wire that up.
Writing Good Instructions
This is where most teams get it wrong on the first attempt. The instructions you write for your declarative agent are not a system prompt in the ChatGPT sense. They need to be specific about what the agent does, what it doesn't do, and how it should handle edge cases.
Here's what I've learned works:
Be explicit about scope. "You are an IT support agent for [Company]. You help employees resolve common technical issues. You do not handle HR questions, payroll queries, or anything outside IT support. If asked about those topics, direct the user to the HR portal."
Give it real examples of queries it should handle. "When an employee asks about VPN setup, check the VPN guide in the IT Knowledge Base SharePoint site first."
Tell it what tone to use. "Respond in plain English. Avoid jargon. If a solution requires technical steps, list them as numbered instructions."
Don't over-engineer the instructions on your first version. Start with something clear and reasonable, deploy it to a small group, and iterate based on real usage patterns. The agents that work best are the ones refined through actual feedback, not the ones designed in a vacuum.
Tools for Building
Microsoft offers four paths to create declarative agents:
Microsoft 365 Agents Toolkit (formerly Teams Toolkit) is what I'd recommend for most development teams. It gives you proper source control, local debugging, and deployment automation. If your team is already comfortable with VS Code and Node.js or .NET, this is the natural choice.
Copilot Studio works well for citizen developers and business analysts who want to build agents without writing code. The drag-and-drop interface covers most common scenarios. I've seen business operations managers build useful agents in Copilot Studio within a day. The limitation is that complex scenarios with custom API integrations can feel clunky compared to the code-first approach.
SharePoint agents are the quickest path if your agent just needs to answer questions from SharePoint content. You can create one directly from a SharePoint site without any separate development environment. Good for knowledge-base style agents.
Building directly in Copilot is available but limited. Fine for personal agents, not what you'd use for organisation-wide deployment.
For most of our clients, we start with Copilot Studio for prototyping and validation, then move to the Agents Toolkit for production deployments where we need proper CI/CD and testing. That workflow lets the business validate the concept quickly before engineering gets involved in the production build.
Real Use Cases We've Seen Work
IT self-service agents are the easiest win. Every organisation has the same problem: employees submitting tickets for things that have documented solutions. A declarative agent that draws from your IT knowledge base in SharePoint can deflect a meaningful percentage of L1 support tickets. One client saw a 35% reduction in simple password reset and VPN tickets within the first month.
Customer support with live data is more complex but higher value. We built an agent for a professional services firm that could pull real-time project status from their project management system through an API plugin. Their account managers stopped chasing PMs for status updates because they could just ask the agent. The plugin integration took the most development effort, but the time savings were significant.
Employee onboarding is another strong fit. New starters have endless questions about systems, policies, and processes. An onboarding agent scoped to HR policies and IT setup guides handles the repetitive questions that managers answer dozens of times per year.
Procurement support - agents that know your vendor catalogue, pricing agreements, and approval workflows. Staff can check whether a vendor is approved or what the current pricing is without digging through SharePoint folders.
What to Watch Out For
Data quality is still the bottleneck. If your SharePoint knowledge base is full of outdated documents from 2019, your agent will confidently serve up wrong answers. Clean your sources before connecting them. This is not optional.
Responsible AI validation is real. Microsoft runs your agent through RAI checks before it can be published. They're checking for potential harmful outputs, data leakage risks, and compliance with Microsoft's AI principles. Most well-designed agents pass without issues, but if your instructions are too loose or your knowledge sources contain sensitive data without proper access controls, you'll get flagged.
Admin control matters. IT admins manage distribution of declarative agents through the Microsoft 365 admin centre. Think about your rollout strategy early. Which groups get which agents? Who can modify them? How do you handle versioning when you update instructions or add new plugins?
Performance with plugins can vary. API plugins that call external systems introduce latency. If your backend API takes three seconds to respond, the agent will feel slow. Optimise your APIs before blaming the agent framework.
Getting Started
If you haven't built a declarative agent yet, here's the path I'd recommend:
- Pick one well-defined use case. Not your most ambitious idea - your simplest one that would still save meaningful time.
- Make sure the knowledge sources are clean and accessible in SharePoint or through connectors.
- Start with Copilot Studio to build a prototype. Test it with five real users.
- Gather feedback and refine the instructions.
- If the concept proves out, move to the Agents Toolkit for a production deployment.
At Team 400, we've been helping Australian organisations build and deploy these agents as part of their broader Microsoft 365 strategy. The technology is mature enough now that the limiting factor isn't the platform - it's having clear thinking about what problems to solve first.
If your organisation is already paying for Copilot licences and you're not building declarative agents, you're leaving value on the table. The agents that work best aren't the flashiest ones - they're the ones that answer a specific question that people ask fifty times a week. Start there.
For organisations looking at broader AI strategy or needing help with Microsoft AI consulting, we're always happy to have a conversation about where agents fit into your roadmap.