EBS Analysis: Compare declarative and custom engine agents

Posted on by escapebusinesssolutions in Uncategorized

Choosing Between Declarative and Custom Engine Agents for Microsoft 365 Copilot

Modern enterprises increasingly rely on AI‑driven assistants to streamline workflows, reduce manual effort, and surface insights from disparate data stores. Microsoft 365 Copilot brings generative AI capabilities to everyday productivity apps, but most organizations have domain‑specific needs that the out‑of‑the‑box experience cannot satisfy. The solution is to build agents – specialized AI assistants that can pull in custom data, call enterprise APIs, and orchestrate multi‑step business processes. Microsoft offers two distinct paths to create such agents:

  • Declarative agents – low‑code, plug‑and‑play extensions that run entirely within Copilot’s secure, cloud‑hosted orchestrator and foundation models.
  • Custom engine agents – fully engineered assistants where the organization controls orchestration, selects or trains language models, and adds custom hosting for higher flexibility.

Understanding the trade‑offs between these approaches is essential for architects, data scientists, and IT decision‑makers who want to deploy reliable, compliant, and cost‑effective AI assistants across Microsoft 365. The following article walks through the architecture, capabilities, implementation details, security implications, operational considerations, and practical decision criteria for each approach.

Core Components of an Agent

Whether declarative or custom, every agent shares a common set of layers that collectively determine how the assistant behaves:

  1. Knowledge – Structured instructions, domain rules, and curated data sources that shape the assistant’s responses.
  2. Actions – API calls, triggers, and workflows that let the agent modify external systems or initiate downstream processes.
  3. Orchestrator – The runtime engine that coordinates dialogue flow, decides when to call actions, and enforces policies.
  4. Foundation Model – The underlying large language model (LLM) that powers natural language understanding and generation.
  5. User Experience Layer – The integration points into Teams, Outlook, Word, Excel, SharePoint, Edge, or custom web portals, providing a seamless conversation UI.

Declarative agents rely on Microsoft’s Copilot orchestrator and foundation models, while custom engine agents bring their own orchestrator and model stack, often hosted in Azure.

Declarative Agents

A declarative agent is essentially a configuration file that tells Copilot “when I see this trigger, use these instructions, pull this data, and run this action.” Because the heavy lifting is handled by Microsoft’s cloud, the implementation is straightforward:

  • Custom instructions – Plain text or JSON that refines the model’s tone, style, or domain knowledge.
  • Custom knowledge – Connectors that expose Microsoft 365 data (Teams messages, SharePoint lists, OneDrive files) or external sources via the Copilot connector framework.
  • Custom actions – REST or Graph API calls that allow the agent to perform operations such as creating a Dynamics 365 lead, sending an email, or updating a SharePoint item.

Because the orchestrator, model, and compliance policies are all managed by Microsoft, declarative agents inherit the platform’s built‑in security, data residency, and responsible‑AI safeguards. This eliminates the need for the organization to host any infrastructure or manage model fine‑tuning.

Custom Engine Agents

Custom engine agents give architects full control over every layer of the stack. They are ideal when the business logic is highly specialized, requires multimodal inputs, or must interoperate with legacy systems not exposed via Copilot connectors.

  • Custom orchestration – Developers write workflows that dictate how the agent moves through conversation states, invokes APIs, and handles branching logic.
  • Custom models – The organization can select from Microsoft’s managed LLMs, host their own fine‑tuned models in Azure, or bring in third‑party models from other vendors.
  • Autonomy & proactive support – Agents can initiate actions on their own (e.g., “send a reminder if a ticket is overdue”), not just in response to user input.
  • Agent‑to‑agent communication – Multiple agents can collaborate, delegating subtasks, aggregating results, or escalating issues.

Because the orchestrator and models run outside Microsoft’s core Copilot infrastructure, organizations must provision, secure, and manage the underlying Azure resources. This introduces additional operational overhead but also opens the door to bespoke solutions that may not be possible within a purely declarative framework.

How the Technology Works

Below is a more granular view of the end‑to‑end flow for both agent types, illustrated with the common use case of an “IT Helpdesk Agent” that answers @mentions in Teams and creates support tickets.

Declarative Agent Flow

  1. Team member mentions the agent: @HelpDesk.
  2. Copilot’s orchestrator receives the mention, parses the natural language intent.
  3. Using the declaratively defined custom instructions, the LLM generates a concise response.
  4. When the response requires data, the orchestrator pulls from a custom knowledge source (e.g., a SharePoint list of known issues).
  5. To create a ticket, the orchestrator calls a custom action – a predefined REST endpoint that writes to a ticketing system.
  6. All interactions are logged, encrypted, and audited by Microsoft’s compliance framework.

Custom Engine Agent Flow

  1. User triggers the agent via Teams or a custom web UI.
  2. The custom orchestrator (hosted in Azure App Service, Azure Functions, or a Kubernetes cluster) receives the message.
  3. It tokenizes the input, consults a local or remote knowledge base (e.g., an Azure Cognitive Search index).
  4. The orchestrator then sends the prompt to a custom LLM – perhaps a fine‑tuned model hosted on Azure ML or a third‑party service.

  5. EBS Consulting Advice

    If your organization is evaluating Compare declarative and custom engine agents, do not treat the technology decision in isolation. Start with the business outcome, current architecture, security and identity controls, operational constraints, migration dependencies and governance requirements. A practical assessment should identify the current-state gaps, prioritize the risks and define an implementation roadmap with measurable outcomes.

    EBS can help assess the environment, develop the architecture and modernization roadmap, and translate the technical options into an actionable business plan. Relevant EBS services: Microsoft Azure consulting Escape Cloud Microsoft Solution Assessments.

    Have a technology challenge? Email info@escapebusinesssolutions.com to describe your situation. We welcome questions, consulting discussions and requests for a proposal.

    Discover more from Escape Business Solutions

    Subscribe to get the latest posts sent to your email.