Power Apps With Agents: Building Is No Longer the Bottleneck
AI agents can now create and edit canvas apps in Power Apps through MCP. What changed, what it demands from IT, and how to adopt it without losing control.
Sebastian Mera · Growth Strategist & Automation Specialist
Microsoft has released canvas app authoring with AI agents. Speed is no longer the problem; the challenge now is deciding who delegates what, with which data, and under what rules.
An operations analyst asks for an app to log field inspections. Their department’s backlog already has 14 similar requests. The usual answer: “it’s on next quarter’s list.”
That “next quarter” just lost its technical justification.
Since September 2026, an AI agent can create screens, connect data, and write Power Fx formulas inside a real canvas app, while a person reviews the result in Power Apps Studio. It’s not a throwaway prototype or a mockup generator. It’s the same app your team already knows how to govern, test, and deploy.
This article explains the image Microsoft uses to present this capability, what changed in concrete terms, and above all, what IT needs to decide before every department starts asking an agent for apps.
| Figure | What it means |
|---|---|
| September 1, 2026 | Microsoft announced general availability of canvas app co-authoring with agents; it’s now suitable for production workloads |
| More than 1,400 connectors | The agent works on top of the same ecosystem of connectors and governance controls as always |
| .NET 10 SDK | Local requirement to run the MCP server; it means managing makers’ workstations |
| November 15, 2026 | Release Planner retires; updates move to continuous publication |
The Image, Piece by Piece
The diagram summarizes an architecture in three beats: context, orchestration, and outcome.
On the left: what the agent needs to know
Five sources feed the agent:
- Dataverse: business data and logic. The data model you already have.
- Azure: services and APIs for what low-code can’t solve on its own.
- Connectors: external systems, from ERP to CRM.
- Code: custom components and logic.
- Your context: requirements, documents, and patterns from your organization.
That last block is the most underrated. An agent without context produces generic apps. One with your design standards and business rules produces apps that look like yours.
In the center: the agent and the protocol
The Power Apps Canvas Authoring Agent receives tools and data. Above it, Copilot and AI agents run a cycle: understand, plan, act. Below sits MCP, described as a standard way for agents to interact with tools and services.
On the right: the app, ready
The “Build & update” arrow ends in a working app. The caption’s promise: build, extend, maintain. Faster.
The bottom strip assigns a role to each product: Power Apps builds, Dataverse unifies, Azure scales, and Copilot accelerates.
The image doesn’t show a new tool. It shows a new front door to a platform you already administer.
What Actually Happened: From Preview to Production
The capability didn’t appear this month. The MCP server behind it has been published on NuGet in preview versions since April 2026, with nearly monthly updates through version 1.1.5 on August 31.
What matters is the jump to general availability. According to Microsoft, you can now integrate collaboration with agents into production development practices, on top of existing canvas apps and without starting from scratch.
For an IT manager, “GA” changes the conversation. It’s no longer an experiment by a curious maker. It’s a supported capability that will reach your tenant whether you planned for it or not.
One more detail: Microsoft stopped publishing semiannual release plans and moved to a continuous roadmap. Waiting for “the next wave” to evaluate new features no longer works as a strategy.
MCP: The Plug That Makes It Possible
The Model Context Protocol (MCP) is an open standard that lets an AI agent discover and use external tools in a structured way. Think of it as a contract: the tool declares what it can do, and the agent invokes it without custom integrations.
In Power Apps, the MCP server gives the agent a concrete set of capabilities. According to Microsoft, agents can create and modify apps and screens, inspect controls, connectors, and data sources, understand schemas, configure controls, write Power Fx formulas, and validate changes by syncing them with a live co-authoring session.
The strategic consequence is that you choose the agent. The official documentation mentions GitHub Copilot, Claude Code, or any other tool that supports MCP servers and agent plugins. There’s no single AI vendor tied to the platform.
Co-Authoring, Not Autopilot
The workflow is less magical and more useful than the marketing suggests:
- Prepare the app. The app must exist in Power Apps, saved in the right environment and with co-authoring enabled, even if it’s empty.
- Connect the agent. The maker links their local tool to the session open in Studio.
- Describe the need. In natural language: “a requests screen with a status filter.”
- Generate and validate. The agent generates .pa.yaml files with screens, controls, and formulas, validates them with the MCP server, and fixes errors.
- Review and adjust. Changes show up in Studio, where a person tests and refines.
The key point is in step 4. The app’s source code lives in readable files, so every contribution from the agent is visible and reviewable. That enables something traditional low-code did poorly: version control and change review, just like any software project.
An app you can review line by line is an app you can audit.
What the Agent Speeds Up (and What It Doesn’t)
Where it delivers:
- Repetitive screens that follow a common pattern.
- Broad refactors across existing apps.
- First working versions from a clear requirement.
- Maintenance: adding filters, fields, or views without rebuilding the app.
Where it doesn’t replace anyone:
- Defining the right data model in Dataverse.
- Deciding which connectors are acceptable under your data policy.
- Validating accessibility, security, and compliance.
- Understanding the business process the app must support.
Microsoft says it plainly: the tool tries to generate production-ready code, but responsibility for validating it remains with your organization.
The Cost Nobody Puts in the Proposal
Every instruction to the agent consumes tokens. Microsoft openly acknowledges this and recommends using the agent where it adds the most value, such as generating related screens, and making small changes by hand.
This has concrete financial implications:
- Agent licensing: each maker needs access to a compatible AI tool, with its own license cost.
- Variable consumption: a broad refactor can cost more than doing the work manually if the requirement is poorly defined.
- Workstations: the .NET 10 SDK requirement means managing software on makers’ machines.
If you’re presenting this to the board, don’t sell “free, fast apps.” Sell shorter delivery times with a variable cost that can be measured and capped.
How to Start Without Breaking Anything
- Pick a narrow use case. An internal app, with non-sensitive data and a committed business owner.
- Use a development environment. The official guidance recommends validating generated changes in a non-production app before applying them to production.
- Apply least privilege. The account connecting the agent should only be able to edit the target app.
- Review your DLP policies. The agent respects existing connector restrictions; make sure they’re well defined.
- Define what gets reviewed. Establish who approves the generated .pa.yaml files before publishing.
- Measure. Compare development hours and AI consumption against a similar app built manually.
Objections From a Skeptical Manager
“This is going to multiply apps without control.” The risk exists, but it isn’t new: low-code shadow IT already happens. The difference is that generated apps now live in reviewable files and under the same environment and connector policies. The problem isn’t the agent; it’s not having governance in place beforehand.
“What about the security of connecting an external agent to my tenant?” It’s a valid concern. Microsoft notes that credentials are handled with the Azure Identity SDK, without storing tokens, and warns about indirect prompt injection attacks. Administrators can also block agent plugins, third-party MCP servers, or local MCP processes. You keep control; you have to actively decide how to use it.
“My makers aren’t developers. Are they going to use a terminal?” Some will, others won’t. There’s an installation path from Visual Studio Code that lowers the friction, but the ideal profile today is an advanced maker or a fusion developer. Don’t roll it out broadly in the first month.
IT’s New Job
For years, the argument against the backlog was capacity: too few developers, too many requests. That argument weakens every time an agent generates in minutes a screen that used to take days.
What doesn’t weaken is the need for judgment. Which data to expose. Which processes deserve an app. What quality is acceptable. Who answers when something breaks at 3 a.m.
When building gets cheap, governing becomes the competitive advantage.
The IT teams that define their rules of the game today will be the ones that capture that speed. The ones that wait will find agents working in their tenant under rules nobody wrote.
The agent is ready. The question is whether your governance is too.
Sources
- Microsoft Power Platform Blog — Turbocharge your canvas development with the canvas authoring agent plugin – now generally available! (September 1, 2026)
- Microsoft Learn — Create and edit canvas apps with AI code generation tools
- NuGet — Microsoft.PowerApps.CanvasAuthoring.McpServer
- Microsoft Learn — Power Platform 2026 release wave 1 plan overview
- HubSite 365 — Power Platform: No More Release Waves
- GitHub — microsoft/power-platform-skills
