Sam's Dynamics, Power Platform & AI Blog

Thursday, 1 October 2026

Under the Hood of the New Copilot: Managed Runtime, Agent Identity and Copilot Credits

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:

bash
# Copilot Managed Runtime CLI (preview)
npm install -g @microsoft/managed-apps-cli
ms --version

# SDK package used inside the app
@microsoft/managed-apps

Why 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

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

The New Copilot: Home, Code and Autopilot. What It Means If You Build on Dynamics 365 and Power Platform

 On 25 September, Microsoft announced what it calls the new Copilot. I've read through it with one question in mind: what changes for those of us who design and build business apps on Dynamics 365, Dataverse and Power Platform?

The short answer is quite a lot. Most of it isn't about new buttons, though. It's about who builds things, where agents run, and how the bill gets paid.

What Microsoft actually announced

The new Copilot is organised around three spaces. Home brings Chat and Cowork together in one central place, and Microsoft is also building Word, Excel and PowerPoint directly into Copilot. Code lets users build apps and automations in natural language. It's based on the same technology as GitHub Copilot and is aimed at helping non-developers create their own solutions inside their organisation's environment. Autopilot is the newest piece. It was previously called Scout, and it's an always-on personal agent that lives in its own tab in the Copilot app. New Microsoft Copilot Brings Home, Code, and Autopilot Together - Source EMEA +2

Under the hood, Microsoft is improving Copilot's grounding with Fabric IQ, Work IQ and a new Plugin Registry so it can draw more fully on organisational data, processes and applications. microsoft

Code: the citizen-developer story gets a new front door

For years, "build it yourself" in the Microsoft world meant Power Apps and Power Automate. Code now offers a second route, starting from a sentence instead of a canvas.

The part I'd pay most attention to is hosting. Microsoft is introducing Copilot Managed Runtime, which hosts code inside a Microsoft 365 environment. It will support apps built in Cowork, Code and Copilot Studio, and it's also being opened to third-party and professional developers. channellife

For CRM teams, I see three practical questions:

  • Where does the data live? An app built in Code still needs a system of record. For customer data, that should still be Dataverse, not a new spreadsheet hidden behind a nice UI.
  • Who governs it? Your Power Platform CoE, environment strategy and DLP policies were built for makers. You'll want the same discipline here before people start shipping apps from chat.
  • Who maintains it? "Anyone can build" also means anyone can leave the company. Ownership and ALM don't go away because the code was generated.

Autopilot: an agent with its own identity

This is the change I think matters most for architects. Microsoft says Autopilot is cloud-hosted and operates with its own identity, memory, computer and workspace inside a customer tenant. channellife

An agent with its own identity is an agent that needs permissions. If it can work across your tenant while nobody is watching, then Dataverse security roles, business units, field-level security and column-level access stop being "nice to have". They become the actual guardrails. I covered this in an earlier post on what a Copilot agent can actually see. Autopilot makes that question more urgent, not less.

It's also why data quality matters. An always-on agent working from duplicate accounts and stale opportunities will do the wrong thing confidently and quickly.

The billing change is a design decision

A user subscription licence covers Copilot in Chat, Word, Excel, PowerPoint, Outlook and Teams, while usage-based billing applies to Cowork, Code, Autopilot and long-running agentic capabilities. Microsoft's admin documentation describes Copilot Credits as a common currency for eligible services billed by usage. technobezzdev

For consultants, that means estimating agent usage becomes part of the solution design, the same way we already think about API limits and Dataverse capacity. "Should this be a plugin, a flow or an agent?" now has a cost dimension as well as a technical one.

When can you use it?

Not quite yet for most people. Home and Code will reach testers through the Frontier program in the coming weeks, while Autopilot moves into private preview at the end of this month. Frontier requires a Microsoft Copilot licence and has to be switched on by an IT admin. Microsoft has also previewed things still to come, including Today in Home and @Copilot in Teams. Microsoft Adds Home, Code and Autopilot to Copilot +2

My take

For years the question was "how do I add AI to my CRM?" With this release, Microsoft is turning that around. Copilot becomes the place where work starts, and the CRM becomes one of the systems it reaches into.

That doesn't make Dynamics 365 less important. It makes the foundations more important: clean data, a sensible security model, proper ALM and governance that keeps up with the people now able to build. Those are the things to get right before Code and Autopilot reach your tenant.

I'll be testing these as they become available and writing up what holds up in real projects. If you're planning a Copilot or agent rollout on Dynamics 365 and want a second pair of eyes, get in touch.

Sources:


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


Wednesday, 30 September 2026

Generative pages in Power Apps: building model-driven pages from a prompt

Generative pages in Power Apps

You describe a page, and the agent writes React code for both the UI and the logic behind it. Think of it as a custom page where you don't need Power Fx.


Two ways to build

  • Browser — make.powerapps.com, conversational, no setup
  • Code tools like GitHub Copilot CLI — Microsoft's recommended route: newer models, works worldwide, and one request can build multiple pages plus the Dataverse tables they need


Before you start

  • Environment must be in the US, Great Britain, Australia or Singapore — otherwise the option won't appear and you'll need the code-tools route
  • Browser prompts are US English only
  • No extra AI or message credits needed

Build it

  1. App designer → Add page → Generative page → Describe a page
  2. Prompt with functional requirements first, then UX — name the columns
  3. Add data → Add table — max six Dataverse tables
  4. Optionally attach a sketch or wireframe
  5. Generate page

The agent shows its plan first — requirements and assumptions — then writes, transpiles and renders. Check the assumptions before iterating. Fixing a bad plan later costs more.

Iterate

  • Chat with the agent, or Edit on the Code tab — your edit saves as a new iteration
  • Compare diffs iterations, but only from the second iteration in the current session
  • The accessibility assistant scans each iteration; Auto fix hands violations back to the agent

Patterns worth knowing

  • Inputs: pages accept recordId, entityName and data — say so in the prompt and the agent writes the init code
  • Form embedding: form designer → Components → Display → Generative page. The record ID is passed in automatically, no config needed. This is the one I'd use most
  • Navigation: open a page with Xrm.Navigation.navigateTo, passing parameters
  • Data: everything goes through the dataApi object — read what it's calling
  • Connectors (preview): create a connection, then a connection reference in the Default Solution, and it appears under Add data → Connectors. Not for production yet

ALM

  • Solution-aware — add the app and sitemap; pages come across as UX Agent Project rows via the sitemap dependency
  • Missing from the dependency check? Make a small sitemap change, republish, export again
  • Only the first prompt and published code move to the target — the conversation stays behind. Write your intent down somewhere else

Limits

  • 50,000-character prompt maximum
  • One maker per page at a time
  • Model-driven apps only
  • Fixed list of supported column types — check before designing around anything unusual


My take

Microsoft is explicit: validating the generated code is your job. Check the dataApi calls, and make sure no rule that must hold has ended up in browser code. That belongs in a plugin.

Use it for dashboards, card galleries, Kanban boards and record panels on forms. Keep PCF for reusable field-bound controls and anything performance-sensitive.


Thanks for reading this article. Hope this Article will help you. Cheers!!!

Related Article: https://learn.microsoft.com/en-us/power-apps/maker/model-driven-apps/generative-pages


 #Dynamics365 #PowerPlatform #MicrosoftCopilot #DynamicsCRM #CopilotStudio #Dataverse #AIDeveloper #DynamicsAIEngineer #HireAIEngineer #AIEngineer #D365Consultant #CRMDeveloper #AIAgents #MSDyn365



Under the Hood of the New Copilot: Managed Runtime, Agent Identity and Copilot Credits

A technical guide for Dynamics 365 and Power Platform architects My last post covered what Microsoft announced on 25 September. This one i...