Discord Buttons Turn an Agent Into a Workflow

The agent had done the hard part.

It had found the right post, prepared the exact text, and was ready to publish. Then it asked the least useful possible question: “Should I post it?”

That looks harmless, but it creates needless ambiguity. Does “yes” mean publish the version above? Does it mean publish everywhere or only here? What if someone replies after the preview is stale? What if the agent has moved on to a different draft by the time the response arrives?

This is not really a chat problem. It is a workflow problem.

Native Discord buttons give the workflow a small control surface: a human sees the exact choice and taps the action they actually mean. The agent receives a bounded response, verifies it, and either acts or stops. No custom dashboard, webhook server, or bespoke Discord bot is required for the normal OpenClaw path.

Buttons are not just prettier confirmation

The useful change is not visual polish. It is replacing interpretation with a concrete state transition.

Compare these two interactions.

Chat-only approval

1. Agent: “I drafted the announcement. Should I post it?”
2. Human: “Yep.”
3. Agent has to infer which announcement, where it goes, and whether the original preview is still current.

Bounded approval

1. Agent shows the exact announcement and destinations.
2. Agent presents Post to all three and Cancel.
3. Human chooses one specific action.
4. Agent verifies the request is still valid, then acts once.

That difference matters most when the action leaves the machine: posting, emailing, buying, deleting, changing permissions, or triggering a deployment. A button does not make any of those actions safe by itself. It makes the requested decision explicit enough to validate.

Where buttons fit

Buttons are a good fit for a small, fixed set of actions:

• approve or cancel an exact external action after seeing its preview
• retry a failed job or leave it failed for later investigation
• continue or stop a multi-step workflow
• choose one of a few fully described implementation paths
• acknowledge that a reminder or task is complete

They are the wrong interface when the person needs to supply information instead of choosing an action. Do not put What should the release notes say? behind buttons. Do not make someone choose from thirty issues with a row of tiny controls. Use normal text, a modal, or a select menu when the response needs explanation, a value, or a large/open-ended choice.

The rule I use is simple: if the button label cannot name the actual effect, the decision is not ready for a button yet.

The supported OpenClaw shape

OpenClaw’s message tool has a portable presentation object. On Discord, it renders as Components v2 buttons and registers a callback that routes the click back to the agent. That means the normal approval path does not require a custom Discord interaction endpoint or a gateway restart.

First, show the payload the person is being asked to approve. For example:

Ready to publish this post:

"Discord Buttons Turn an Agent Into a Workflow"

Destinations: blog and Threads

Then send the decision prompt. Here is the complete message-tool shape:

{
  "action": "send",
  "channel": "discord",
  "target": "channel:123456789012345678",
  "message": "The preview above is ready. Choose the exact action.",
  "presentation": {
    "title": "Publishing approval",
    "tone": "warning",
    "blocks": [
      {
        "type": "text",
        "text": "This will publish the reviewed text to the blog and Threads."
      },
      {
        "type": "buttons",
        "buttons": [
          {
            "label": "Publish to both",
            "action": {
              "type": "callback",
              "value": "publish-reviewed-draft"
            },
            "style": "success"
          },
          {
            "label": "Cancel",
            "action": {
              "type": "callback",
              "value": "cancel-publish"
            },
            "style": "danger"
          }
        ]
      }
    ]
  }
}

Use your real channel ID in place of the placeholder. The value should be a compact action name, not a blob of free-form text and not a substitute for the authoritative workflow state. The visible label tells the human what will happen; the agent’s state tells the system what, precisely, is eligible to happen.

What happens after a click

Discord renders the button. The OpenClaw Discord renderer registers the interaction and routes a click back into the agent as an inbound message. Treat that callback as a response to one precise visible action, not as a blanket authorization to do whatever the agent currently has in mind.

Before executing a consequential action, the agent should check all of the following:

1. The sender is authorized. The portable schema currently does not expose Discord’s per-button allowedUsers field, so channel-level inbound authorization still matters. Re-check the requester before acting.
2. The requested action matches the preview. If the draft, target, price, recipient, or scope changed after the button was sent, invalidate the old approval and show a fresh preview.
3. The workflow is still pending. Do not reuse an approval after a successful run, failure, cancellation, or a later workflow step.
4. The button has not expired. Component callbacks are single-use by default and expire after the configured TTL, which is 30 minutes by default in this setup.
5. The action is idempotent or guarded. A duplicate click, retry, or delayed callback must not publish twice, purchase twice, or apply a change twice.

That is the part that turns a UI feature into a reliable control. A button click is evidence of a specific approval, not proof that every related action is safe forever.

A small state model saves a lot of pain

The easiest mistake is treating the button callback value as the whole workflow. It is not.

Keep an explicit record for the pending decision, whether that lives in an application database, a task record, or durable workflow state. At minimum, store:

• a decision or workflow ID
• the authorized requester and conversation
• a hash or version of the reviewed payload
• the exact permitted action and target
• creation and expiry times
• status: pending, approved, cancelled, expired, or executed

When a callback arrives, look up that record and transition it once. A useful mental model is:

previewed -> pending approval -> approved -> executed
                       |              |
                       v              v
                   cancelled        expired

The callback value can identify the branch to take, but the stored decision record should establish the actual payload and whether the transition is still allowed. This avoids a surprisingly common failure mode: an old, vague approval being applied to a newer action.

Build the fallback into the workflow

Rich components are not guaranteed to be available in every channel or client situation. A good approval flow has a plain-text fallback that preserves the same clarity:

The reviewed draft will be published to the blog and Threads.
Reply exactly: PUBLISH REVIEWED DRAFT
Reply CANCEL to stop.

That is less pleasant than a button, but it remains bounded. The agent should repeat the action and scope, require an unambiguous response, and still validate the same pending-decision record. Never silently downgrade to “yes/no” shorthand for an action that matters.

Test the control before trusting it

Before using buttons for a live external action, test the whole loop with a harmless prompt.

• Send a two-button test to the intended channel.
• Click each branch in separate test messages.
• Confirm each click reaches the intended agent and session.
• Confirm a clicked control cannot be used a second time.
• Confirm an expired control is rejected rather than applied late.
• Change the underlying payload and verify the old approval is refused.
• Confirm the plain-text fallback produces the same safe state transition.

This is worth doing because the easy failure is not “Discord did not render a blue button.” The easy failure is a button that renders perfectly but is routed to the wrong workflow, survives too long, or is treated as a broader approval than the user gave.

For agents

Buttons should make an agent more careful, not more eager.

• Present the exact payload before the approval controls.
• Use labels that name the action: Publish to both, not Yes.
• Always include Cancel for action-bearing prompts.
• Keep controls single-use unless repetition is explicitly safe and intentional.
• Re-check authorization, current payload, expiry, and workflow state after a click.
• Acknowledge success, cancellation, expiry, or failure plainly in the channel.
• Fall back to an equally specific text confirmation if components cannot be sent.

The larger lesson is that good agent UX is not about making chat look more like an app. It is about putting the right amount of structure around the moments where a human decision changes what the system is allowed to do.

Discord buttons are a tiny interface feature. Used well, they are also a clean boundary between an agent suggesting an action and a person authorizing one.