hermes - 💡(How to fix) Fix Feature request: trusted internal triggers between gateway role sessions [1 comments, 2 participants]

Feature Description

Add a first-class Trusted Internal Session Trigger / Role Handoff mechanism for Hermes gateway sessions.

The core idea: an authorized Hermes session (for example a Director / coordinator session) should be able to dispatch a bounded task to another predefined Hermes gateway session or role chat (for example Backend, Frontend, QA, SRE) and have that target session execute visibly in its own chat/thread.

This should not be implemented as naive bot-to-bot Telegram message triggering. Instead, it should be a platform-agnostic internal handoff primitive with explicit authorization, loop prevention, concurrency limits, audit logging, and preserved high-risk approval gates.

Motivation

Some users run Hermes as a multi-role work system across messaging platforms. A common pattern is:

1. The user talks mainly with one coordinator / Director session.
2. The coordinator breaks work into tasks for specialized role chats.
3. Each role chat executes in its own context and reports there.
4. The coordinator summarizes results and proposes the next round.

Today, this requires the human user to manually "ignite" every role chat by copying a short trigger message into each Telegram/Discord/Signal/etc. chat. That works, but it is tedious and prevents true parallel multi-role execution from a single control conversation.

Hermes already has related building blocks:

• gateway sessions and platform delivery
• cron/background jobs
• webhooks
• delegation/subagents
• profiles and multi-agent discussions
• command approval / risk gates

But there is no safe first-class way for one authorized gateway session to trigger another role/session to start a real visible execution turn.

Proposed Solution

Introduce an internal handoff/trigger API, conceptually something like:

session_triggers:
  enabled: true
  sources:
    director:
      allowed_targets: [backend, frontend, qa, sre]
      max_depth: 1
      max_concurrent_targets: 4
      default_risk: low
      require_human_confirmation_for: [dangerous, production_write, public_infra]

And an internal task object like:

{
  "source_session": "director",
  "target_session": "frontend",
  "target_chat": "telegram:-1234567890",
  "task": "Review the public preview homepage and report mobile/visual blockers.",
  "risk_level": "low",
  "forbidden_actions": ["db_write", "worker_restart", "nginx_reload", "dns_change", "secret_change"],
  "reply_policy": "post_progress_in_target_chat",
  "audit_id": "handoff_...",
  "requires_user_confirmation": false
}

The target role/session should then receive a visible execution event in its own gateway chat, similar to:

Director handoff received: Review the public preview homepage and report mobile/visual blockers.
Boundary: low-risk only; no production writes or infrastructure changes.

Then that target Hermes session performs a normal turn with its own memory/context/tools and reports in that chat.

Required Guardrails

This feature needs strong safety controls:

• Source allowlist: only trusted sessions/profiles can trigger others.
• Target allowlist: only configured target sessions/chats can be triggered.
• Risk policy: default low-risk only; high-risk tasks still require explicit human approval.
• Forbidden actions: task-level guardrails should be injected into the target prompt/context.
• Recursion depth limit: prevent A -> B -> C -> A loops.
• Deduplication: avoid repeated triggers from retries or edited messages.
• Per-target concurrency limit: prevent multiple overlapping runs in the same role chat.
• Rate limits and budgets: avoid accidental cost/quota explosions.
• Audit log: source, target, prompt, timestamps, outcome, approval IDs.
• Cancellation: coordinator or user can cancel a pending/running triggered task.
• Visible target delivery: the target chat should show the task/progress/result, preserving the messaging UX.

Non-goals

This request is not asking for:

• arbitrary bot-to-bot message triggering
• allowing Telegram bot messages to bypass normal authorization
• a default-on mode where any bot can trigger Hermes
• bypassing command approvals or dangerous-action confirmations
• hidden background execution with no visible target-chat trace

Naive bot-to-bot triggering is risky because it can cause loops, spoofing, permission confusion, cost explosions, and platform-specific edge cases. The request is for a safer Hermes-native internal trigger/handoff primitive.

Example Use Case

A user has role chats:

• Director — main coordination chat
• Product
• Core Data
• Backend
• Frontend
• QA
• SRE

The user only talks to Director:

Please start the next release-readiness round.

Director dispatches low-risk tasks to role chats:

• Backend: inspect API readiness, no production writes
• Frontend: review preview UX, no deploy
• QA: run read-only acceptance checks
• SRE: inspect runtime health, no restart

Each role executes visibly in its own chat and reports there. Director later summarizes. Any risky action is escalated back to the user for explicit confirmation.

Relationship to Existing Issues

This is related to, but narrower/different from:

• #7517 Native Multi-Agent Support
• #5143 Multi-Role Auto-Routing via Gateway Hooks
• #6419 Telegram inter-bot collaboration protocol
• #13083 TELEGRAM_ALLOW_BOTS
• #14853 Multi-Agent Discord channel collaboration
• #16939 Visible Multi-Agent Conversations in Gateway Chats
• #5712 True Autonomy / injecting background results into live sessions

The distinction: this proposal is not primarily about auto-routing incoming human messages, channel history injection, or open-ended agent debate. It is about safe, authorized, auditable one-session-to-another task ignition across existing gateway role sessions.

Why this matters

This would let Hermes support a practical "AI organization" workflow without forcing the human user to manually copy/paste trigger phrases into every role chat.

It also keeps the important UX property that each role still works visibly inside its own Telegram/Discord/Slack/etc. chat, while the coordinator session can orchestrate parallel work from one main conversation.