Skip to content

gateway/webhook: delegate clarify() to target platform adapter#31566

Open
alexcf wants to merge 1 commit into
NousResearch:mainfrom
alexcf:webhook-clarify-delegation
Open

gateway/webhook: delegate clarify() to target platform adapter#31566
alexcf wants to merge 1 commit into
NousResearch:mainfrom
alexcf:webhook-clarify-delegation

Conversation

@alexcf

@alexcf alexcf commented May 24, 2026

Copy link
Copy Markdown

Closes #31565

See the linked issue for full motivation + reproduction. This PR
implements the proxy/delegate sketch from the issue.

Tests: smoke-tested manually on a Hermes install configured with
deliver: discord + deliver_extra.chat_id. Webhook agent
call to clarify correctly renders native Discord buttons in
the target channel; button click resolves the agent's wait.

Backward compatibility: when deliver is log /
github_comment / unknown / when no chat_id can be resolved,
the implementation falls back to the existing base text behaviour
(no observable change for those configurations).

When a webhook route is configured with deliver=<messaging-platform>
and deliver_extra.chat_id is set, the agent spawned by the webhook
can call clarify() and get a native button render on the target
platform (Discord buttons / Telegram inline keyboard).

Before this change, the WebhookAdapter inherited the base text
fallback for send_clarify, which wrote a numbered list to the
target chat — but the gateway's text-intercept is keyed on the
SOURCE platform's session_key (the webhook session), so a user
reply on the target platform (Discord/Telegram) never resolved the
clarify wait. The agent timed out at clarify_timeout (10 min) with
nothing the user could act on.

This patch implements WebhookAdapter.send_clarify to delegate to
self.gateway_runner.adapters[Platform(route.deliver)] with the
deliver_extra.chat_id. The Discord adapter (or Telegram, Slack,
etc.) renders buttons or text natively; resolution flows through
the existing module-level clarify_gateway._entries registry —
which is platform-agnostic, so any adapter can unblock any agent.

Also: small UX improvement to ClarifyChoiceView (Discord) — button
colour is derived from choice text via a tiny keyword heuristic
(send → success/green, discard/cancel → danger/red, edit/open →
secondary/grey) so common Sift/clarify use cases get visual
hierarchy without an API change.

Behaviour for deliver=log / deliver=github_comment / unknown
platform / missing chat_id is unchanged (falls back to base text
behaviour).

Closes #<ISSUE-NUMBER>
@mohamedorigami-jpg

Copy link
Copy Markdown
Contributor

Clean delegation pattern. The fallback chain (text fallback → adapter not connected → no chat_id → target adapter's send_clarify) means webhook routes that deliver to Discord/Telegram/etc get native buttons/keyboards for clarify without breaking existing log-only or github_comment routes.

The clarify_gateway._entries registry point is key - button clicks resolve via that regardless of source platform, so the webhook session's clarify wait unblocks correctly even though the UI was rendered by a different adapter.

@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/gateway Gateway runner, session dispatch, delivery platform/webhook Webhook / API server comp/plugins Plugin system and bundled plugins labels May 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/gateway Gateway runner, session dispatch, delivery comp/plugins Plugin system and bundled plugins P2 Medium — degraded but workaround exists platform/webhook Webhook / API server type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

webhook: clarify tool unavailable to agents spawned by webhook routes

4 participants