Building a Microsoft 365 Copilot Agent: Declarative or Custom Engine?

Start with the operating boundary

A useful Microsoft 365 agent has a narrow job, named users, approved knowledge, explicit actions, and a clear escalation path. Begin with the workflow and permission boundary, then choose the agent type. Starting with a tool because it is available usually produces a broad assistant that is difficult to evaluate and govern.

Choose a declarative agent when Microsoft 365 is the centre

Declarative agents use the Microsoft 365 Copilot orchestrator and model. They are configured with instructions, knowledge, and actions and can run in familiar Microsoft 365 surfaces such as Teams, Word, Excel, and Outlook.

This is often the best first option for department knowledge, onboarding, policy guidance, account preparation, or workflows that primarily use SharePoint, OneDrive, Microsoft 365 data, and a small number of controlled API actions.

• Use concise instructions that define scope, refusal behavior, source priorities, and escalation.
• Keep knowledge permission-aware and remove duplicate or obsolete content before blaming retrieval.
• Expose only the actions required for the job and validate their parameters server-side.
• Test with each target role because answers and available content can differ by user permissions.

Choose a custom engine when orchestration is the product

Custom engine agents provide control over models, orchestration, memory, integrations, and hosting. They fit multi-step workflows, specialized models, complex state, agent-to-agent coordination, or applications that must also operate outside Microsoft 365.

That control introduces more responsibility. The delivery plan must include hosting, identity, telemetry, evaluation, safety controls, lifecycle management, and a support model. Microsoft documentation notes that availability can vary for preview capabilities, so tenant and channel support should be confirmed during architecture—not after development.

Treat knowledge and actions differently

Knowledge answers a question; an action changes a system. Retrieval quality can be improved through source curation, descriptions, permissions, and evaluation. Actions also require authorization, idempotency, validation, audit history, and human confirmation for high-impact operations.

A strong pattern is read-first: let the agent collect context and propose the operation, then require confirmation before creating, updating, sending, or approving anything consequential.

A delivery sequence that scales

Move through discovery, knowledge readiness, a read-only pilot, controlled actions, evaluation, and staged rollout. Use development, test, and production environments and version agent definitions, connectors, prompts, and policies together.

• Define task completion and failure metrics before the pilot.
• Test permission trimming, prompt injection, stale content, unavailable tools, and partial failures.
• Publish to a small user group and review real questions before broad distribution.
• Assign an operational owner for content freshness, action failures, and agent changes.

The practical takeaway

Use a declarative agent when Microsoft 365 already provides the right model, interface, and governance boundary. Use a custom engine when differentiated orchestration or broader integration justifies the additional platform and operational work. In both cases, a focused workflow and measurable evaluation plan matter more than the number of connected tools.