3.3.2. Response Formatting and Adaptive Cards
💡 First Principle: A response is an interface, not a paragraph. Formatting (structure, emphasis, media) controls comprehension; adaptive cards go further and make the response operable — a JSON-defined micro-UI whose inputs and action buttons feed values straight back into the conversation's variables.
Message-level tools first: markdown formatting (headings, bold, lists, links, images) structures the reading experience; message variations let a node carry alternative phrasings so repeated encounters don't feel robotic; speech-enabled channels can carry distinct spoken text. These are cheap wins the exam mentions mostly in "improve the response experience" phrasing.
Adaptive cards are the deeper skill. A card is a JSON payload — text blocks, images, input fields (text, date, choice sets), and actions — rendered natively by the channel. In a topic you add one via the message/question surface, paste or author the JSON, and bind conversation data into it. The submit action closes the loop: what the user enters and clicks arrives back as structured values the topic stores in variables and branches on. That makes cards the right answer whenever conversation needs form-shaped input — multi-field, validated, selected-from-options — that would be miserable as six sequential question nodes.
The planning echo from 3.1.2 applies: card support and rendering vary by channel, so a card-heavy design constrains which channels can carry the agent faithfully.
⚠️ Common Misconception: Adaptive cards are just formatted messages. The distinguishing feature is bidirectional data: inputs and actions return structured values to the topic. A card without inputs is formatting; a card with inputs is UI.
Reflection Question: An IT intake conversation needs device type (choice), issue description (text), and urgency (choice) — then must branch on urgency. Why does one adaptive card beat three question nodes, and where do the submitted values land?
