Problem or Use Case

When the gateway is already busy with an active Hermes run, users need accurate acknowledgement of what will happen to their next message.

Today, if a platform/session is configured to queue rather than interrupt, the acknowledgement can still feel like an interrupt-style response. That creates confusion about whether:

• the current task is still running
• the new message was actually queued
• the agent stopped what it was doing

This matters most on messaging platforms where users only see the acknowledgement text and do not have local process visibility.

Proposed Solution

Make busy-session acknowledgements reflect the real behavior:

• In queue mode:

  • do not interrupt the active agent
  • store the new message for the next turn
  • send an acknowledgement that clearly says the current task is still running and the new message was queued

• In interrupt mode:

  • keep the existing interrupt-and-ack behavior

Redacted implementation sketch:

if busy_mode == "queue":
    merge_pending_message_event(...)
    reply("Current task is still running. Your new message was queued for the next turn.")
else:
    request_interrupt(...)
    reply("Interrupted current task and queued your new message.")

Alternatives Considered

• Keep one generic acknowledgement for both modes.
  • Simpler, but misleading when queue semantics differ from interrupt semantics.
• Always interrupt when busy.
  • Lower ambiguity, but worse UX for users who intentionally prefer queueing.
• Only document the difference in docs.
  • Not enough; the live acknowledgement text is what shapes user expectations.

Feature Type

Gateway / messaging improvement

Scope

Small to Medium

Contribution

A redacted local prototype already exists and was validated with targeted gateway tests. This appears to be a contained UX improvement with low implementation risk and clear user-facing value.