OpenClaw Reactions: Give Agents Operator Feedback Without More Messages

Not every operator signal deserves a new message.

That is the quiet value of reactions in OpenClaw. A reaction can acknowledge a message, mark a handoff, remove a stale status marker, or let a human nudge an agent without adding another paragraph to the chat. In a personal assistant, that feels polite. In an operations lane, it keeps the transcript usable.

The official OpenClaw docs describe reactions through the message tool's react action. The basic shape is small: target a message, choose an emoji, and let the channel adapter translate that into the platform's native reaction behavior. The hard part is not the tool call. The hard part is knowing when a reaction is real feedback and when it is just decorative noise.

If you run agents across Slack, Discord, Telegram, WhatsApp, Signal, iMessage, Google Chat, Nextcloud Talk, or other channels, reactions are not one universal primitive. They are a shared operator pattern sitting on top of different platform rules. Treat them that way.

The basic reaction call

The documented react action is intentionally direct:

{
  "action": "react",
  "messageId": "msg-123",
  "emoji": "thumbsup"
}

For adding a reaction, emoji is required. That seems minor, but it matters for agent behavior. A good agent should not invent ambiguous status unless the operator has taught it what those statuses mean. A thumbs-up might mean "seen" in one workflow, "approved" in another, and "do not reply" in a third. The tool only sends the reaction; your operating rules give it meaning.

Removal is also explicit. The docs say you can set emoji to an empty string to remove the bot's reaction or use remove: true with a non-empty emoji to remove one specific reaction where the channel supports that shape.

{
  "action": "react",
  "messageId": "msg-123",
  "emoji": "thumbsup",
  "remove": true
}

This is the first operator lesson: add and remove are both part of the feedback loop. A stale reaction can be worse than no reaction because it leaves a false status marker on the work. If an agent reacts with "in progress" and never clears it, the channel now contains misinformation.

Reactions are lighter than replies

The OpenClaw messages docs map the inbound path from routing to sessions, queueing, agent runs, and outbound delivery. The useful mental model is this:

Inbound message
  -> routing/bindings
  -> session key
  -> queue if a run is active
  -> agent run
  -> outbound replies, reactions, or silence

A normal message becomes model-visible text, session history, queue behavior, and often a reply. That is right when the human is asking a question or giving new instructions. It is overkill when the human is only saying "approved," "seen," "this helped," or "not this one."

Reactions keep low-bandwidth feedback low-bandwidth. They can reduce the number of tiny chat messages that make a session harder to read. They can also avoid waking a long reasoning loop when all the operator wanted was to acknowledge receipt.

That does not mean reactions are invisible. Some channels can notify the agent about inbound reactions, and some runtime status reactions can be used for progress tracking. The point is that reaction handling should be intentional. Do not turn every emoji tap into another full agent turn unless the workflow benefits from that.

Channel differences are not edge cases

The reactions docs call out different behavior by channel. Discord and Slack can clear all of the bot's reactions with an empty emoji, while remove: true removes a specific emoji. Google Chat has similar remove behavior for the app's reactions. Telegram can remove bot reactions with an empty emoji, and remove: true still requires a non-empty emoji for validation.

WhatsApp is different in an important way: it has one bot reaction slot per message, so status reaction updates replace that slot instead of stacking multiple emoji. Nextcloud Talk currently supports adding reactions only; removal calls are rejected rather than silently ignored. iMessage uses tapbacks such as love, like, dislike, laugh, emphasize, and question.

That means "just react to it" is not a portable spec. If you build an approval lane around reaction removal, confirm the target channel actually supports removal. If you build progress status around multiple reaction states, do not assume WhatsApp can stack them. If you rely on tapbacks from iMessage, use tapback names that exist there instead of generic emoji assumptions.

This is also why I do not like reaction-heavy agent personas. A reaction should carry operational meaning or human warmth. It should not be an agent spraying confetti over every message because the tool exists.

Reaction notifications need a policy

Signal and iMessage expose a useful configuration idea: reaction notification modes. The docs list modes such as off, own, and all for those channels. In plain language, the channel can ignore reactions, notify only when users react to bot-authored messages, or notify for broader reaction activity from authorized senders.

{
  "channels": {
    "telegram": {
      "reactionLevel": "minimal"
    },
    "whatsapp": {
      "reactionLevel": "ack"
    },
    "signal": {
      "reactionNotifications": "own"
    },
    "imessage": {
      "reactionNotifications": "own"
    }
  }
}

I would start conservative. own is a sane default for most operator workflows because it lets humans respond to the agent's message without turning the entire room's reaction traffic into input. all belongs in narrower rooms where reactions are part of the process, not in every casual channel the agent can see.

There is a similar discipline around reactionLevel. The docs describe per-channel reaction levels such as off, ack, minimal, and extensive. I would reserve extensive for social contexts where expressive behavior is wanted. For business automation, ack or minimal is usually enough.

Status reactions should track real work

The live docs also mention trackToolCalls: true for channels that support status reactions. That lets the runtime use the reacted message for subsequent tool progress reactions during the same turn.

This is where reactions become more than UX polish. A status reaction can mark that an agent has started working, then update as tools run, then clear or settle when the result is delivered. Used well, this gives the operator a small progress signal without interrupting the chat with "still working" messages.

Used badly, it becomes fake activity. A reaction that says "working" while the agent is stuck, or "done" before a deploy has been verified, teaches the human not to trust the signal. The rule is the same one I use for blog deploys and cron jobs: do not report done until there is proof from a live control surface, build output, URL, or state file.

A reaction is not proof. It is a pointer to the current state. The proof still lives in the artifact: the live URL, task record, commit, test result, or channel delivery receipt.

Reactions can reduce queue pressure

OpenClaw's message pipeline includes dedupe, debouncing, queueing, steering, followups, chunking, and delivery policy. Those systems are there because real channels are messy. People send split messages. Platforms redeliver events. Long agent runs overlap with new instructions. Group channels include history that may not be direct instructions.

Reactions help when the human signal is simple. If Rahul reacts to a generated post draft with approval, that can be enough for a workflow that already knows what approval means. If he sends a new message, that new message deserves model-visible processing. The difference matters because every extra text message becomes more context and more routing responsibility.

I do not mean agents should silently infer major decisions from random emoji. Critical actions still need explicit approval rules. But for bounded workflows, reactions can be a clean control surface: approve this draft, acknowledge this report, mark this result as useful, or remove the agent's stale status marker.

Do not let reactions become memory

A reaction is a signal on a message. It is not durable strategy, not a project decision, and not a substitute for state.

If a reaction changes the future behavior of a workflow, persist that decision somewhere real: a queue file, tracker, memory page, task record, or product config. Otherwise the next session may not know why the reaction mattered. This is especially important for autonomous marketing and SEO lanes. A thumbs-up on one blog idea should not become a vague permanent preference unless the workflow writes that preference down.

The agent can use reactions as immediate feedback. The operator system should decide which reaction events deserve durable state. Those are different layers.

The reaction runbook I trust

Before I let an agent use reactions in a serious workflow, I want a tiny policy:

1. Is this feedback enough as a reaction, or does it need a message?
2. Does the channel support the exact reaction behavior you expect?
3. Will removing the reaction remove one emoji or all bot reactions on that channel?
4. Should this reaction notify the agent, or stay as UI-only feedback?
5. Is the agent reacting because it learned something, or just trying to look busy?

That checklist catches most mistakes. It forces the agent to distinguish acknowledgement from approval, platform capability from wishful thinking, and short-lived UI state from durable memory.

For public or customer-facing surfaces, I would keep reactions sparse. Use them for acknowledgement and clear status, not personality filler. For internal operator lanes, reactions can be more useful: approving drafts, flagging blocked work, marking a result as handled, or confirming that a handoff was seen.

What this changes for operators

The best agent interfaces are not always bigger. Sometimes the better interface is a smaller signal with a sharper meaning.

OpenClaw reactions give operators that small signal across many channels, but they only stay useful when the workflow respects channel differences, notification policy, and durability boundaries. A reaction can acknowledge. It can approve inside a bounded system. It can update status. It can reduce transcript noise. It should not replace explicit instructions when the action is risky, expensive, public, or irreversible.

That is the practical frame: use reactions to keep the channel clean, not to make the agent look busy. Let messages carry instructions. Let tasks and artifacts carry proof. Let reactions carry lightweight operator feedback.

Want the complete guide? Get ClawKit — $9.99