Product1 publisher2 min readPublished
Engineers get an SDK to maintain the apps Microsoft's Copilot lets analysts build
Microsoft's rebuilt Copilot adds a Code mode, one of three new sections, letting non-technical staff build apps and host them on a managed runtime. Engineers get an SDK to extend those apps, so IT ends up supporting software its colleagues wrote by prompt.
The Product Desk · Product desk
What happened
- Microsoft's rebuilt Copilot for Microsoft 365 has a Code section where non-technical workers build simple apps from prompts, such as a store-sales dashboard.
- The runtime ships with an SDK and a command line tool that engineers can use to refine the apps and link them to external services.
- A separate Autopilot section lets workers create no-code AI agents that run recurring tasks or act when specific business events occur.
- Microsoft IQ, the service that feeds company data into Copilot, can now draw on Dynamics 365 customer records and Power Platform.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- decision IT has to decide which shared apps need an owner before they spread, because the runtime removes the server setup step where that conversation would otherwise happen.
- cost Engineering hours go to refining and integrating apps written by colleagues outside the team, work Microsoft's own description hands to developers through the SDK.
- exposure Because Copilot can now draw on Dynamics 365 customer records, data IT already governs can end up underneath software that non-technical staff prompt into existence.
A business analyst describes a store-sales dashboard to Copilot and gets a working app back [2]. Kept as a desktop widget, it is hers. Published as a cloud service, it can reach every regional manager. Microsoft says its Copilot Managed Runtime handles that deployment with no manual configuration or maintenance [3][4].
Microsoft is selling the prompt. The step IT will answer for comes after it, when one person's tool becomes something colleagues depend on [4]. When a regional manager spots a number that looks wrong, Microsoft's own description has an engineer fixing it with the runtime's SDK and command line tool [5].
David Blyth, vice president and general manager of Microsoft's managed apps and agents group, set out the controls in a blog post [6]. "Identity and policy are enforced through the host. Monitoring, usage, and inventory give your organization visibility into what's been built, how apps are being used, and app health," he wrote [7]. He added: "Teams can preview and improve a new version while the current version remains available to users." [6]
Those controls tell IT what exists and how often it gets opened [7]. A usage count can't tell you whether a dashboard's sales figures are correct. Only someone who reads the query underneath can check that. The SiliconANGLE report on the launch does not include pricing for the runtime, and it does not say whether an app can be shared without IT signing off [12].
A simple 2x2 sorts the inventory. One axis is audience: a desktop widget for the author, or a hosted service colleagues can use [3][4]. The other is reach: the author's own files, or Dynamics 365 customer records and external services an engineer has connected [5][10].
Author-only apps on the author's own files can stay with the author. Once one of those is shared, it goes on the inventory with a named business owner who answers for its numbers. A personal app that reads customer records gets a data review. The fourth box, shared and connected, gets an engineering owner before it spreads further. That engineer can use the preview Blyth described to fix the app while the live version keeps running [6].
I'd put engineering hours only into that fourth box. The tradeoff is speed. Analysts wait longest on the apps the most people see, and the other three boxes rely on the analysts' own judgement plus a line in the inventory.
What to watch
- Pricing for Copilot Managed Runtime, and whether hosting shared apps is billed separately from existing Copilot licences.
- The admin settings that decide who can publish an app to the runtime and share it beyond a team.
- The planned feature that removes the manual switch between Chat and Code, since it could let a document request become an app without the user choosing to build one.