Microsoft is preparing a significant user-experience expansion for declarative agents in Microsoft 365 Copilot, with a roadmap item that promises flexible layouts and rich UX components for makers building these specialized AI assistants. The feature, listed as Microsoft 365 Roadmap ID 497844, is marked in development for worldwide standard multi-tenant environments, with general availability currently targeted for May 2027 across desktop and web. Microsoft frames the goal in unusually direct product language: more expressive agents should improve engagement and potentially make them more shareable inside organizations. Microsoft 365 Roadmap
For Windows and Microsoft 365 users, this is more consequential than a cosmetic Copilot refresh. It signals that Microsoft wants business agents to move beyond the familiar pattern of prompt, paragraph, and follow-up question. Instead, makers should be able to assemble agents that present structured information, capture user input, provide decision points, and guide people through a task with an interface that feels more like a focused application than an AI chat thread.
That direction aligns with Microsoft’s broader declarative-agent strategy: make it possible to create tailored Copilot experiences through instructions, organizational knowledge, and actions, while Microsoft continues to supply the models, orchestration, hosting, and much of the governance foundation. Microsoft Learn’s declarative agents overview
The roadmap entry uses the term “DA’s,” a shorthand for declarative agents. These are configurable Microsoft 365 Copilot agents designed for defined business scenarios. Rather than writing a completely custom AI application and controlling every part of its model and orchestration stack, makers declare what the agent is for, what it should know, how it should behave, and which actions it can take. Microsoft’s agent architecture documentation
Microsoft’s planned feature focuses on two connected ideas:
In practical terms, the roadmap points toward agents that can do more than say, “Here are five sales opportunities” or “Your request is awaiting approval.” A future agent could instead display a ranked list, summarize the evidence behind each item, surface a compact visual, offer appropriate next actions, and collect the information required to proceed—all within a coherent Microsoft 365 Copilot experience.
A paragraph is not the best way to compare options, approve a request, inspect a set of figures, select a date, triage an incident, or review a record that has several related fields. Users often have to extract information from prose manually, then formulate another prompt to get the agent to perform the next step.
Flexible layouts potentially change that dynamic. They create room for an agent to organize an answer into sections that mirror the task itself: a summary at the top, priority data in the center, evidence below it, and actions positioned where people expect them. Microsoft’s design guidance for agent cards specifically emphasizes visual hierarchy, progressive disclosure, essential actions, and responsive behavior across different widths. Microsoft’s Adaptive Cards design guidance
Consider a procurement agent. In a plain chat format, it might produce a written recommendation, then wait for the user to request a comparison, ask for supporting documents, and finally type an approval instruction. With richer components, that same agent could organize the task into a more functional surface:
Microsoft already describes Adaptive Cards as a way to place structured and interactive content alongside or in place of text, including inputs, dropdowns, choice sets, buttons, images, charts, and multi-part layouts. Microsoft’s Adaptive Cards documentation The roadmap suggests that richer, more flexible visual patterns could become more central to the maker experience for Microsoft 365 Copilot agents.
That creates an important requirement: an agent interface cannot assume a large desktop canvas. Dense data panels that work in a wide browser window may become frustrating in a narrow Teams side panel or a constrained Copilot experience. Microsoft’s current design guidance identifies responsive breakpoints—Wide, Standard, Narrow, and Very Narrow—and advises makers to tailor layouts to the context in which the card is rendered. Microsoft’s Adaptive Cards design guidance
The likely payoff is consistency. A well-designed agent should retain its identity and task flow across desktop and web without requiring users to relearn its interface each time they encounter it in a different Microsoft 365 context.
That adoption potential depends on whether rich components solve actual workplace problems rather than simply adding visual decoration.
Structured input controls can collapse several conversational steps into one interaction. Microsoft’s guidance highlights dropdowns, inputs, and choice sets as mechanisms for gathering information efficiently, while keeping the flow focused. Microsoft’s agent card guidance
This could be particularly helpful in scenarios such as:
Microsoft explicitly positions Adaptive Cards as capable of presenting charts, images, structured content, and rich approval workflows. Microsoft’s agent design guidance Microsoft also provides training material focused on using Adaptive Card templates to render API data visually within declarative-agent actions, reinforcing that visually structured responses are already an important development direction. Microsoft Learn’s Adaptive Cards module for declarative agents
For a Windows-focused IT organization, imagine an internal endpoint-management agent. Rather than returning a prose summary of devices requiring attention, it could offer:
That observation should not be dismissed as superficial. In enterprise environments, users make rapid judgments about whether a tool is safe and official. Clear labels, familiar terminology, restrained branding, and consistent behavior can help distinguish an approved company agent from an ad hoc AI experiment.
However, branding must not be allowed to create false confidence. An attractive card can make uncertain or incomplete AI-generated content appear more authoritative than it is. The more polished the interface becomes, the more important it is to identify source data, provide links to underlying records where appropriate, and make the boundary between recommendation and automated action unmistakable.
A declarative agent is configured with several core elements:
That can reduce time to value, especially for departmental use cases grounded in SharePoint, OneDrive, Teams content, Copilot connectors, and approved API plugins. It also means the agent inherits Microsoft 365 structures around authentication, governance, app distribution, audit, retention, and data loss prevention rather than forcing every maker to rebuild those foundations. Microsoft’s declarative-agent architecture
Rich UX components make this proposition more attractive because they could close a longstanding gap between “easy to configure” and “pleasant to use.” A low-code agent is more likely to receive real adoption if it does not feel like a text-only prototype.
Microsoft further notes that grounding and external tool calls operate sequentially in this model. That means makers cannot rely on looped operation plans or chains of operations that repeatedly use new grounding data, which limits complex multi-step automation. Microsoft’s declarative-agent architecture
The documentation identifies practical technical constraints, including limits for grounding records, plugin-response items, tokens, and timeouts. It also warns that declarative agents are a poor fit for full-document or large-data contexts, lengthy processes, advanced decision trees, and scenarios that demand reliable recency from dynamic web sources. Microsoft’s declarative-agent architecture
That distinction is vital. A flexible interface can make a simple workflow dramatically better, but it cannot turn a platform-constrained declarative agent into a fully bespoke case-management system, autonomous operations platform, or custom multi-agent orchestration engine.
Microsoft’s design guidance recommends leading with the most important information, using visual hierarchy, supporting progressive disclosure, and limiting actions to those directly connected to task completion. Microsoft’s agent design guidance Those principles should become internal standards for makers, not optional design suggestions.
The best rich agent interface will usually be quieter than an inexperienced maker expects. One primary action, one or two secondary actions, concise labels, and a clear separation between information and controls will usually outperform a dense dashboard.
That warning is especially relevant to Microsoft 365 Copilot agents expected to work across desktop and web. An interface that looks correct in one environment might degrade in another because of width constraints, host-level rendering differences, or component support boundaries.
Testing should therefore include:
If an agent can initiate a workflow, update a record, or invoke an external API, the UI must communicate the consequence clearly. Buttons should use unambiguous verbs. Approval surfaces should show what is being approved. Destructive actions should require confirmation when appropriate. AI-generated summaries should not hide the original record or source details when a user needs to make a consequential decision.
Microsoft also calls out cross-prompt injection attacks as a security issue in conversational AI, where malicious instructions in prior content or context can influence later behavior. Microsoft’s declarative-agent architecture Rich components do not create that risk by themselves, but they can magnify its impact if an untrusted result is presented with an authoritative-looking action path.
Good early candidates include:
That system might define:
A rich declarative-agent interface may make the declarative route more compelling for many departmental solutions. But if the underlying task requires complex orchestration, long-running autonomous work, iterative decision trees, specialized models, or deeply customized external experiences, a custom-engine approach may remain the technically appropriate choice.
The opportunity is substantial because declarative agents already benefit from Microsoft 365 integration, enterprise knowledge connections, established security controls, and multiple low-code and pro-code authoring paths. Microsoft’s declarative-agent overview Adding more expressive design capabilities could make those agents materially easier to adopt in day-to-day work.
The caution is equally clear: a richer surface does not remove platform limits, guarantee correct AI output, or substitute for thoughtful workflow design. The agents that succeed will be those that use flexibility with restraint—showing only what matters, making actions understandable, grounding outputs in trusted information, and remaining usable across the desktop and web environments where Microsoft 365 work happens.
If Microsoft delivers Roadmap ID 497844 on its current May 2027 target, declarative agents may begin to feel less like customized chatbots and more like a practical new layer of lightweight, governed business applications inside Copilot.
For Windows and Microsoft 365 users, this is more consequential than a cosmetic Copilot refresh. It signals that Microsoft wants business agents to move beyond the familiar pattern of prompt, paragraph, and follow-up question. Instead, makers should be able to assemble agents that present structured information, capture user input, provide decision points, and guide people through a task with an interface that feels more like a focused application than an AI chat thread.
That direction aligns with Microsoft’s broader declarative-agent strategy: make it possible to create tailored Copilot experiences through instructions, organizational knowledge, and actions, while Microsoft continues to supply the models, orchestration, hosting, and much of the governance foundation. Microsoft Learn’s declarative agents overview
What Microsoft Is Planning for Copilot Declarative Agents
The roadmap entry uses the term “DA’s,” a shorthand for declarative agents. These are configurable Microsoft 365 Copilot agents designed for defined business scenarios. Rather than writing a completely custom AI application and controlling every part of its model and orchestration stack, makers declare what the agent is for, what it should know, how it should behave, and which actions it can take. Microsoft’s agent architecture documentationMicrosoft’s planned feature focuses on two connected ideas:
- Flexible layouts — more control over how an agent’s response is arranged, prioritized, and adapted to the available space.
- Rich UX components — visual and interactive elements that can turn a static answer into an actionable workflow.
In practical terms, the roadmap points toward agents that can do more than say, “Here are five sales opportunities” or “Your request is awaiting approval.” A future agent could instead display a ranked list, summarize the evidence behind each item, surface a compact visual, offer appropriate next actions, and collect the information required to proceed—all within a coherent Microsoft 365 Copilot experience.
Why Flexible Layouts Matter More Than They Sound
AI interface design has been dominated by text because text is the most universal medium for large language models. It is easy to generate, cheap to render, and flexible enough to answer almost any question. But it is also a poor default for many work tasks.A paragraph is not the best way to compare options, approve a request, inspect a set of figures, select a date, triage an incident, or review a record that has several related fields. Users often have to extract information from prose manually, then formulate another prompt to get the agent to perform the next step.
Flexible layouts potentially change that dynamic. They create room for an agent to organize an answer into sections that mirror the task itself: a summary at the top, priority data in the center, evidence below it, and actions positioned where people expect them. Microsoft’s design guidance for agent cards specifically emphasizes visual hierarchy, progressive disclosure, essential actions, and responsive behavior across different widths. Microsoft’s Adaptive Cards design guidance
From a conversation to a task surface
The most important design shift is not that responses may look more polished. It is that the interface can carry part of the workflow.Consider a procurement agent. In a plain chat format, it might produce a written recommendation, then wait for the user to request a comparison, ask for supporting documents, and finally type an approval instruction. With richer components, that same agent could organize the task into a more functional surface:
- A concise recommendation with an explanation of the selection criteria.
- A comparison section for price, lead time, contract status, and risk.
- Attached source documents or record links.
- A choice control for approving, declining, or escalating.
- A comment field for exceptions or justification.
Microsoft already describes Adaptive Cards as a way to place structured and interactive content alongside or in place of text, including inputs, dropdowns, choice sets, buttons, images, charts, and multi-part layouts. Microsoft’s Adaptive Cards documentation The roadmap suggests that richer, more flexible visual patterns could become more central to the maker experience for Microsoft 365 Copilot agents.
Responsive design is part of the promise
“Flexible” should not be interpreted only as creative freedom for designers. In Microsoft 365, a single agent can be encountered through different applications and window sizes, including Copilot Chat and Microsoft 365 surfaces such as Teams, Outlook, Word, and Excel. Microsoft says declarative agents can run inside Microsoft 365 Copilot and Microsoft 365 apps, while Adaptive Cards are intended to adapt to their host environment. Microsoft’s agents overview Microsoft’s Adaptive Cards overviewThat creates an important requirement: an agent interface cannot assume a large desktop canvas. Dense data panels that work in a wide browser window may become frustrating in a narrow Teams side panel or a constrained Copilot experience. Microsoft’s current design guidance identifies responsive breakpoints—Wide, Standard, Narrow, and Very Narrow—and advises makers to tailor layouts to the context in which the card is rendered. Microsoft’s Adaptive Cards design guidance
The likely payoff is consistency. A well-designed agent should retain its identity and task flow across desktop and web without requiring users to relearn its interface each time they encounter it in a different Microsoft 365 context.
Rich UX Components Could Make Agents More Useful
Microsoft’s roadmap language links rich UX to user engagement and virality. “Virality” is an unusual word in enterprise software, but it points to an understandable ambition: agents that provide a clear, polished, immediately useful experience are more likely to be shared by colleagues and adopted across a tenant.That adoption potential depends on whether rich components solve actual workplace problems rather than simply adding visual decoration.
Better input, fewer conversational turns
One of the clearest benefits is reducing unnecessary back-and-forth. If an agent needs a department, date range, approval choice, priority level, or other structured information, asking for each item sequentially can make a simple task feel slow.Structured input controls can collapse several conversational steps into one interaction. Microsoft’s guidance highlights dropdowns, inputs, and choice sets as mechanisms for gathering information efficiently, while keeping the flow focused. Microsoft’s agent card guidance
This could be particularly helpful in scenarios such as:
- IT service management: category selection, urgency, affected device, and error details.
- HR self-service: leave type, dates, supporting documentation, and policy acknowledgment.
- Finance workflows: cost center, spending category, amount, and approver selection.
- Sales operations: deal stage, forecast confidence, next action, and account updates.
- Project administration: status, owner, due date, blockers, and escalation path.
More intelligible data presentation
The second advantage is interpretability. A table, status pill, visual trend, or compact chart can communicate information much faster than a paragraph describing the same data.Microsoft explicitly positions Adaptive Cards as capable of presenting charts, images, structured content, and rich approval workflows. Microsoft’s agent design guidance Microsoft also provides training material focused on using Adaptive Card templates to render API data visually within declarative-agent actions, reinforcing that visually structured responses are already an important development direction. Microsoft Learn’s Adaptive Cards module for declarative agents
For a Windows-focused IT organization, imagine an internal endpoint-management agent. Rather than returning a prose summary of devices requiring attention, it could offer:
- A high-level health summary.
- A breakdown of devices by compliance status.
- A list of the most urgent remediation actions.
- Links to relevant device records or management portals.
- A controlled action to create a ticket, notify an owner, or begin an approved remediation flow.
A stronger place for branding and trust
Rich UX components also give organizations a way to make agents feel purposeful and trustworthy. Microsoft notes that typography, iconography, layout rhythm, and action labels influence whether an agent feels polished or like an afterthought. Microsoft’s agent design guidanceThat observation should not be dismissed as superficial. In enterprise environments, users make rapid judgments about whether a tool is safe and official. Clear labels, familiar terminology, restrained branding, and consistent behavior can help distinguish an approved company agent from an ad hoc AI experiment.
However, branding must not be allowed to create false confidence. An attractive card can make uncertain or incomplete AI-generated content appear more authoritative than it is. The more polished the interface becomes, the more important it is to identify source data, provide links to underlying records where appropriate, and make the boundary between recommendation and automated action unmistakable.
How This Fits Microsoft’s Declarative-Agent Model
Flexible layouts and rich components are most meaningful when considered alongside the architectural trade-offs of declarative agents. Microsoft’s model is designed to lower the effort needed to build an agent that works inside the Microsoft 365 ecosystem.A declarative agent is configured with several core elements:
- Instructions that define its purpose, scope, and behavior.
- Knowledge sources that ground its answers in Microsoft 365 or connected data.
- Capabilities and actions that allow it to retrieve data or interact with external services.
- App metadata that controls how it is identified and distributed. Microsoft’s declarative-agent overview
Low-code power, with platform constraints
The appeal is straightforward. Teams can build focused agents without taking responsibility for hosting their own foundation model, orchestrator, or full conversational runtime. Microsoft states that declarative agents use Copilot’s orchestrator and foundation model, and that no additional hosting is required for the declarative approach. Microsoft’s agents overviewThat can reduce time to value, especially for departmental use cases grounded in SharePoint, OneDrive, Teams content, Copilot connectors, and approved API plugins. It also means the agent inherits Microsoft 365 structures around authentication, governance, app distribution, audit, retention, and data loss prevention rather than forcing every maker to rebuild those foundations. Microsoft’s declarative-agent architecture
Rich UX components make this proposition more attractive because they could close a longstanding gap between “easy to configure” and “pleasant to use.” A low-code agent is more likely to receive real adoption if it does not feel like a text-only prototype.
The agent is not a replacement for custom applications
At the same time, better layout does not erase declarative-agent limitations. Microsoft’s architecture documentation is explicit that developers do not control the underlying orchestrator or language model, and that declarative agents are best suited to focused scenarios rather than highly complex, iterative workflows. Microsoft’s declarative-agent architectureMicrosoft further notes that grounding and external tool calls operate sequentially in this model. That means makers cannot rely on looped operation plans or chains of operations that repeatedly use new grounding data, which limits complex multi-step automation. Microsoft’s declarative-agent architecture
The documentation identifies practical technical constraints, including limits for grounding records, plugin-response items, tokens, and timeouts. It also warns that declarative agents are a poor fit for full-document or large-data contexts, lengthy processes, advanced decision trees, and scenarios that demand reliable recency from dynamic web sources. Microsoft’s declarative-agent architecture
That distinction is vital. A flexible interface can make a simple workflow dramatically better, but it cannot turn a platform-constrained declarative agent into a fully bespoke case-management system, autonomous operations platform, or custom multi-agent orchestration engine.
Risks Makers and Administrators Should Address
The prospect of expressive agents creates new opportunities, but it also raises predictable operational and governance concerns. The risks are not arguments against rich UX. They are reasons to adopt it carefully.Visual complexity can undermine usability
A response card stuffed with buttons, badges, nested containers, decorative imagery, and competing calls to action can be worse than plain text. Users may not know where to look, which control is safe, or whether an action is reversible.Microsoft’s design guidance recommends leading with the most important information, using visual hierarchy, supporting progressive disclosure, and limiting actions to those directly connected to task completion. Microsoft’s agent design guidance Those principles should become internal standards for makers, not optional design suggestions.
The best rich agent interface will usually be quieter than an inexperienced maker expects. One primary action, one or two secondary actions, concise labels, and a clear separation between information and controls will usually outperform a dense dashboard.
Host compatibility remains a practical testing challenge
Microsoft’s documentation cautions that Adaptive Card schema support varies by host, and that unsupported elements may render incorrectly or fail silently. It specifically advises makers to test against the schema version supported by the intended host. Microsoft’s agent design guidanceThat warning is especially relevant to Microsoft 365 Copilot agents expected to work across desktop and web. An interface that looks correct in one environment might degrade in another because of width constraints, host-level rendering differences, or component support boundaries.
Testing should therefore include:
- Desktop and browser-based use cases rather than a single ideal screen size.
- Narrow-width layouts and smaller panes.
- Light and dark modes, where supported.
- Keyboard navigation and assistive technologies.
- Failure and empty states, not only the ideal successful response.
- Permission-denied and unavailable-data cases that users will encounter in real deployments.
AI safety must extend to actions and presentation
Microsoft requires declarative agents to pass Responsible AI validation checks, and says declarative agents inherit Microsoft 365 security, compliance, and Responsible AI requirements. Microsoft’s declarative-agent overview That foundation is useful, but organizations remain responsible for their own agent instructions, connected data, and action design.If an agent can initiate a workflow, update a record, or invoke an external API, the UI must communicate the consequence clearly. Buttons should use unambiguous verbs. Approval surfaces should show what is being approved. Destructive actions should require confirmation when appropriate. AI-generated summaries should not hide the original record or source details when a user needs to make a consequential decision.
Microsoft also calls out cross-prompt injection attacks as a security issue in conversational AI, where malicious instructions in prior content or context can influence later behavior. Microsoft’s declarative-agent architecture Rich components do not create that risk by themselves, but they can magnify its impact if an untrusted result is presented with an authoritative-looking action path.
What Organizations Should Do Before May 2027
The stated May 2027 availability target gives Microsoft 365 customers time to prepare thoughtfully. The most productive response is not to wait for the feature and then redesign every agent. It is to identify the work where a richer interface would genuinely improve outcomes.Start with high-friction conversational workflows
The strongest candidates are not necessarily the most ambitious AI projects. They are tasks that are already viable in Microsoft 365 Copilot but feel inefficient because users must repeatedly type structured information or parse repetitive text.Good early candidates include:
- Request intake and triage.
- Approval workflows.
- Policy lookup with guided follow-up actions.
- Sales and account summaries.
- IT support diagnostics and ticket creation.
- Employee onboarding steps.
- Project-health reporting.
- Knowledge retrieval that benefits from citations, source links, and clear navigation.
Establish a component and content design system
Organizations that expect many agents should avoid allowing every department to invent its own visual language. A small reusable design system can improve consistency and reduce risk.That system might define:
- Standard headers and status patterns.
- Approved button labels and confirmation behavior.
- Table and chart conventions.
- Error, loading, and no-data states.
- Approved language for AI uncertainty.
- Data-source attribution patterns.
- Accessibility and responsive-layout requirements.
- Rules for action placement and escalation paths.
Match the agent type to the business problem
Finally, teams should be disciplined about choosing declarative agents only when their constraints fit the job. Microsoft’s own comparison is clear: declarative agents are designed for focused scenarios within Microsoft 365, while custom-engine agents are intended for more complex workflows, custom model choices, proactive interactions, and broader channel requirements. Microsoft’s agents overviewA rich declarative-agent interface may make the declarative route more compelling for many departmental solutions. But if the underlying task requires complex orchestration, long-running autonomous work, iterative decision trees, specialized models, or deeply customized external experiences, a custom-engine approach may remain the technically appropriate choice.
A More Mature Phase for Microsoft 365 Copilot Agents
Microsoft’s planned flexible layouts and rich UX components represent an important maturation point for Microsoft 365 Copilot declarative agents. The company is not merely promising prettier cards. It is setting the stage for makers to build agent experiences that can organize information, collect structured input, guide approvals, visualize results, and surface the right action at the right moment.The opportunity is substantial because declarative agents already benefit from Microsoft 365 integration, enterprise knowledge connections, established security controls, and multiple low-code and pro-code authoring paths. Microsoft’s declarative-agent overview Adding more expressive design capabilities could make those agents materially easier to adopt in day-to-day work.
The caution is equally clear: a richer surface does not remove platform limits, guarantee correct AI output, or substitute for thoughtful workflow design. The agents that succeed will be those that use flexibility with restraint—showing only what matters, making actions understandable, grounding outputs in trusted information, and remaining usable across the desktop and web environments where Microsoft 365 work happens.
If Microsoft delivers Roadmap ID 497844 on its current May 2027 target, declarative agents may begin to feel less like customized chatbots and more like a practical new layer of lightweight, governed business applications inside Copilot.
References
- Primary source: Microsoft 365 Roadmap
Published: 2026-07-28T22:43:45.1902826Z
Microsoft 365 Roadmap | Microsoft 365
The Microsoft 365 Roadmap lists updates that are currently planned for applicable subscribers. Check here for more information on the status of new features and updates.www.microsoft.com
- Related coverage: learn.microsoft.com
Declarative Agents for Microsoft 365 Copilot | Microsoft Learn
Learn how you can use declarative agents to meet business needs. Declarative agents customize Microsoft 365 Copilot via instructions, actions, and knowledge.learn.microsoft.com