A technical guide for Dynamics 365 and Power Platform architects
My last post covered what Microsoft announced on 25 September. This one is about how it works: where the code runs, which identity the agents use, how Copilot gets its grounding, and who pays for what. Most of this is in preview, so treat it as a map for planning, not production guidance.
1. The architecture in one picture
Here's how I'd sketch the new stack, top to bottom:
The three experiences sit at the top. Everything else is plumbing, and the plumbing is where architects need to pay attention.
2. Copilot Managed Runtime: where generated code actually runs
When someone builds an app in Code, it has to be hosted somewhere. That's what Copilot Managed Runtime is for. Microsoft put it into public preview as a platform that runs code within the Microsoft 365 tenant boundary, governed by IT, while keeping features users expect such as sharing, live data connections and easy access to their apps.
Key technical points:
- Built-in auth and connectors. Apps built with the SDK include Microsoft Entra authentication without any custom code and can connect to more than 1,500 data sources, including Microsoft Graph, SQL and SharePoint.
- Source control by default. The platform provisions a managed Git repository when you create an app, so no extra setup is needed. You can also connect your own GitHub repo.
- Multiple entry points, one host. The Microsoft entry points are already live in Copilot Cowork, Copilot Code and Copilot Studio, and developers can use the SDK and plugins to build apps for the same host.
- Central inventory. Hosted apps show up in a new Apps experience in the Microsoft 365 admin center, where admins can review access, usage, health and policy in one place.
For pro developers, the tooling is a CLI and an SDK on npm:
# Copilot Managed Runtime CLI (preview)
npm install -g @microsoft/managed-apps-cli
ms --version
# SDK package used inside the app
@microsoft/managed-appsWhy this matters for Power Platform people: if you've worked with Power Apps code apps, this will feel familiar. One community write-up describes Managed Runtime as the name for what Code Apps was growing into, with the admin home moving from the Power Platform admin center to the Apps node in the Microsoft 365 admin center. That's a real shift in where makers' work gets governed. Your CoE team needs to look at both admin centres from now on.
My design rule: a Code app is a UI and logic layer. Customer, case and opportunity data should still live in Dataverse, where your security model, auditing and business rules already apply. Before you let teams build against CRM data, check in your own tenant which connector path they'll use to reach Dataverse.
3. Autopilot and agent identity
Autopilot is the piece that changes the security conversation.
Autopilot takes a role and a goal from the person who sets it up, then keeps working in the background without needing a new prompt for each step. Each Autopilot gets its own governed Entra identity and agent user account, which separates the agent's permissions and activity from those of its creator.
This builds on Microsoft Entra Agent ID, which Copilot Studio developers have been dealing with for months:
- An Entra Agent ID is a Microsoft Entra service principal with an "Agent" subtype.
- Since May 2026, Copilot Studio automatically creates an Entra Agent ID for each new agent. Before that, it created an Azure app registration per agent.
- No one in your tenant, including tenant administrators, can generate tokens using the agent identity.
- Every Agent ID is a directory object and counts against your tenant's Entra resource quota. If you hit the quota, agent creation fails.
A practical detail that's easy to miss: according to TechGig, as reported by Windows Forum, an Autopilot agent's governed Entra identity doesn't automatically come with email, a calendar or OneDrive. The model separates the agent identity (a service principal) from an optional agent user account that's flagged as an AI agent and needs licences.
What this means for Dataverse: an agent with its own identity is a new principal that needs access to your CRM. Before Autopilot or any persistent agent touches Dynamics 365, decide:
- Which identity reaches Dataverse? The agent's own identity (an application user with a dedicated security role), or the signed-in user's identity passed through? These give very different audit trails.
- What's the minimum security role? Start with read-only access on the specific tables the agent needs. Don't copy a human user's role.
- Which business unit owns it? Business unit scoping decides which records the agent sees. Get it wrong and you'll leak data across regions or divisions.
- Field-level security. Sensitive columns such as pricing, margins and personal data should be protected by column security profiles, not by hoping the prompt avoids them.
- Human sign-off. Microsoft says each agent runs with scoped credentials, approved-destination limits, optional human sign-off and Purview enforcement. Use the sign-off option for anything that writes to CRM.
Where to look:
- Power Platform admin center → Copilot → Settings → Entra Agent Identity for Copilot Studio to enable agent identities for Copilot Studio agents
- Microsoft Entra admin center → Agent ID to audit every agent identity in the tenant
- Power Platform inventory, which exposes per-agent fields such as whether the agent is part of a managed Dataverse solution. That's useful for checking that your agents went through proper ALM.
4. Grounding: Work IQ, Fabric IQ and the Plugin Registry
Microsoft says Copilot will draw more fully on organisational data, business processes and applications through Fabric IQ, Work IQ and a new Plugin Registry.
- Work IQ is the Microsoft 365 context layer. Its REST API lets custom apps hold multi-turn conversations with Microsoft 365 Copilot using enterprise and web search grounding, without building and maintaining your own vector indexes and orchestration. For developers, there's also an open-source plugin collection that connects GitHub Copilot to Microsoft 365 data through MCP servers and skills.
- Fabric IQ grounds Cowork on Power BI reports and their semantic models, but not yet on dashboards, paginated reports, lakehouses or eventhouses. One detail I like: sensitivity labels on the source data are respected, and new content Cowork creates inherits the label of the Power BI item it was grounded on.
- Plugin Registry: a plugin packages one or more capabilities, such as skills, MCP servers or agents, so Copilot can support your organisation's own workflows. Work IQ Developer Tools (WIQD) helps you package existing work into a plugin and publish it to the registry.
The Dynamics angle: if you already have Dataverse-backed logic, such as a Custom API, an MCP server or a Copilot Studio agent, the Plugin Registry is the route for making it available in Home and Cowork. Don't rebuild it from scratch. For reporting questions, a well-modelled Power BI semantic model on top of Dataverse now does double duty as Copilot's grounding through Fabric IQ. One more reason to invest in a clean data model.
5. Copilot Credits: cost becomes architecture
Billing has two layers. The user licence covers Copilot in Chat, Word, Excel, PowerPoint, Outlook and Teams. Usage-based billing applies to Cowork, Code, Autopilot and long-running agent work.
Key mechanics:
- Cowork usage counts model responses, tool and skill calls, image generation and browser tasks. Admins can set per-user or per-group limits.
- Credits are managed in two places: the Microsoft 365 admin center (Cost Management) for Cowork and the Work IQ API, and the Power Platform admin center for Copilot Studio agents and environment allocation.
- Copilot Credits are pooled at the tenant level, and Microsoft's own guide lists Dynamics 365 agents among the experiences that consume them.
- Managed Runtime apps consume credits each time an app launches and for each API call.
- At the time of writing, one credit is $0.01 at pay-as-you-go rates, with discounts for pre-purchase.
Design implications:
- Chatty agents cost money. An agent that polls Dataverse every few minutes looking for work costs more than one triggered by an event. Use Dataverse events, plugins or Power Automate triggers to wake the agent instead.
- Keep deterministic logic out of the LLM. If a rule can be a plugin, a business rule or a calculated column, don't make an agent "reason" through it on every run. That was already good design. Now it's also cheaper.
- Set budgets before go-live. Admins should set tenant, group and user budgets and spend alerts before a continuously running agent starts consuming credits.
6. Pre-flight checklist for CRM teams
Before Code and Autopilot reach your tenant, I'd work through this list:
- Inventory existing agent identities in the Entra admin center
- Review Dataverse security roles that any agent or app user will receive
- Apply field-level security to sensitive CRM columns
- Decide which environments and connectors Code apps may use, and align DLP across the Power Platform and Microsoft 365 admin centres
- Set up Copilot Credit budgets, per-group limits and alerts
- Agree an ALM path: agents and apps in managed solutions or Git, not built directly in production
- Clean up duplicate and stale CRM data before an always-on agent starts acting on it
- Pick one pilot use case with a measurable outcome and a named owner
7. Availability, as of today
Home and Code are coming to testers through the Frontier program over the coming weeks, and Autopilot moves into private preview at the end of this month. Frontier needs a Microsoft Copilot licence and has to be turned on by an IT admin. Copilot Managed Runtime is already in public preview.
Previews change, so check the Microsoft Learn pages on the day you configure anything.
Final thoughts
The headline features are Home, Code and Autopilot. The real story is underneath: a governed runtime for generated code, a first-class identity for every agent, a plugin model for grounding, and a meter on everything agentic.
For Dynamics 365 architects, none of this replaces the fundamentals. It raises the stakes on them. Security roles, data quality, ALM and cost-aware design are what decide whether these tools help your organisation or create a mess that's hard to clean up.
I'll test these hands-on as they land and post what I find. If you're planning agents on top of Dynamics 365 and want help with the design, feel free to reach out.
Want me to save this to Blogger as a draft with your usual labels, or make a 1200×600 header image to go with it?
Sources:
- Copilot Managed Runtime announcement – Microsoft
- Copilot Managed Runtime developer docs – Microsoft Learn
- Copilot Managed Runtime explained – recursion.no
- Copilot agents get identity and runtime – The New Stack
- App registration and agent identities – Microsoft Learn
- Migrate to Entra Agent ID – Microsoft Learn
- Autopilot Entra identities and admin controls – Windows Forum
- Autopilot megathread – Windows Forum
- Govern Copilot Studio agent identity – Cloud Harbor Consulting
- Copilot Studio agent inventory – Microsoft Learn
- New Microsoft Copilot – Microsoft Source EMEA
- Work IQ REST API – Microsoft Learn
- microsoft/work-iq – GitHub
- Fabric IQ in Cowork – Microsoft Learn
- Work IQ Developer Tools – Microsoft 365 Dev Blog
- Microsoft Adds Home, Code and Autopilot – Technobezz
- Manage Copilot Cowork – Microsoft Learn
- Copilot cost management guide – A Guide to Cloud
- Microsoft Copilot Credits Guide (PDF) – Microsoft
- Copilot Cowork credit-based billing – Windows Management Experts
Thanks for reading this article. Hope this Article will help you. Cheers!!!
#Dynamics365 #PowerPlatform #MicrosoftCopilot #DynamicsCRM #CopilotStudio #Dataverse #AIDeveloper #DynamicsAIEngineer #HireAIEngineer #AIEngineer #D365Consultant #CRMDeveloper #AIAgents #MSDyn365





