Key takeaways
- There are two main ways to build a Copilot agent: declarative agents (low-code, on Microsoft’s hosted AI) and custom engine agents (pro-code, bring your own model and orchestration).
- For most SMEs and non-profits, declarative agents are the sweet spot: fast to build, secure, and grounded in your own data and permissions.
- As needs grow, a single agent doing everything degrades; the answer is a multi-agent system of focused specialists.
- An orchestrator agent routes work to child or connected agents, which can now collaborate through agent-to-agent communication.
- The guiding principle is “specialise agents, not prompts”, and to govern each agent’s identity and access carefully.
Two Ways to Build an Agent
Once you’ve decided to build your own AI assistant, one practical question comes next: how should you build it? Within the Microsoft ecosystem, there are two fundamentally different approaches. Understanding the difference helps you choose the right tool for the job, as well as the right level of investment.
The first and most accessible is the declarative agent. The name captures the idea neatly. Rather than programming the agent’s intelligence, you simply declare what it should be. You provide three things: instructions (how it should behave and what it’s for), knowledge (the data sources it can draw on, such as a SharePoint site or a set of documents), and actions (the things it can do, such as looking up a record or triggering a workflow). The agent then runs on Microsoft’s hosted orchestration and foundation models, the same AI engine that powers Microsoft 365 Copilot. In effect, a declarative agent is a customised version of Copilot that’s tailored to a specific purpose.
It helps to make those three ingredients a little more concrete.
The instructions are written in plain language, much like the role description you’d give a new team member. They define the agent’s purpose, tone, boundaries, and how it should respond when it isn’t confident. The knowledge might be a SharePoint library of approved policies, a handful of uploaded PDFs, or a connection to a business system through a connector. The actions are where the agent moves beyond answering questions and starts doing useful work, whether that’s creating a ticket, looking up an order, submitting a leave request or triggering a Power Automate flow.
All of this is assembled in Copilot Studio, a low-code environment that allows a capable business analyst or IT generalist to build a useful agent without writing traditional code.
The second approach is the custom engine agent. Here, you bring your own orchestration logic and AI models, typically using tools such as Azure AI Foundry or the Microsoft 365 Agents SDK. This is the pro-code path, giving you complete control over how the agent reasons, which models it uses and how it integrates with systems beyond Microsoft. That flexibility comes with a trade-off. You’re building and maintaining a software solution, with all the design, testing, hosting and operational overhead that comes with it.
| Declarative agent | Custom engine agent | |
| You provide | Instructions, knowledge, actions | Your own model, orchestration and code |
| Runs on | Microsoft’s hosted Copilot AI | Your chosen models (e.g. Azure AI Foundry) |
| Build effort | Low-code, fast | Pro-code, a development project |
| Best for | Most business use cases, grounded in M365 | Complex, bespoke or highly specialised needs |
For many SMEs, corporates, and non-profits, a declarative agent is the natural place to start, and often all that’s needed. It’s quick to build, doesn’t require a data science team, runs within Microsoft’s secure and governed environment, and automatically grounds responses in your own data while respecting existing permissions. You can build genuinely useful agents, such as an HR assistant, a policy guide or a client onboarding assistant, in a fraction of the time and cost of a custom solution.
A custom engine agent generally makes sense when the hosted platform can’t meet a specific requirement, such as using a particular model, implementing specialised reasoning, or integrating deeply with systems that don’t have existing connectors. For many organisations, that point may never arrive, and that’s perfectly fine.
When One Agent Isn't Enough
A single, well-designed agent can do a focused job extremely well. The challenge comes when one agent is expected to do everything.
As more knowledge sources, actions and responsibilities are added, quality can begin to decline. The agent suddenly has too many options competing for attention, making it harder to consistently choose the right source of knowledge or action. An agent expected to cover HR, IT, finance and customer service at the same time often ends up doing none of them particularly well.
The signs are usually easy to recognise. A payroll question gets answered using information from the IT handbook. The wrong action is selected, and the wrong type of request is submitted. Instructions become increasingly complex as they try to account for every possible scenario, making testing slower and more difficult because improvements in one area unexpectedly affect another. They’re all indicators that the agent has grown beyond the point where it can remain reliable.
This is exactly the problem that multi-agent systems are designed to solve.
Instead of building one overloaded generalist, you build a team of focused specialists that work together. The design question shifts from “How do I make one agent do everything?” to “How should I divide the work, so each agent does one thing well?”
It’s much the same as building a team within an organisation. You wouldn’t expect one person to run HR, finance, IT and customer service. AI agents benefit from the same kind of specialisation.
Microsoft summarises this philosophy well: “Specialise agents, not prompts.”
A well-scoped agent with a dozen focused capabilities will almost always outperform a bloated agent trying to do sixty things at once. Each specialist is easier to understand, test, maintain and improve without creating unintended consequences elsewhere.
How Agents Work as a Team
In a multi-agent system, one agent usually acts as the orchestrator. It’s the front door that understands the user’s request and decides how best to respond.
Behind it sit specialist agents, and there are two common ways they work with the orchestrator:
- Child (inline) agents are specialists created within the same solution. They share context with the orchestrator and are ideal for grouping related tools and knowledge into smaller, more focused capabilities. For example, an HR solution might include a dedicated leave and absence specialist that remains part of the broader HR agent while having its own focused instructions and responsibilities.
- Connected agents are independent agents with their own orchestration, tools and knowledge, often owned by different teams. The orchestrator simply delegates work to them when needed. This approach works well when an agent needs to be reused across multiple scenarios or has its own governance and ownership, such as a finance agent that’s shared across several business functions. Maintaining that capability in one place also avoids the same logic being rebuilt and gradually drifting out of sync across multiple solutions.
Increasingly, these agents can also communicate directly through agent-to-agent (A2A) communication, passing context and handing work between themselves as they move towards a shared outcome. They can also connect to external systems using open standards such as the Model Context Protocol (MCP), allowing them to access tools and data through a common interface instead of relying on custom-built integrations.
Behind the scenes, an AI planning layer interprets each request and decides whether to answer from knowledge, trigger an automated workflow, or delegate the task to another specialist. It’s a much more flexible approach than the rigid, menu-driven chatbots many organisations are familiar with.
A practical example helps bring it all together.
Imagine an agent responsible for preparing a client proposal. The orchestrator receives the request and coordinates a small team. One agent retrieves the client’s details from business systems, another drafts the proposal using approved SharePoint templates, a third validates pricing against company policy, and a fourth starts the approval workflow.
From the user’s perspective, it’s one seamless conversation. Behind the scenes, several specialised agents have each completed the part they’re best equipped to handle. If pricing rules change later, only the pricing specialist needs updating, and every proposal immediately benefits.
A Worked Example: A Membership Enquiry Agent
Picture a mid-sized non-profit that receives a steady stream of member enquiries: questions about renewals, event bookings, tax receipts and grant eligibility. Asking a single agent to handle all these responsibilities quickly becomes difficult. A multi-agent design keeps each responsibility focused.
An orchestrator greets the members and works out what they need. A membership specialist, grounded in the membership database, answers questions about renewals and membership status. A knowledge specialist, grounded in SharePoint policies and FAQs, handles eligibility and process questions. A finance specialist, managed by the finance team and reused across the organisation, issues receipts and confirms payments.
To the member, it feels like one helpful assistant. Behind the scenes, the work is shared between specialist agents that are each easier to build, test and govern. If the organisation later introduces a volunteer programme, it simply adds another specialist rather than expanding and complicating the agents that already work well.
Getting it Right and Keeping it Governed
Multi-agent systems bring a great deal of flexibility, but they also introduce design decisions that deserve careful thought. A few practical principles help keep them effective, secure and easy to manage.
- Don’t over-split. Not every task needs its own agent. Creating a separate agent only when a capability has its own domain requires different governance or permissions, or is likely to be reused elsewhere. Otherwise, a child agent, or even a well-designed single agent, is often the better option. Every additional agent introduces another component to build, test, monitor and maintain, so there should always be a clear reason for adding one.
- Let one agent speak to the user. In a well-designed system, the orchestrator is the single voice presented to the user. It combines information from specialist agents into one clear response. Specialists exist to perform specific tasks, not to respond directly. This keeps the experience consistent and avoids conflicting answers.
- Design identity and access deliberately. One area that deserves particular attention is identity and permissions. A connected agent may have access to data or actions that the orchestrator does not. It’s important to ensure delegation never becomes an unintended shortcut around those restrictions. If one agent isn’t allowed to delete records, calling another that can, shouldn’t become a loophole. Each agent should operate with a clearly defined identity, least privilege access, and appropriate logging. Where necessary, sensitive actions should still require human approval.
- Maintain a clear audit trail. Specialist agents generate their own activity records, making it important to understand how work flowed across the system. Being able to trace what the orchestrator requested, which specialist handled it, and what actions were taken makes troubleshooting significantly easier. When something goes wrong, that visibility often makes the difference between resolving an issue quickly and spending hours trying to understand what happened.
This is where good governance becomes just as important as good design. Identity through Microsoft Entra, data protection through Microsoft Purview, and clear operational oversight all help ensure a capable multi-agent system remains secure and trustworthy. As agents become more capable and collaborative, the value of those governance foundations only grows.
A Sensible Path for Organisations
The encouraging news is that none of this requires starting with a large or complex solution.
A practical approach is to begin with a single declarative agent that solves one genuine business problem. Prove its value first, then introduce specialist agents and orchestration only when there is a clear need for greater modularity. Multi-agent architecture is something you grow into, not something you need on day one.
Choose that first use case carefully. The strongest candidates are tasks that are common enough to deliver value, well understood enough to describe clearly, and grounded in content you already trust. An HR policy assistant, an IT service desk assistant or a guide to a well-documented business process are all good examples.
Give the agent clear instructions, reliable knowledge sources and a small number of safe actions. Then see whether it genuinely saves people time and earns their trust. Once it’s delivering consistent value, you can decide whether introducing specialist agents or an orchestrator would make the solution even stronger.
One of the strengths of Microsoft’s approach is that the same low-code platform, Copilot Studio, supports that entire journey. You can start with a simple declarative agent and gradually evolve it into a coordinated team of specialists, all within the same secure environment. That allows organisations to start small, build confidence and expand as their needs grow.
At 365 Architechs, we help organisations choose the right type of agent for each use case, build them on a secure foundation and design multi-agent solutions that are practical, scalable and well governed.
Thinking about building your first AI agent, or wondering when it’s time to introduce specialist agents? We’d be happy to help you design an approach that’s secure, practical and built to grow with your organisation.
