Lars Winstand

Posted on Jul 30 • Originally published at standardcompute.com

My AI agent update broke and now it talks in emojis — turns out that’s better UX

#ai #slack #discord #automation

I thought this was going to be one of those tiny agent bugs you laugh at and ignore.

Then I saw a thread on r/openclaw where someone said their OpenClaw agent had started using emojis for status updates — and they liked it.

Not tolerated it. Liked it.

They even described the sequence:

👀 I see the message
🧠 I'm thinking
⏳ This is taking time
🛠️ I'm working on it

That’s not random model weirdness. That’s product feedback.

If you build bots or agents for Slack, Discord, n8n, Make, Zapier, OpenClaw, or your own workflow stack, there’s a real lesson here:

Glanceable state beats progress spam.

And once you look at the API constraints, this stops being a UX opinion and starts looking like the correct engineering choice.

The interesting part wasn’t the emojis

Most people see emoji-heavy agent output and assume one of two things:

prompt drift
model personality leaking through

Sometimes that’s true. GPT-5.4, Claude Opus 4.6, Grok 4.20, Qwen, and Llama models all have their own ideas about tone.

But in the OpenClaw thread, someone pointed out that this behavior had apparently been there all along, and users could disable it.

That changes the story.

This wasn’t an AI model going off-script. It looks much more like an intentional status design.

And if users keep it on, they’re telling you something useful:

In chat interfaces, short visual signals often work better than verbose progress narration.

That matters because a lot of agent builders still design status UX like they’re writing logs for humans.

That’s a mistake.

Why verbose progress updates feel bad in chat

A dashboard can handle detail.

A chat thread cannot.

In Slack, Discord, and WhatsApp, users usually want three answers:

Did you get my request?
Are you still working?
Is this normal, or is something stuck?

That’s it.

A lot of bots answer those questions with mini diary entries:

Analyzing your request
Searching sources
Synthesizing findings
Preparing final response
Formatting output

That reads like internal trace logs escaped into the UI.

A compact status sequence is usually better:

👀 Received
🧠 Thinking
⏳ Taking longer than usual
🛠️ Retrying
✅ Done
⚠️ Needs input

Same information. Less noise.

Slack quietly rewards quiet bots

This is where the UX lesson becomes implementation advice.

Slack’s API nudges you toward editing one message instead of posting a stream of updates.

Typical options:

chat.postMessage
chat.update
reactions.add

Those are not equivalent.

chat.update and reactions.add are much better fits for status changes than posting new messages every few seconds.

The practical pattern is:

Post one acknowledgment
Update that same message as state changes
Add reactions for lightweight confirmation
Post a new message only when you have a real result

A better Slack pattern

Post once:

curl -X POST https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "C123456",
    "text": "👀 Received your request"
  }'

Update in place:

curl -X POST https://slack.com/api/chat.update \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "C123456",
    "ts": "1723472384.123456",
    "text": "🧠 Running enrichment"
  }'

Add a reaction when done:

curl -X POST https://slack.com/api/reactions.add \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "C123456",
    "timestamp": "1723472384.123456",
    "name": "white_check_mark"
  }'

That is better than six separate “working on it” messages.

It’s cleaner for users and cleaner for rate limits.

Don’t break accessibility while making it look nice

This is the part a lot of Slack bot builders miss.

If you use Block Kit, the top-level text field still matters for accessibility. Screen readers rely on it.

So this is risky:

{
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "⏳"
      }
    }
  ]
}

This is better:

{
  "text": "Processing your request. Step 2 of 4: running enrichment.",
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "⏳ *Running enrichment*"
      }
    }
  ]
}

Emoji-only status can look slick and still be bad UX for real users.

Good status design has to survive assistive tech, not just screenshots.

Discord already solved part of this

Discord has a native liveness signal: typing.

Use it.

If your bot receives a request and needs a few seconds, trigger the typing indicator immediately:

POST /channels/{channel.id}/typing

That buys you time and reassures the user that the bot is alive.

Then send one short acknowledgment and edit that message as work progresses.

That pattern fits Discord much better than posting a new progress message every step.

A good Discord flow

trigger typing immediately
send one short acknowledgment
edit the same message as state changes
send a new message only for the final result if it’s materially different

Pseudo-code with discord.js might look like this:

await channel.sendTyping();

const status = await channel.send("👀 Received — checking context");

await status.edit("🧠 Thinking — searching docs");
await status.edit("⏳ Taking longer than usual — retrying one source");
await status.edit("✅ Done — posted result below");

await channel.send(finalAnswer);

That feels much better in a busy server.

If your bot drops a new message every 10 seconds, it doesn’t feel smart. It feels rude.

The real thing users want is confidence

When users say they like emoji status updates, they usually don’t mean “please decorate my bot.”

They mean:

I want confidence without clutter.

That’s the whole job of status UX in chat.

Not entertainment.
Not personality.
Not synthetic enthusiasm.

Just confidence.

That matters even more for long-running automations:

web research agents
CRM updates
lead enrichment
document generation
multi-step n8n flows
Make scenarios
Zapier automations
custom workers behind Slack or Discord bots

If those systems are billed per token, teams often end up with a second problem: they become weirdly cautious about status verbosity, retries, and long-running chains because every extra call feels like cost leakage.

That’s one reason predictable infrastructure matters.

Why this gets more important when agents run all day

Once you start running agents 24/7, status design stops being cosmetic.

It becomes operational.

If your automation stack is constantly:

updating Slack threads
retrying failed steps
routing between models
summarizing intermediate work
posting final outputs

then the difference between “one living message” and “a flood of progress chatter” becomes huge.

And if you’re paying per token for every stage, you get the worst combination:

noisy UX
cost anxiety
pressure to trim useful behavior

That’s exactly the kind of problem Standard Compute is built to remove.

Standard Compute is a drop-in OpenAI-compatible API for teams running agents and automations. Instead of per-token billing, you get unlimited AI compute for a flat monthly price. That makes it much easier to build practical long-running workflows in n8n, Make, Zapier, OpenClaw, or custom agent stacks without constantly asking whether every extra update, retry, or routing step is worth the spend.

If you’re building bots that need to stay alive all day, predictable cost matters just as much as model quality.

My rule of thumb

If you’re designing agent status in chat, use compact state with both symbol and label:

👀 Received
🧠 Thinking
⏳ Taking longer than usual
🛠️ Fixing an issue
✅ Complete
❌ Failed — needs retry

That keeps the speed of emoji cues without the ambiguity of emoji-only UI.

And if you need detailed logs, put them where logs belong:

Datadog
Sentry
Honeycomb
your internal admin console

Don’t dump them into the user conversation.

One living message is usually enough

That’s the biggest takeaway here.

For most chat-based agents, the best status UX is one living message that evolves over time.

| Channel | Native affordance | Best pattern |
|----------|----------|
| Slack | chat.update, reactions.add | Post once, update in place |
| Discord | Typing indicator, edited messages | Signal liveness, then edit one message |
| WhatsApp | Limited UI surface | Keep updates sparse and short |

The OpenClaw thread looked silly at first.

It was actually a tiny product spec.

Users weren’t celebrating emojis.
They were celebrating reassurance without clutter.

If your AI agent update “broke” and suddenly got shorter, quieter, and easier to read at a glance, don’t assume it regressed.

You might be looking at the first honest status UX your bot has ever had.

DEV Community