Agent 365: Building Agents · 1 of 5
Declarative vs Custom-Engine Agents
The first design choice is whether to describe the agent or build the engine that runs it.
Most agent debates start too late, with tools, models, or user interfaces. The more important question comes first: are you asking a ready-made agent engine to do a well-defined job, or are you building the engine yourself? In Microsoft 365, that choice separates declarative agents from custom-engine agents. The difference shapes delivery speed, governance, integration depth, model choice, and operational responsibility.
The two build patterns
A declarative agent is described rather than programmed. You provide instructions, knowledge sources, and a defined set of actions. The shared Microsoft 365 Copilot orchestrator then decides how to interpret the user request, retrieve relevant context, and call the allowed actions.
A custom-engine agent works the other way around. You build or bring the orchestration yourself. You decide how the agent plans, which artificial intelligence model it uses, which systems it connects to, and when it should act.
This is not a maturity scale where one option is basic and the other is advanced. It is a control trade-off. Declarative agents optimize for speed, consistency, and inherited Microsoft 365 governance boundaries. Custom-engine agents optimize for precision, extensibility, and freedom to implement behavior the shared orchestrator does not provide.
What declarative really means
Declarative does not mean vague. It means the builder states the intended behavior in structured form instead of writing the full decision-making program. The agent is given a role, instructions, grounding knowledge, and a list of permitted actions.
In Microsoft 365, declarative agents provide low-code extensibility for Microsoft 365 Copilot. A maker can map natural-language requests to predefined actions and domain-specific knowledge without building a separate reasoning engine.
The important boundary is this: the maker controls what the agent is allowed to know and do, but does not control the underlying orchestration loop. The shared Microsoft 365 Copilot orchestrator and its foundation models handle the reasoning path underneath.
What you inherit with a declarative agent
The practical appeal of a declarative agent is not only that it is faster to build. It also inherits much of the surrounding Microsoft 365 environment because it runs through shared infrastructure that Microsoft already operates and governs.
That matters in enterprise settings. Identity, permission boundaries, compliance controls, and audit expectations are not afterthoughts. A declarative agent starts inside the Microsoft 365 compliance boundary instead of requiring the team to assemble every control around a new runtime from scratch.
This does not remove design responsibility. A poorly scoped action, a badly written instruction, or an overbroad knowledge source can still create risk. But the builder is configuring within an existing governed frame rather than creating the frame itself.
- Use declarative agents for bounded productivity tasks, guided workflows, and question answering over approved knowledge.
- Keep actions narrow, named, and testable so the shared orchestrator has a clear operating envelope.
- Treat instructions as policy-like configuration: review them, version them, and test them against misuse cases.
- Do not use a declarative agent as a shortcut for behavior that requires a custom planning loop or a specialized model.
What custom-engine really means
A custom-engine agent gives the development team control over the agent’s reasoning machinery. The team defines the orchestration: how requests are interpreted, how plans are made, how tools are selected, how failures are handled, and how results are checked.
It also opens model choice. The agent might use a general foundation model, a fine-tuned model trained further for a particular task, or an industry-specific model selected for a narrow domain. That choice can be essential when the shared Copilot model behavior is not the right fit.
Custom-engine agents can also perform proactive automation. Instead of waiting only for a user request inside a defined action set, the agent can programmatically trigger workflows across enterprise applications according to its own workflow logic.
The responsibility that comes with control
The custom-engine path is powerful because fewer decisions are predetermined. That same freedom means the team must provide the engineering discipline that the shared orchestrator would otherwise supply.
You must decide how the agent authenticates, how it receives authorization, how it stores or avoids storing data, how it logs decisions, how it handles tool failures, how it prevents unsafe actions, and how humans can review or override important outcomes.
This is why custom-engine agents are not simply declarative agents with more features. They are closer to distributed software systems that happen to use artificial intelligence. They need software engineering, security engineering, operations, and governance from the beginning.
A house analogy that holds up
A declarative agent is like moving into a house that already has foundations, wiring, plumbing, inspections, and basic services. You choose the rooms you will use, bring in furniture, and decide how people should move through the space. You can be productive quickly because the structure is already there.
A custom-engine agent is like designing and building the house yourself. You can place every wall, choose every material, and route every pipe exactly where you want it. But you are also responsible for the structure, safety, inspections, maintenance, and repair.
The analogy is useful because it avoids a common mistake. A furnished house is not inferior to a custom-built one if it fits the job. A custom-built house is not wasteful if the requirements truly demand it. The wrong choice is picking custom construction merely because it feels more advanced, or picking the furnished house when the job plainly needs a different foundation.
The decision leaders and builders actually face
For a practitioner, the decision often starts with feasibility. Can the task be fully described as instructions, approved knowledge, and a defined list of actions? If yes, a declarative agent is usually the simpler and safer first build.
For a leader, the decision is about operating model. Declarative agents let more teams build useful extensions while staying close to the Microsoft 365 governance frame. Custom-engine agents require deeper engineering ownership, but they may be the only fit for specialized models, unusual workflows, or proactive cross-system automation.
A good review does not ask which type is more impressive. It asks what must be controlled. If the answer is mostly content, permissions, and allowed actions, choose declarative. If the answer includes the planning algorithm, model behavior, external event handling, and proactive execution, choose custom-engine.
- Start with the smallest accurate description of the work the agent must do.
- Check whether instructions, knowledge, and a bounded action list are enough.
- Identify any requirement for a specific artificial intelligence model or custom planning workflow.
- Identify whether the agent must act proactively across enterprise systems.
- Choose custom-engine only when the extra control is worth the extra responsibility.
Key takeaways
- Declarative agents are described with instructions, knowledge, and actions, then run on the shared Microsoft 365 Copilot orchestrator.
- Custom-engine agents use orchestration, model choices, integrations, and automation logic built or selected by the development team.
- Declarative agents are usually faster to deliver and inherit more of the Microsoft 365 governance boundary.
- Custom-engine agents offer more control, including specialized models and proactive automation across enterprise systems.
- The practical trade-off is not simple versus advanced; it is inherited structure versus owned responsibility.
- Choose declarative when the task is bounded; choose custom-engine when the reasoning process itself must be custom.
Glossary
- Declarative agent
- An agent defined through instructions, knowledge sources, and allowed actions rather than through a custom reasoning engine.
- Custom-engine agent
- An agent whose orchestration, model choice, integrations, and automation behavior are built or selected by the development team.
- Orchestrator
- The component that coordinates how an agent interprets a request, uses context, selects actions, and produces a result.
- Microsoft 365 Copilot
- Microsoft’s assistant experience for Microsoft 365 that uses shared orchestration and artificial intelligence models to help users work with organizational content and tools.
- Foundation model
- A general-purpose artificial intelligence model that can perform many language or reasoning tasks and may be adapted for narrower uses.
- Fine-tuned model
- A foundation model that has been trained further on task-specific or domain-specific data.
- Proactive automation
- Agent behavior that triggers workflows or actions based on its own logic or events, not only in response to a direct user request.
- Compliance boundary
- The set of controls, policies, and operational limits that govern how data and actions are handled in an environment.