Adaptive response formats in Agentforce: buttons, carousels, and the v1-only catch

Your Agentforce agent knows the answer. It delivers it as a paragraph, and the customer reads three options buried in a sentence and types one back in free text the agent then has to re-parse.

Formatting, not reasoning, is the problem, and the fix has a name. Adaptive response formats let you shape what an action returns so the agent renders buttons, a scrollable carousel, or a rich link with a thumbnail instead of prose.

One decision shapes the whole rollout, so I’ll put it first. These formats render on the older Enhanced Chat v1 channel and, as of this writing, not on Enhanced Chat v2, the newer channel Salesforce built for voice and multimodal. Move a deployment to v2 for the voice story and your rich buttons stop rendering, and you’ll probably blame the action.

The two formats, and what each one becomes

There are two standard formats today, and the names describe the intent rather than the pixels.

A rich choice response is a list of items the customer picks from. Depending on the channel and your configuration, the same list surfaces as a horizontal carousel of cards, a set of buttons, a list selector, or, when the channel can’t do better, plain text.

Each carousel tile carries a title, a short description, an image, and a link, so “pick one of these five plans” becomes five cards a thumb can flick through instead of a numbered paragraph.

A rich link response is a single formatted link. It renders as a media card with a title, a description, and an image, or as a bare link when the channel is limited. Reach for it when you want to point at the one article that answers a question, or the product a customer asked about, where a preview card earns the tap a raw URL doesn’t.

The important property is that you don’t hard-code the pixels. You return structured data, and the agent chooses the presentation based on that data shape, the channel’s capabilities, and any instructions you’ve written. The Salesforce reference for these formats is explicit that the appearance depends on the channel and your customizations, which is freeing and also the source of most “why does it look wrong” tickets.

It’s on by default, and an action feeds it

On a new agent, adaptive response formats are enabled out of the box. You’ll find the switch under the Connections menu in Agent Builder if you ever need to turn it off, but the more useful knowledge is where the content comes from: an action.

A rich response is only as good as the data an action hands the agent. That data comes from a custom Apex action or a Flow action, the same two paths you already use for everything else the agent does.

Apex returns a collection; Flow returns output variables marked as available for output. You shape the output to carry the fields a card needs, and you map that output to the rich choice or rich link response in the builder.

The data a rich-choice item needs is small and predictable:

{
  "title": "Premier Support",
  "description": "24/7 phone and chat, 1-hour response",
  "imageUrl": "https://cdn.example.com/plans/premier.png",
  "link": "https://example.com/plans/premier"
}

In Apex, the action returns a list of those items. None of this is a special Agentforce type; it’s an ordinary invocable action returning a wrapper class, which is why it ports across the agents you already maintain:

public class GetPlanChoices {
    public class Choice {
        @InvocableVariable public String title;
        @InvocableVariable public String description;
        @InvocableVariable public String imageUrl;
        @InvocableVariable public String link;
    }

    @InvocableMethod(label='Get Plan Choices'
        description='Returns the plans a customer is eligible for')
    public static List<List<Choice>> getChoices(List<Id> accountIds) {
        List<Choice> choices = new List<Choice>();
        for (Plan__c p : [
            SELECT Name, Summary__c, Image_URL__c, Detail_URL__c
            FROM Plan__c
            WHERE Eligible_For__c = :accountIds[0]
            LIMIT 5
        ]) {
            Choice c = new Choice();
            c.title = p.Name;
            c.description = p.Summary__c;
            c.imageUrl = p.Image_URL__c;
            c.link = p.Detail_URL__c;
            choices.add(c);
        }
        return new List<List<Choice>>{ choices };
    }
}

Notice the LIMIT 5. It earns its place.

The five-item carousel cap is a real limit, not a guideline

On Enhanced Chat v1, the carousel renders a maximum of five items. Pass six or more and they don’t render correctly, which usually shows up as the whole response silently falling back to text.

The first time a carousel of eight products collapses into a paragraph, the instinct is to debug the format configuration. The real fix is to cap the result set in the query, the way the Apex above does, and to let the agent offer to narrow the list rather than dump it.

Rich formats share a general pattern: when something can’t render, it degrades to text rather than erroring. Good for resilience, bad for debugging, because a silent fallback looks identical to an action that returned nothing. Build the action to return at most what the channel can show, and treat any fallback to prose as a signal to check the count and the channel first.

The grey-box trap that makes everything look like plain text

There’s a specific misconfiguration that produces the most confusing symptom: the agent returns your content, but it shows up as plain text in a grey, code-style box, with no card, no button, no formatting. Teams rebuild the action three times before finding it.

The cause is usually an output variable with Show in conversation checked. That setting tells the agent to print the raw value directly into the transcript, which prevents the rich rendering from ever happening. Uncheck it, confirm the output is set to the rich format you intend, and the card comes back. It’s a two-click fix that costs an afternoon because the failure doesn’t look like a setting, it looks like the feature is broken.

Why v1 versus v2 is the decision that matters

Salesforce introduced Enhanced Chat v2 in the Winter ‘26 release, available from late October 2025, and it’s the strategic direction: a new architecture built for multimodal conversations, with voice, images, read and delivery receipts, and the ability to render responses as custom Lightning web components. v1 is still the default channel, you enable v2 deliberately, and you can switch back.

The tension sits right there. Rich choice and rich link are, today, a v1 capability, and the channel Salesforce steers you toward for voice and richer media is the one where those renderings don’t yet apply. So “upgrade to v2 for voice” and “use native buttons and carousels” currently pull in opposite directions, and the conflict only surfaces after a rollout has already picked one.

My read: choose the channel by the interaction that carries the most volume. A text deflection agent whose whole job is guiding a customer through choices lives or dies on buttons and carousels, so it belongs on v1 until the rich formats land on v2. A voice-first or multimodal experience needs v2, and there you build the equivalent affordances with custom components and accept that the out-of-the-box rich choice isn’t the tool. Do not move a working button-driven agent to v2 for a voice feature it doesn’t use and lose the formatting that was doing the work. Test the move in a sandbox, confirm every rich response still renders, and keep the ability to revert in your pocket.

Where these formats don’t reach

Two boundaries are worth stating plainly so you don’t design into a wall. Adaptive response formats are a messaging-channel feature. They apply to Messaging for In-App and Web and other enhanced messaging channels, and they are not available on Experience Cloud site components or on surfaces that aren’t messaging. If your agent lives somewhere other than an enhanced messaging channel, buttons and carousels from this feature aren’t the lever, and you build interactivity in that surface’s own component model.

The licensing is the ordinary Agentforce for Service footprint: a Service Cloud edition that supports it plus the Agentforce add-on, billed on the conversation-based model. Rich formatting doesn’t change what a conversation costs; it changes whether the customer finishes it.

What to do on Monday

Open one high-volume topic where the agent currently answers with a list in prose, the classic “which of these do you mean” turn. Give its action an output shaped like the item above, cap it at five, map it to a rich choice, and test it in your v1 deployment with Show in conversation unchecked. You’ll watch a paragraph turn into five cards, and the turn after it get shorter because the customer taps instead of types.

Then write down which channel each agent runs on and why, before you touch v2. The version you’re on is now a design input, not a detail, and the teams that get burned are the ones that discover that after the rich responses stop rendering in production.

Understanding the basics

What are adaptive response formats in Agentforce?

Adaptive response formats let an Agentforce agent render structured responses instead of plain text. There are two: a rich choice response, which renders as a carousel, buttons, a list selector, or text, and a rich link response, which renders as a media card or a link. The agent picks the presentation based on the data an action returns, the channel’s capabilities, and your configuration.

How do you produce a rich response from an action?

You return structured data from a custom Apex or Flow action and map that output to a rich choice or rich link response in Agent Builder. For a rich choice, the action returns a list of items, each with a title, description, image, and link. You don’t specify the exact visual; the agent renders the best format the channel supports.

Why does my Agentforce rich response show up as plain grey text?

The most common cause is an output variable with Show in conversation enabled, which prints the raw value into the transcript and blocks rich rendering. Uncheck it and confirm the output is set to the rich format. A second cause is exceeding the five-item carousel limit on Enhanced Chat v1, which makes the response fall back to text.

Do adaptive response formats work on Enhanced Chat v2?

As of this writing, no. Rich choice and rich link responses render on the Enhanced Chat v1 messaging channel, not on Enhanced Chat v2, the newer channel built for voice and multimodal experiences. If a deployment needs these rich formats, keep it on v1 and test carefully before moving to v2.

Deciding which channel an Agentforce agent should run on, and making it render buttons and carousels instead of a paragraph the customer has to parse? Talk to us. Getting the agent to finish the conversation instead of only answering it is exactly the work we do.