RFC: Explicit external agent routing from messaging gateway

Title

RFC: Explicit external agent routing from messaging gateway

Problem

Hermes is the default assistant in messaging gateways, but some users also want to invoke specialized external execution backends from the same chat entry point. Examples include coding agents, local automation runners, or future project-specific workers.

Without a first-class routing model, integrations tend to become one-off command branches with unclear defaults, safety rules, and observability.

Proposal

Introduce an explicit, opt-in external agent routing model for messaging gateways.

Potential command shape:

• /agent <backend> <task>: route one task to a named backend.
• /mode <backend>: set the current session default backend.
• /mode hermes: restore Hermes as the default backend.
• /route: show the current route, backend availability, and last run status.
• /agent status: show enabled backends and last execution metadata.

Codex can be treated as one possible backend, but the core design should not be coupled to Codex or to any specific vendor.

Safety Requirements

• Hermes remains the default route.
• External backends are disabled unless explicitly configured.
• Group chats are disabled by default unless explicitly allowed.
• Dangerous operations require confirmation.
• Execution uses argv isolation or an equivalent non-shell invocation model.
• Last-run status and audit metadata are recorded for diagnosis.
• Admins can disable a backend with one environment/config flag.

Suggested Backend Contract

A backend should provide:

• name: stable backend identifier.
• enabled(): whether routing is allowed.
• status(source, session): diagnostic status and last-run metadata.
• run(task, source, session, approved): execute one request.
• requires_confirmation(task): detect high-risk operations.

Reference Behavior

A local prototype used:

• /codex <task> for one-off routing.
• /mode codex and /mode hermes for session defaults.
• /route and /codex status for diagnostics.
• /codex approve <id> and /codex cancel <id> for high-risk operations.
• argv-based subprocess execution and status/audit files.

That prototype should be considered an implementation sketch, not a required upstream API.

Open Questions

• Should routing live in gateway core or as a plugin hook?
• Should route state be stored per platform chat, per user, or per gateway session?
• Should confirmation policies be centralized or backend-defined?
• Should Web UI expose backend status and audit history?
• What should the stable command syntax be?

Acceptance Criteria

• A messaging user can route a task to a configured backend without changing the default Hermes behavior.
• A maintainer can disable the feature entirely.
• A failed backend run leaves enough status evidence to diagnose the failure.
• No chat text is shell-expanded.

Risk

Medium to high. This changes product surface and safety expectations, so it should start as an RFC before code is proposed.