OpenClaw Message Presentation Explained

Message presentation is OpenClaw's shared contract for rich outbound chat UI. Instead of forcing agents to know Slack blocks, Discord components, Telegram buttons, Teams cards, or Feishu cards, OpenClaw lets a producer describe intent once and lets each channel render the best native shape it supports.

30-second answer

Use presentation when a message needs portable structure: title, tone, text sections, context text, dividers, buttons, select menus, URL buttons, and delivery hints. Do not add provider-native fields to the shared message tool. Channel plugins own native rendering; the shared contract owns semantic intent and fallback text.

Contract shape

The docs define MessagePresentation with optional title and tone plus ordered blocks. Supported block types are text, context, divider, buttons, and select. Buttons can have labels, action values, URLs, and advisory styles. Select options have labels and values. Labels also power fallback text.

Why this matters

Without a shared presentation layer, every approval card, status card, or action menu becomes channel-specific code. With presentation, the same agent request can become Slack blocks, Telegram inline buttons, Discord components, or plain text fallback depending on the channel's capabilities.

Degradation rules

Fallback behavior is part of the contract. A title becomes the first line, text blocks become paragraphs, context blocks become compact context lines, dividers become visual separators, button labels and URLs remain visible, and select options are listed as text when the channel does not support selects. URL-only buttons become native link buttons or fallback URL lines.

That graceful degradation is important for business automation. A status update should not disappear just because one channel lacks native select menus. The user should still receive enough text to understand the decision or next action.

Delivery pin

Presentation can include delivery metadata for pinning. pin: true pins the first successfully delivered message. Optional pin failures degrade and leave the sent message intact. Required pin failures fail delivery. Chunked messages pin the first delivered chunk, not the tail.

Plugin author checklist

Channel plugins should declare presentation support, add presentation capabilities to outbound adapters, implement rendering in runtime code, preserve platform limits, and add fallback tests for unsupported buttons, selects, URL buttons, titles, text, context, dividers, and pin behavior. Native UI libraries should stay out of hot setup and catalog paths.

The OpenClaw Playbook uses message presentation as a communication discipline: the agent should send compact, actionable UI when a channel supports it and still fall back to clear text when it does not.

Rollout plan

Treat OpenClaw Message Presentation Explained as a workflow you roll out in stages, not a switch you flip once. Start with the smallest harmless proof: a status check, dry run, local-only call, private session, or read-only inspection. Confirm the documented behavior matches your installed OpenClaw version, then write the exact commands and expected output into the workspace so the next agent does not rely on memory or vibes.

For a production runbook, document decision owner, source document, acceptance check, upgrade risk, and where future agents should look before changing the behavior. Also write down what the agent may do alone, what requires approval, and what must stop immediately. That boundary is the difference between useful autonomy and a workflow that surprises the operator at the worst possible time.

Keep one rollback note beside the guide. It can be as simple as the command to disable a plugin, the channel to pause, the config key to revert, or the owner who must approve the next run. Include the proof that tells you rollback worked, and keep it visible near the production checklist for future maintainers. Agents are most useful when recovery is obvious.

After the first live run, review the transcript or logs while the details are fresh. Look for missing prerequisites, stale assumptions, broad prompts, confusing errors, and any external side effect that should have been gated. Tighten the guide, then repeat with one wider scope. The OpenClaw Playbook is built around this operating rhythm: cautious first proof, written runbook, verified automation, then gradual autonomy once the evidence is boring.