Building Rich Agent Experiences with Adaptive Cards in Microsoft Copilot Studio

Introduction

Microsoft Copilot Studio agents are conversational applications, but conversation does not need to be limited to plain text.

An agent can answer a question with a sentence such as:

Your vacation request has been created successfully.

However, enterprise applications often need to communicate considerably more information. A user might need to review structured data, select an option, confirm an operation, provide several pieces of information, inspect the result of an Action, or interact with information retrieved from systems such as SharePoint Online.

This is where rich responses and particularly Adaptive Cards become important.

Adaptive Cards allow an agent to transform part of a conversation into structured user interface elements while keeping the interaction inside the conversational experience.

Instead of thinking about a Copilot Studio agent only as:

User → Question → Text Answer

we can begin thinking about it as:

User → Conversation → Structured UI → User Interaction → Agent Logic → Result

This represents an important step in the transition from a simple conversational agent to an enterprise conversational application.

1. Rich responses in Copilot Studio

The simplest response generated by an agent is plain text.

For example:

User

What is the status of request 1045?

Agent

Request 1045 is currently awaiting manager approval.

This is perfectly acceptable when the information is simple.

But imagine that the response contains several attributes:

• Request ID
• Employee
• Department
• Request type
• Status
• Submitted date
• Approver

Returning everything as a paragraph quickly becomes difficult to read.

A structured response could instead conceptually present:

Request #1045

Employee: John Smith
Department: Engineering
Status: Pending Approval
Submitted: September 10, 2026

[View Request]

The underlying information has not changed.

What changed is the presentation layer of the conversation.

This distinction is important:

An Adaptive Card therefore should not be confused with Knowledge or an Action.

It is primarily part of the interaction and presentation layer.

2. What is an Adaptive Card?

Adaptive Cards are platform-agnostic user interface fragments represented using JSON.

Instead of creating a separate HTML interface for Teams, another interface for a web application, and another interface for another Microsoft surface, the application describes the desired interface declaratively.

A simplified card might look like this:

{
  "type": "AdaptiveCard",
  "version": "1.5",
  "body": [
    {
      "type": "TextBlock",
      "text": "Request created successfully",
      "weight": "Bolder"
    }
  ]
}

The JSON describes what should be presented.

The host application decides how it should be rendered.

Conceptually:

Copilot Studio
      |
      v
Adaptive Card JSON
      |
      v
Host Application
      |
      +---- Microsoft Teams
      |
      +---- Copilot Chat
      |
      +---- Web Chat
      |
      +---- Other supported channels

This is why they are called Adaptive Cards.

The card adapts its presentation to the host environment instead of requiring the developer to create an entirely independent UI implementation for every supported surface.

3. The Adaptive Card as a declarative UI

Developers coming from SPFx, React, TypeScript, C#, or traditional web development might initially think of an Adaptive Card as a small web component.

That mental model is not completely accurate.

Adaptive Cards are better understood as a declarative UI schema.

In SPFx we might create a component using:

React
HTML
CSS
Fluent UI
TypeScript

With Adaptive Cards, we primarily describe the interface through JSON:

AdaptiveCard
   |
   +-- body
   |    |
   |    +-- TextBlock
   |    +-- Image
   |    +-- Container
   |    +-- ColumnSet
   |    +-- Input.Text
   |    +-- Input.ChoiceSet
   |
   +-- actions
        |
        +-- Action.Submit
        +-- other supported actions

The host is responsible for rendering the actual UI.

This provides less UI freedom than a custom SPFx application, but dramatically reduces the amount of interface code required.

4. Anatomy of an Adaptive Card

A useful conceptual model is:

AdaptiveCard
│
├── Metadata
│   ├── type
│   ├── version
│   └── $schema
│
├── Body
│   ├── TextBlock
│   ├── Image
│   ├── Container
│   ├── ColumnSet
│   └── Input controls
│
└── Actions
    ├── Submit
    └── Other supported actions

A common card starts with something similar to:

{
  "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
  "type": "AdaptiveCard",
  "version": "1.5",
  "body": [],
  "actions": []
}

$schema

Identifies the Adaptive Card schema and helps tools understand and validate the document.

type

Defines the root object.

For a card:

"type": "AdaptiveCard"

version

Indicates which version of the Adaptive Cards schema the card expects.

This property becomes especially important when the agent is published to different channels.

body

Contains the visual elements.

Examples include:

TextBlock
Image
Container
ColumnSet
FactSet
Input.Text
Input.Date
Input.Toggle
Input.ChoiceSet

actions

Contains operations the user can trigger.

For example:

{
  "type": "Action.Submit",
  "title": "Confirm"
}

5. Informational versus interactive cards

One of the most important distinctions when designing Adaptive Cards in Copilot Studio is whether the card is intended to display information or collect information.

Informational card

An informational card primarily presents data.

Example:

Employee Request
ID: 1045
Type: Hardware Request
Status: Pending Approval
Created: September 10
Manager: Robert Smith

The user does not necessarily need to provide anything back.

Typical scenarios include:

• Search results
• SharePoint document information
• Request status
• Employee information
• Knowledge summaries
• Action results
• Approval status
• Technical system information

Conceptually:

Agent
   |
   +--> obtains information
   |
   +--> constructs response
   |
   +--> Adaptive Card
   |
   +--> User

6. Interactive Adaptive Cards

Interactive cards introduce another capability.

They can collect structured information from the user.

For example:

New IT Request
Title:
[________________________]
Category:
[Hardware          ▼]
Priority:
( ) Low
( ) Normal
( ) High
Description:
[________________________]
[________________________]
        [Submit Request]

Now the card is not merely presentation.

It becomes part of the conversation input mechanism.

The architecture changes:

User
 |
 v
Adaptive Card
 |
 +-- Title
 +-- Category
 +-- Priority
 +-- Description
 |
 v
Submit
 |
 v
Copilot Studio variables
 |
 v
Conversation logic

This is extremely important for enterprise agents.

Conversational language is excellent for flexible interaction, while forms are excellent for structured information.

Adaptive Cards allow both approaches to coexist.

7. Conversation versus form

Suppose we need four pieces of information.

A purely conversational design could work like this:

Agent: What is the request title?
User: New laptop
Agent: Which department?
User: IT
Agent: What priority?
User: High
Agent: Please describe the problem.
User: My current laptop is failing.

This works, but requires several conversational turns.

An Adaptive Card could gather everything simultaneously:

Request
Title
[New laptop]
Department
[IT ▼]
Priority
[High ▼]
Description
[My current laptop is failing]
[Submit]

Neither approach is universally better.

Conversation is useful when:

• information is ambiguous;
• natural language is valuable;
• the agent needs clarification;
• the interaction should feel exploratory.

Structured cards are useful when:

• required fields are known;
• several fields must be collected;
• validation is important;
• options should be constrained;
• the user needs to review data before submitting.

Good agent architecture often combines both.

8. Adaptive Cards and Topics

Adaptive Cards become particularly useful when combined with Topics.

A Topic defines a controlled conversational path.

For example:

Topic: CreateHardwareRequest
Trigger
   |
   v
Gather initial context
   |
   v
Ask with Adaptive Card
   |
   +-- Title
   +-- Device
   +-- Priority
   +-- Description
   |
   v
Variables
   |
   v
Validate
   |
   v
Action
   |
   v
Create SharePoint item
   |
   v
Confirmation Adaptive Card

This architecture separates responsibilities cleanly.

The Adaptive Card collects information.

The Topic coordinates the conversation.

Variables hold the values.

The Action performs the business operation.

SharePoint stores the resulting business record.

9. Adaptive Cards and variables

Interactive cards become much more powerful when their inputs are mapped into agent variables.

Consider:

{
  "type": "Input.Text",
  "id": "requestTitle",
  "label": "Request title"
}

The important concept here is the identifier:

requestTitle

When the user submits the card, the value associated with that input can participate in the subsequent conversation logic.

Conceptually:

Adaptive Card
requestTitle
      |
      v
Topic Variable
      |
      v
Validation
      |
      v
Action Input

This is the bridge between UI and orchestration.

10. Dynamic Adaptive Cards with Power Fx

Cards do not need to contain only static information.

Copilot Studio can use Power Fx to make cards dynamic by referencing agent or Topic variables.

Imagine that an Action retrieves the following values:

RequestId = 1045
Status = "Pending Approval"
Employee = "John Smith"

Instead of hardcoding those values into JSON, the card can use variables.

The conceptual flow becomes:

SharePoint / Action / Conversation
              |
              v
           Variables
              |
              v
           Power Fx
              |
              v
        Adaptive Card
              |
              v
             User

This is one of the points where Adaptive Cards move beyond visual formatting and become a reusable presentation layer for dynamic enterprise data.

11. A SharePoint example

Consider an agent called:

SharePoint Request Assistant

The employee says:

I need a new laptop.

The agent understands the intent and starts the appropriate Topic.

The Topic displays:

Hardware Request
Employee
John Smith
Device
[Laptop ▼]
Priority
[Normal ▼]
Business justification
[____________________________]
[Submit Request]

After submission:

Adaptive Card
      |
      v
Topic Variables
      |
      v
Action
      |
      v
Power Automate
      |
      v
SharePoint List

Power Automate could create:

The Flow returns:

RequestId = 1045
Status = New

The agent then presents another card:

Request Created
Request ID: 1045
Status: New
Your request was successfully registered.

Notice the separation of responsibilities.

Adaptive Card: user interface.

Topic: conversation orchestration.

Variables: state and data.

Power Automate: business process.

SharePoint: data persistence.

This separation is an important enterprise architecture principle.

12. Adaptive Cards are not Actions

This deserves explicit emphasis.

A button displayed inside an Adaptive Card does not automatically mean that the card itself implements the business operation.

Consider:

[Create Request]

Visually this appears to perform an Action.

Architecturally, however, several layers might exist behind it:

Button
   |
   v
Adaptive Card submission
   |
   v
Topic logic
   |
   v
Action / Tool
   |
   v
Power Automate
   |
   v
SharePoint

The card captures the user’s intent.

The actual business operation belongs to the Action/Tool layer.

This distinction becomes critical when analyzing authentication, authorization and security.

13. Adaptive Cards are not Knowledge

The same architectural distinction applies to Knowledge.

Suppose the agent searches a SharePoint knowledge source and retrieves information about a corporate policy.

The architecture might be:

SharePoint Documents
        |
        v
Knowledge / Retrieval
        |
        v
Agent
        |
        v
Generated answer
        |
        v
Adaptive Card
        |
        v
User

Knowledge determines what information is available to the agent.

The Adaptive Card determines how some information is presented or collected.

Therefore:

Knowledge ≠ Adaptive Card
Action ≠ Adaptive Card
Adaptive Card = Interaction / Presentation

14. Adaptive Cards and generative AI

Another architectural question is whether an Adaptive Card is generated by the LLM.

Not necessarily.

In many enterprise scenarios, it is preferable to define the card structure explicitly and only insert dynamic values.

For example:

LLM / Retrieval
       |
       v
Structured information
       |
       v
Known Adaptive Card template
       |
       v
Rendered response

This provides greater predictability than asking generative AI to decide the complete UI every time.

This introduces an important design principle:

Use generative AI where flexibility is valuable and deterministic structures where predictability is valuable.

For a policy explanation, generative language can be useful.

For collecting fields required by a business process, a predefined Adaptive Card is usually more appropriate.

15. Channel compatibility matters

Adaptive Cards are rendered by a host, and different hosts do not necessarily support every schema feature identically.

This means:

Adaptive Card
     |
     +-- Teams
     |
     +-- Copilot Chat
     |
     +-- Web Chat

does not guarantee completely identical capabilities everywhere.

Therefore, an enterprise agent should be tested on its actual target channel, not only inside the Copilot Studio test experience.

Schema version also matters.

A card using an element introduced in a newer schema might work in one host and fail or render differently in another.

This leads to an important rule:

Design for the capabilities of the target host, not simply for the newest Adaptive Card schema available.

16. Security considerations

Adaptive Cards themselves should not be considered a security boundary.

Suppose a card contains:

Employee: John Smith
Salary: $120,000
Manager: Jane Doe

The important security question is not whether the card can display this information.

The question is:

Was the user authorized to obtain this information in the first place?

Security belongs to the underlying data and execution architecture:

User Identity
      |
      v
Agent
      |
      v
Knowledge / Action
      |
      v
Authorization
      |
      v
Data
      |
      v
Adaptive Card

The card should only present information that the preceding layers were authorized to retrieve.

Likewise, hiding a button or field does not replace authorization on the underlying Action.

17. Adaptive Cards versus SPFx

Because SharePoint developers are familiar with SPFx, this comparison helps position the technology.

Therefore, Adaptive Cards should not be considered a replacement for SPFx.

They solve a different problem.

Use Adaptive Cards when the interface belongs naturally inside an agent conversation.

Use SPFx when you need a richer, highly customized SharePoint application experience.

18. A useful enterprise architecture

As our Copilot Studio knowledge grows, the following architecture will become increasingly important:

                   USER
                     |
                     v
             Microsoft Agent
                     |
          +----------+----------+
          |                     |
          v                     v
      KNOWLEDGE              TOPICS
          |                     |
          v                     v
     SharePoint            Variables
    Documents                  |
                               v
                        Adaptive Cards
                               |
                               v
                         User Input
                               |
                               v
                         Action / Tool
                               |
                               v
                        Power Automate
                               |
                               v
                          SharePoint
                               |
                               v
                         Action Result
                               |
                               v
                        Adaptive Card
                               |
                               v
                             USER

This architecture illustrates something fundamental about enterprise agents.

An agent is not simply an LLM answering questions.

It can become an orchestration layer connecting natural language, structured UI, enterprise knowledge and deterministic business processes.

19. When should we use an Adaptive Card?

A useful architectural guideline is:

The most important lesson is therefore not simply how to create an Adaptive Card, but when an Adaptive Card belongs in the architecture.

20. Design principles for enterprise agents

Several principles emerge from this architecture.

Keep cards focused

A card should normally solve one interaction problem rather than becoming an entire application embedded inside the conversation.

Prefer deterministic forms for deterministic processes

If a process requires:

Title
Category
Priority
Description

collect those fields explicitly instead of relying entirely on natural-language extraction.

Use generative AI where ambiguity exists

Natural language remains valuable for understanding intent, answering questions, summarizing content and interpreting unstructured information.

Validate inputs

Never assume that information submitted by a card is automatically valid simply because it came through a structured interface.

Authorize Actions independently

UI controls are not security controls.

Test the actual publishing channel

A card working inside a test environment does not guarantee identical behavior everywhere.

21. The larger Copilot Studio picture

At this stage of our learning journey, we can expand our mental model of a Microsoft Copilot Studio agent.

Previously, we could think of it as:

Agent
 |
 +-- Instructions
 |
 +-- Knowledge
 |
 +-- Generative Answers

Now we can expand that model:

AGENT
│
├── Instructions
│
├── Knowledge
│     └── Grounding / Retrieval
│
├── Conversation
│     ├── Topics
│     ├── Messages
│     ├── Questions
│     ├── Variables
│     └── Adaptive Cards
│
├── Actions / Tools
│     ├── Power Automate
│     ├── Connectors
│     └── APIs
│
└── Channels
      ├── Microsoft Teams
      ├── Microsoft 365 Copilot
      ├── Web
      └── Other supported surfaces

Adaptive Cards therefore occupy a very specific position.

They sit primarily between the conversation logic and the user experience.

22. Final architecture lesson

The key lesson is not JSON.

Learning the Adaptive Card schema is useful, but the more important architectural lesson is understanding how structured UI fits into an AI-driven application.

A well-designed enterprise agent combines different technologies according to their strengths:

Natural Language
      ↓
Understand intent
Knowledge
      ↓
Retrieve information
Generative AI
      ↓
Reason and communicate
Topics
      ↓
Control deterministic conversation paths
Adaptive Cards
      ↓
Present and collect structured information
Actions / Tools
      ↓
Execute operations
Power Automate / APIs
      ↓
Implement business processes
SharePoint / Dataverse
      ↓
Store enterprise data

This separation helps produce agents that are easier to understand, test, secure and maintain.

Adaptive Cards are therefore much more than a visual enhancement.

They represent the bridge between conversation and structured application interaction.

That bridge becomes particularly important as an agent evolves from answering questions to participating in real enterprise processes.

Official Microsoft references

Microsoft Learn — Deliver rich agent responses using Adaptive Cards in Microsoft Copilot Studio

Microsoft Learn — Adaptive Cards in Copilot Studio

Microsoft Learn — Ask with Adaptive Cards

Microsoft Learn — Adaptive Cards documentation

Microsoft Learn — Power Fx in Copilot Studio

Microsoft Learn — Design agent conversations and responses using Topics