Operational incident · Slack · July 23–24, 2026 HST

Why Carl Got Check Marks but No Answers

Slack accepted Carl’s three direct ForgeBot mentions and added acknowledgments. The agent then intentionally suppressed every answer because the qualifying mention had been removed before the model saw the message.

Unresolved until gateway restart + live Carl test

Executive Finding

This was not a Slack send failure and not an Azure-access failure. It was a stale runtime configuration combined with a mention-stripping mismatch. The visible check mark meant “request accepted,” but it looked like “work completed.”
  • Carl’s direct requests reached the active Slack session.
  • The stored session shows three exact model outputs: NO_REPLY.
  • Hermes correctly suppressed those control responses, so Slack displayed no text.
  • The current gateway remains healthy, but health checks do not prove the updated mention policy was loaded.

What Actually Happened

1. Slack admittedCarl began each request with the exact ForgeBot mention.
→
2. Bot reactedThe ingress lifecycle added :white_check_mark:.
→
3. Mention disappearedThe model received [Carl] ... with no ForgeBot mention.
→
4. Reply suppressedThe ownership backstop emitted NO_REPLY; Hermes intentionally delivered nothing.

Timeline

  1. Jul 23 · 7:47 PM
    Carl: “Can you give us a price breakdown of how much we are spending on Azure per month?” direct mention
    Check mark added. Session result: NO_REPLY.
  2. Jul 23 · 8:49 PM
    Carl: “Poke. Can you give us a price breakdown for Azure?” direct mention
    Check mark added. Session result: NO_REPLY.
  3. Jul 23 · 8:50 PM
    Carl: “You don’t seem to be posting anything… Test test?” direct mention
    Check mark added. Session result: NO_REPLY.
  4. Jul 24 · 12:10 AM
    Carl escalated to Adam: “I’m not sure what’s going on with ForgeBot.”
    No ForgeBot response was expected because Carl addressed Adam, not ForgeBot.
  5. Jul 24 · 3:13 AM
    Adam tested: “You back up?”
    ForgeBot answered, but that single owner test does not prove team-user reliability under the stale runtime.

Root Cause

  • The gateway process started at Jul 22, 6:50 AM PDT.
  • The Slack mention-policy configuration was edited afterward at Jul 22, 7:16 AM PDT.
  • The still-running gateway never reloaded that configuration.
  • Current source already contains the Jul 16 fix that preserves first-token mention evidence—but only when the updated policy is active.

Observed session input: “[Carl] poke. Can you give us a price break down for azure?”
Observed assistant result: “NO_REPLY”
Expected input after restart: “[Carl] <@ForgeBot> poke. Can you give us…”

Evidence