Status: Public Preview — behaviour may change.
What it does
An agent pane in canvas studio that builds and edits a canvas app from a plain-language description. It proposes a plan, waits for your approval, then writes the screens, controls and Power Fx directly into the app you have open. The result is an ordinary canvas app you carry on refining by hand or by prompt.
Key facts
- Preview, United States only, English only.
- Needs a tenant admin to switch on Agentic Coauthoring in Power Apps using GitHub under tenant settings in the Power Platform admin centre. Accepting the terms there is what makes it available.
- Each maker signs in with their own GitHub account. GitHub runs the authoring tools and bills that account; prompts and app context are processed under the GitHub terms for that account, not Microsoft's.
- It works from the data sources already in the app, so add those first. It can't add or edit data, can't add images, and can't save, publish or share the app.
- You can use it on an existing canvas app as well as a new one, provided the environment meets the eligibility requirements.
- The model is fixed and you can't change it in the studio integration.
- It's a different thing from the Canvas Authoring MCP plugin, which lets you drive canvas authoring from an external coding agent such as GitHub Copilot CLI or Claude Code.
When to use / skip
Worth a look for scaffolding a first version of an internal app when a maker can describe the users and tasks clearly and the data is already connected. Skip it for anything client-facing, anything regulated, or any tenant where sending prompts and app context to GitHub is going to cause a data-handling argument. The plan-then-approve step is genuinely useful; it's the only point where you can correct a wrong assumption cheaply.
Configuration decisions
- Whether the tenant setting is enabled at all, and who gets told. It's tenant-wide, not per environment.
- Whether makers use personal GitHub accounts or organisational ones. That decides who pays and whose terms apply to the prompts.
- Which data sources go into the app before the agent starts, since it can't add them itself.
- Who reviews the generated app before it's shared, because the agent won't publish it for you and nothing guarantees the formulas are right.
Gotchas
- The GitHub billing and data-processing terms are the part security and procurement teams object to. They're easy to miss in a Power Apps feature that otherwise looks like a Microsoft one.
- The canvas only updates as the agent applies changes, so you may see nothing take shape until well into the build. You can also see app checker errors mid-run. Wait for Task completed before judging it.
- The plan lists assumptions, such as how it'll identify the signed-in user. If it can't verify one, it says so. Skim past that and you'll find out in testing.
- Larger apps can take several minutes to build, and you can stop a run in progress.
- US-only means a UK or EU maker simply won't see a working version, whatever the tenant setting says.
Consultant notes
- Don't promise it as a delivery accelerator in a statement of work. It's preview, US-only and English-only, so it's a demo and an experiment, not a plan.
- Raise the GitHub dependency with the client's security lead before the demo, not after. "Your prompts go to GitHub" is a very different conversation from "Copilot builds your app".
- Treat the output as a first draft with a lot of assumptions baked in. Code review and a proper test pass still apply, and generated Power Fx often needs tidying for delegation and naming.
- If the client is already using external coding agents on canvas apps, work out which route they actually want. The two approaches have different governance and billing, and running both loosely is how you end up with neither controlled.
Preview feature — worth revisiting once it leaves the US-only, English-only restriction.