hermes - 💡(How to fix) Fix Add generic action buttons / inline keyboard support for messaging platforms [1 comments, 2 participants]

Feature request

It would be useful to have a generic way for Hermes to send interactive action buttons with messages on messaging platforms, especially Telegram inline keyboards, without hardcoding this behavior for one specific feature.

Motivation

Hermes already supports Telegram inline buttons in some built-in flows, for example model selection and command approval. However, there does not seem to be a generic API/tool/interface for agent-generated or scheduled messages to attach action buttons and handle the user's choice in a platform-agnostic way.

This would be useful for many workflows:

• "Update Hermes now?" → Yes / No
• "Run deployment?" → Deploy / Cancel
• "Approve backup?" → Start / Skip
• "Choose environment" → Production / Staging / Dev
• "Confirm destructive action" → Confirm / Cancel
• Scheduled task reports with follow-up actions
• Any agent workflow where the next step depends on a small set of user choices

Desired behavior

Hermes should expose a generic messaging action API that allows a message to include buttons.

Conceptually:

{
  "target": "telegram",
  "message": "Update available. What should I do?",
  "actions": [
    {
      "label": "Yes, update",
      "value": "update_yes"
    },
    {
      "label": "No, postpone",
      "value": "update_no"
    }
  ]
}

For Telegram, this could be rendered as an inline keyboard.

When the user clicks a button, Hermes should receive the action as a normal gateway event and route it back into the relevant session/workflow, for example as an equivalent user message or structured action event.

Platform considerations

Telegram:

• Use InlineKeyboardMarkup.
• Handle callback_query.
• Call answerCallbackQuery so the Telegram client does not keep showing a loading spinner.
• Optionally edit the original message to show the selected action.

Slack/Discord:

• Could map to native buttons/interactions where supported.
• If a platform does not support buttons, Hermes could gracefully fall back to text instructions.

Why not use ReplyKeyboardMarkup?

Telegram ReplyKeyboardMarkup can be used as a workaround because button presses send normal text messages. However, it is not the same UX:

• It changes the user's input keyboard.
• It is visually less contextual than inline buttons.
• It is not attached to a specific message.
• It is less suitable for one-off approval/action prompts.

Inline keyboards are a better fit for contextual action prompts.

Why not implement this outside Hermes?

A separate helper process can send Telegram messages with inline keyboards using the Bot API, but it cannot reliably handle button clicks if Hermes gateway is already receiving updates for the same bot token.

Telegram allows only one active update receiver for a bot token when using getUpdates, and webhooks are mutually exclusive with polling. Therefore, callback handling should live inside the Hermes gateway that already owns Telegram updates.

Suggested design

Add a generic action-button abstraction to the messaging/gateway layer:

1. Extend messaging send APIs to optionally accept actions/buttons.
2. Add a platform-neutral action payload format.
3. Implement Telegram rendering via InlineKeyboardMarkup.
4. Route callback_query events back into Hermes as:
   • a normal user message, or
   • a structured gateway action event.
5. Add expiration/session binding for safety.
6. Provide a text fallback for platforms without button support.

Safety considerations

Buttons should support:

• session/workflow binding;
• optional expiration;
• action IDs that are not directly executable shell commands;
• clear audit/logging of what action was selected;
• safe fallback if the session no longer exists.

Existing related behavior

Hermes already has some platform-specific button support for built-in flows such as Telegram model picker and approval prompts. This feature request is about exposing a generic reusable mechanism so other workflows can use the same interaction model without patching gateway code for every use case.