Declarative Agent in M365 copilot

Question

We're developing a declarative agent for Microsoft 365 Copilot with the following characteristics:

• Distribution: Available to any user with a valid M365 Copilot license.
• Backend: The agent invokes a REST API hosted on Azure App Service.
• Data source: The API retrieves results from an Azure AI Search service backed by our own indexes.
• Grounding: Responses must be grounded exclusively to our internal data — no external knowledge.

We'd like recommendations on the right tenant strategy for our Dev, Test, Staging, and Production environments. whether to use TME/CORP/AME/PME

Answer 1

Hello Shubham Jain,

For a declarative agent in M365 Copilot with strict internal grounding, a multi-tenant strategy is recommended for proper isolation and validation.

Use TME for development and early functional testing, as it allows safe iteration without impacting enterprise policies. Move to AME (or PME) for staging and integration testing, where you can validate Copilot behavior, authentication flows, and API interactions in a more enterprise-like environment. Choose PME specifically if you need partner/external validation scenarios; otherwise AME is sufficient for internal validation. Use CORP only for final production readiness checks, compliance validation, and controlled rollout. Ensure strict separation of environments by using different Azure AI Search indexes, API endpoints, and Entra app registrations per tenant. This approach helps maintain data isolation, validate grounding behavior correctly, and align with enterprise security and governance expectations.

Answer 2

The context describes how to build and configure declarative agents, but does not define or compare tenant strategies such as TME/CORP/AME/PME or provide guidance on how to split Dev/Test/Staging/Prod across tenants. It only states that declarative agents:

• Run entirely within a Microsoft 365 tenant and inherit that tenant’s security, compliance, and governance.
• Use configuration (instructions, knowledge, actions) plus Copilot’s orchestrator and models.
• Can be built and hosted without additional infrastructure beyond the external APIs and data sources they call.

From the context, the only supported, concrete guidance that applies to environment strategy is:

1. Declarative agents are tenant‑scoped
   • Agents are configured and distributed inside a single Microsoft 365 tenant and are controlled by that tenant’s admins via the Microsoft 365 admin center.
   • Enterprise admins manage distribution and visibility of agents within that tenant.
2. External systems (like Azure App Service and Azure AI Search) are environment‑specific
   • The agent’s “actions” are API plugins pointing to external systems (for example, the REST API on Azure App Service and Azure AI Search indexes).
   • Each environment (Dev/Test/Staging/Prod) is typically represented by different API endpoints and data sources, which are wired into the agent via its manifest and plugin configuration.
3. Grounding to internal data only
   • Declarative agents can be configured to use only specified knowledge sources (SharePoint, OneDrive, connectors, API plugins, etc.).
   • Best practice is to add only the relevant knowledge sources and ensure they are accurate and up to date for the environment.

Because the context does not describe or recommend any specific multi‑tenant strategy (such as using separate tenants for Dev/Test/Prod or specific tenant types like TME/CORP/AME/PME), it only supports the following general, tenant‑agnostic principles:

• Treat the declarative agent configuration (instructions, knowledge sources, actions) as environment‑specific configuration that can be changed per environment.
• Use environment‑specific knowledge sources (for example, Dev/Test/Prod SharePoint sites or indexes) so that grounding remains restricted to the correct internal data set.
• Use environment‑specific API plugin endpoints (for example, different Azure App Service and Azure AI Search instances) per environment.
• Rely on the tenant’s built‑in security, compliance, and governance for any environment where the agent is deployed.

Any decision about whether to use separate tenants (TME/CORP/AME/PME) for Dev/Test/Staging/Prod is outside the scope of the provided context.

---

References:

• Agents for Microsoft 365 Copilot
• Declarative agents for Microsoft 365 Copilot
• Declarative agent architecture
• Best practices for building declarative agents
• Choose the right tool to build your declarative agent
• Declarative agent schema 1.3 for Microsoft 365 Copilot