From Prompt to Published App: Copilot Managed Runtime in Practice

A single prompt in Copilot Cowork produced a three-screen internal app, published into a Microsoft 365 tenant under existing governance, with the agent reporting its own failures at the end. This is what the run showed, what it did not, and the questions it leaves open.

What Copilot Managed Runtime is:

Copilot Managed Runtime is the hosting and execution layer behind Microsoft’s new app-building capability in Copilot Cowork and Copilot Studio. In plain terms: you describe an application in natural language, an agent writes real code (TypeScript and React in this case), and Microsoft runs that code for you inside your Microsoft 365 tenant.

Three facts from that post shape everything below:

• Apps use Microsoft Entra authentication and follow the tenant’s existing connector, environment, data and sharing policies. Nothing new is bolted on.
• Makers are routed to an isolated personal developer environment by default, with environment routing applied automatically where it was not already configured.
• Consumption is billed through Copilot Credits in the Power Platform admin centre, not a separate SKU.

So this is not a shadow-IT tool living outside the platform. It is a new front door onto the Power Platform, with a code-generating agent behind it.

The brief

I gave it a deliberately ordinary internal problem: delivery managers at Kerv need a single view of live client engagements, and that data currently lives in a spreadsheet. The prompt, lightly paraphrased, was:

Build a Kerv internal application called Engagement Health for delivery managers to track live client engagements. Apply the kerv-app-design skill for all visual and component decisions. Use the attached engagements.xlsx (OneDrive) as the data source; do not invent additional clients. The app needs three screens: a dashboard with a summary row and filterable engagement table; an engagement detail screen with the record’s fields, its risk list and an “Update status” form that writes back to the spreadsheet; and a read-only client summary view.

Three constraints were doing the real work:

1. A skill, not a style guide. kerv-app-design is an Agent Skill: a folder of instructions, design tokens, component patterns and acceptance checks that the agent reads before it builds. The test was whether it would apply them unprompted.
2. One data source, no invention. Excel in OneDrive, twelve fictional engagements, nothing else. If it fabricated a client or a figure, the demo failed.
3. Write-back. Reading a sheet is easy. Saving a form back to it through a governed connector is where most low-code demos quietly stop.

All twelve engagements and every named person in the workbook are fictional.

What happened

The run took one approval from me and produced a published app, a Word design note and a list of its own defects. In order:

1. It read the skill first. Before touching the workbook, Cowork opened kerv-app-design and logged “Reviewed custom skill”. The skill’s procedure (confirm the single job, choose the shell, apply tokens, use component patterns, run the checks) became its plan.
2. It planned in four steps and showed them. Read the workbook; create the app and connect it; build the three screens; check the app and open a preview for approval. The plan sat in a side panel and ticked off as it went.
3. It stopped for permission. Creating the Excel Online connection was surfaced as a “Connection create, Medium risk” card with Approve and Cancel. Nothing touched data until I approved. This is the Power Platform connector model showing through, not a feature of the agent.
4. It generated real code and audited it. TypeScript interfaces derived from the workbook schema, a React app with routing, and a running checklist: spacing on the 4 px scale, no hard-coded colours, contrast ratios at or above 4.5:1, a dev server, a preview check.
5. It previewed and flagged deviations before I asked. The preview showed the dashboard (twelve live engagements, two red, four amber, a milestone runway drawn from the workbook dates), the filterable table, the detail screen and the update form. Alongside it, the agent had already listed where it departed from the design guide: no tenant switcher in the sidebar, the Manrope typeface falling back to Segoe UI, status chips darkened for contrast.
6. It published and documented in parallel. On approval it published to the tenant and, as a background task, wrote a one-page design note in Word covering shells, tokens, components used from the library, components it had derived, and known deviations.
7. It reported what it had not done. The final summary said plainly that it could not open the published URL to test live data, that the Word note had come out in Word’s default blue rather than Kerv purple, and listed the design checks that failed. It asked whether to fix them in one pass.
8. Write-back worked. In the live app I changed one engagement’s RAG to red, its phase to Deploy, its next milestone and its budget to 80%. “Save to workbook” wrote all four fields to the correct row in Excel Online. The read-only client view reflected the change immediately.

The published app appeared in the Microsoft 365 Apps hub alongside other organisational apps, under my Entra identity.

Three things that matter:

1. Governance is inherited, not added. The approval card, the environment routing and the connector policy were not features of this demo; they are the Power Platform’s existing controls, and the agent operated inside them. That changes the risk conversation. The question for an IT leader is no longer “how do we govern AI-built apps?” but “are our existing DLP policies, environment strategy and connector controls actually fit for purpose?” For many organisations the honest answer is that they were set up for a few hundred makers, not for every Copilot licence holder being able to ship an app.
2. Skills are the new design system. A Power Apps component library enforces consistency by giving makers pre-built parts. A skill enforces it by giving the agent rules, tokens and checks to apply and verify. The agent did not merely use our colours; it checked its own contrast ratios, flagged where a font had fallen back, and told me which of our rules it had broken. For a partner, this is the interesting commercial surface: the design system, the accessibility standard and the data conventions become a maintained artefact that every generated app inherits, and the agent polices it on every build. Our work on a shared skills library across the Kerv group is a direct consequence.
3. It reported its own failures. The most useful output was the list of checks it had not passed and the gaps it had not closed. An agent that says “done” when it is not done is dangerous in proportion to how fast it works. One that produces a defect list and asks for direction is something a delivery team can actually work with. Whether this behaviour holds under less favourable prompts, or at the twentieth iteration rather than the first, is an open question worth testing before relying on it.