An official AI intelligence platform for public sector professionals. All content generated and verified by Astra.
analysis

Agents in Microsoft 365 Copilot Bring Business Apps Into the Flow of Work

Agents in Microsoft 365 Copilot Bring Business Apps Into the Flow of Work

Agents in Microsoft 365 Copilot Bring Business Apps Into the Flow of Work

One of the persistent friction points in AI-assisted work isn't generating outputs โ€” it's acting on them. A federal analyst summarizes a contract in Copilot, then opens a separate system to log the review. A program manager gets AI-generated meeting notes, then manually enters action items into a project tracker. The insight lives in one window. The work happens in another.

Microsoft announced this month that M365 Copilot agents can now surface business applications directly inside the Copilot chat experience, eliminating the context switch between AI assistance and execution. This is a meaningful change in how Copilot functions in practice.

What Changed

Microsoft 365 Copilot agents can now embed rich, interactive app experiences directly into Copilot conversations. Rather than generating text that a user then carries into another tool, agents connected to external applications can surface those applications' interfaces โ€” forms, records, visual editors, approval workflows โ€” inside the chat. Work can be completed without leaving the Copilot conversation.

The Microsoft 365 Agent Store is live and already includes integrations with Adobe Express, Figma, Optimizely, and Dynamics 365, among others. Microsoft describes the change as closing the gap between AI-powered insight and real, in-app action.

The control model is worth understanding: users can interact directly with the in-chat app interface, or they can prompt the agent and supervise its actions. Either way, the workflow stays within the Copilot conversation rather than fragmenting across applications.

Federal Workflow Relevance

For government agencies, the workflows where this matters most tend to share a common profile: they are document-heavy, involve multiple approval steps, require data entry into systems of record, and are currently handled through a combination of email, SharePoint, and manual process coordination.

Consider a few concrete examples:

Procurement and contract review. A contracting officer uses Copilot to review a statement of work, then needs to route the document for legal and technical review. If the routing system โ€” whether SharePoint, Dynamics, or a custom workflow tool โ€” has an agent in the store, that routing action happens inside the same conversation. No tab switching. No re-entering context.

HR case management. An HR specialist uses Copilot to draft a response to a leave request, then needs to update the employee's record in a case management system. An integrated agent handles the update from within the conversation.

Document approvals. Program office staff reviewing policy documents can generate summaries, leave comments, and push approval actions through connected systems without leaving the Copilot interface.

These are not theoretical scenarios. They describe the kind of repetitive, multi-step processes that make up a significant share of federal knowledge work.

The PRU Connection

One of the consistent challenges in M365 Copilot adoption programs is moving licensed users from occasional usage to habitual usage. The 30-interaction threshold that defines Premium Regular Usage isn't reached by users who remember to try Copilot once in a while. It's reached by users who encounter Copilot naturally inside their existing work patterns.

Embedding business apps into the Copilot experience is relevant here. When Copilot becomes the place where work actually happens โ€” not just where it gets analyzed โ€” the case for opening it habitually strengthens. A user who logs procurement actions through Copilot, routes documents through Copilot, and receives approvals through Copilot has structural reasons to be in Copilot throughout the workday. That kind of embedding is how habitual usage develops.

What to Verify Before Planning Deployments

A few practical considerations for federal technology leads:

GCC/GCCH availability of specific agents. The Agent Store and partner integrations are announced for commercial M365 Copilot. Availability in GCC environments depends on both Microsoft's rollout timeline and the individual partner's compliance posture. Agencies should verify which specific agents are available in their tenant before communicating them to end users.

FedRAMP authorization of partner apps. Integrating third-party apps into federal Copilot environments requires those apps to meet federal security requirements. Adobe Express, Figma, and similar commercial tools are not generally FedRAMP authorized for government use. The more relevant near-term integrations for most federal agencies will be Microsoft-native ones: Dynamics 365 (which has government cloud variants) and SharePoint-based workflows.

IT governance of agent deployment. The Microsoft 365 Agent Store introduces a new surface for IT governance. Agencies should understand whether their Copilot admin settings control which agents users can install, and ensure that agent deployment policies are in place before broad rollout.

The Direction Is Clear

Even accounting for the caveats, the direction of this development is clear and consequential. Microsoft is moving M365 Copilot from a tool that helps with tasks to a surface where tasks are completed. For federal agencies that have licensed Copilot and are working to demonstrate value, the app-in-conversation capability is one of the more compelling use-case expansions announced this year.

The near-term opportunity isn't necessarily the full Agent Store โ€” it's the Microsoft-native integrations that are already authorized for government use. Agencies that have Dynamics 365 in their environment, or have built SharePoint-based approval workflows, should be evaluating how those integrate with Copilot agents now.


Source: Microsoft 365 Blog, April 13, 2026