Thurrott first highlighted the expansion on September 16, and Microsoft’s September 10 announcement confirms the two entry points. Cowork users in the Microsoft Frontier program can invoke the /app skill today; Copilot Studio’s App (Preview) tile was scheduled to enter public preview during the following week. Microsoft’s current documentation supports the availability of the Cowork skill but does not publish a tenant-by-tenant completion notice for the Copilot Studio rollout.
This is a meaningful expansion of Copilot Studio’s remit. The product has been positioned principally as a way to create agents and automated workflows. Microsoft is now putting interactive applications alongside those components, with the intent that a business user can describe an outcome, attach or reference organizational context, refine the result conversationally, inspect it, and publish it.
Cowork’s App Skill Is a Publishing Path, Not a Mockup Tool
Microsoft calls the Cowork output a “lightweight, interactive” app, and that wording should temper expectations. This is not an invitation to replace a carefully engineered desktop client, a line-of-business system with complex regulatory requirements, or a mature Power Platform application built around formal solution management. It is aimed at narrowly scoped internal tools: an onboarding tracker, a data visualization, a guided field-service form, or a team-specific workflow interface.
But the feature is more than a static prototype generator. Microsoft’s documentation says a Cowork user can open the generated app, make iterative changes through the chat, preview those changes, publish the current version, and share it with other users. That makes the permission boundary around publication more important than the prompt that creates the first screen.
Microsoft says Cowork can use context from documents, spreadsheets, meetings, messages, OneDrive, SharePoint, Teams, and organizational search. In a well-governed Microsoft 365 deployment, that can make a departmental tool useful quickly because a user is not starting with an empty database or manually exporting CSV files. It also means the generated app can reflect whatever data access the requesting identity already has.
The company says actions in Cowork require approval, including sensitive actions such as sending email or posting a Teams message. That approval model is helpful for an individual session, but it should not be mistaken for an administrative review of the finished application. A user approving an action while testing an app is not the same thing as security, compliance, data owners, and platform administrators agreeing that the application should be shared.
The other caveat is status. The Cowork App skill remains a Frontier feature, subject to Microsoft’s preview terms. Microsoft expressly says preview capabilities can have restricted functionality, can change over time, and may never reach general availability. An organization can sensibly use it to explore internal use cases, but it should avoid making a critical process dependent on it before the product, lifecycle model, support terms, and controls settle.
Copilot Studio Adds Code Inspection and Deployment Concepts
In Copilot Studio, Microsoft describes the feature as agentic coding that produces a working app scaffold from a plain-language description of users, data, actions, and the intended business result. Makers can continue revising the app through natural language, preview it, and inspect the underlying code. That last element separates this from a simple no-code form designer and gives developers a potential route to take over a generated starting point rather than rebuilding it from scratch.
Microsoft also says the generated applications use open standards and can support Git-backed source control, deployment stages, and version isolation. Those are the right terms for enterprise application delivery, but the announcement does not define which source-control providers, application frameworks, export options, environments, or CI/CD operations are supported in this preview. Nor does it say whether every app generated in Cowork has the same code visibility and deployment behavior as one created from the Copilot Studio home screen.
Those omissions matter before a team treats the capability as a standard development channel. “Git-backed” does not by itself answer where repositories live, who owns them after a maker leaves, how secrets are handled, whether code can be scanned in the organization’s existing pipeline, or how a rollback is performed after an app is published. Microsoft has announced the direction; administrators should verify the actual experience in a non-production environment before promising a lifecycle model to business units.
The distinction between the two front ends is still useful. Cowork makes app creation a conversational skill inside a product already used for Microsoft 365 tasks. Copilot Studio places application building next to agents and workflows, where a Power Platform or automation team is more likely to be involved. The first lowers the barrier to entry sharply; the second provides a more natural home for teams that need to turn an early idea into something operational.
Entra and Connector Policies Are the Real Gatekeepers
Microsoft’s central claim is that apps created through Cowork and Copilot Studio respect Microsoft Entra identity, organizational-data controls, and connector policies by default. If that is borne out in deployment, it addresses the most obvious enterprise objection to prompt-generated apps: a business user should not get a new route around existing identity and data-access controls simply because the app was created with an AI assistant.
The word “respected” is doing important work here. An app that uses an approved connector can still create a poor business process if its creator grants broad access, exposes inappropriate fields to a group, writes inaccurate records back to a connected system, or publishes an interface that lacks the validation expected by the system owner. Identity enforcement limits access according to existing permissions; it does not establish that the app’s workflow is correct, complete, or safe.
Microsoft’s own examples show why. An employee-onboarding app might read a worker’s progress from one source, show learning resources, and update onboarding records in another. A field-service app could retrieve technical information from a third-party system, guide a worker through steps, and write the completed result back. Those are useful scenarios, but both touch data that often has named owners, retention requirements, business rules, and audit expectations beyond ordinary document access.
Admins should treat the connector policy inventory as the first control point. Before enabling broad access, review which connectors are permitted in the relevant environment, whether makers can create or use custom connectors, and whether data-loss-prevention policies distinguish business data from personal or external services. The app builder’s prompt can be informal; the data path cannot be.
The Cost Switch Is Tied to Cowork
Microsoft’s billing documentation fills in a major operational detail not emphasized in the feature announcement: building and using apps created with Cowork is governed by usage-based billing through Copilot Credits. The Microsoft 365 admin center’s Cost management area can apply spending policies, choose eligible users or groups, set organization-level and user-level limits, create alerts, and review consumption by service, user, group, agent, and funding source.
More importantly, Microsoft states that enabling or disabling Cowork also enables or disables its app-building capability by default. That creates an immediate governance decision. A tenant that enabled Cowork for AI-assisted research, document creation, or task automation may have also opened the door to app construction unless an administrator has separately accounted for the App skill’s availability and Frontier status.
Microsoft says applications built with Cowork are listed under Apps in the Microsoft 365 admin center, which provides an inventory, operational health monitoring, and policies for content security, data access, and application usage. Published apps are also intended to be discoverable through Microsoft’s managed-apps service. This is a more structured model than employees passing around a local HTML file or a personal low-code project, but it creates a new catalog that IT must own.
The sensible rollout is therefore selective. Enable the capability first for a small maker group that includes Power Platform administrators, security staff, data owners, and developers who can inspect the generated code. Put those users under a bounded Copilot Credit spending policy, restrict the connector set, require review before publication to a broad audience, and define ownership for every published app. Then test what the admin-center inventory actually reveals: creator, users, connector dependencies, data sources, version history, usage, and a way to retire the app.
Microsoft has moved from helping workers draft content to helping them create deployable software inside the same Microsoft 365 boundary. The immediate question for enterprise IT is no longer whether users can ask Copilot to make an app. They can. The decision is whether the organization has set the data, cost, ownership, and publication rules before those apps begin appearing in its admin center.