Skip to content

feat(slack): tell trigger agent to always reply in the user's thread#440

Merged
decobot merged 1 commit into
mainfrom
slack-trigger-reply-instruction
May 14, 2026
Merged

feat(slack): tell trigger agent to always reply in the user's thread#440
decobot merged 1 commit into
mainfrom
slack-trigger-reply-instruction

Conversation

@JonasJesus42
Copy link
Copy Markdown
Contributor

@JonasJesus42 JonasJesus42 commented May 14, 2026

Summary

Follow-up to #439. Even with thread_messages and user_name in the trigger payload, the subscriber had no explicit signal saying which thread_ts to use when replying — and for a fresh top-level DM event.thread_ts is undefined, so the agent could not derive it from the event alone.

Bake the reply contract into both the payload and the trigger definition:

  • reply_in_thread_ts = event.thread_ts ?? event.ts is now computed by the publisher. For thread continuations it's the existing thread; for top-level messages it's the message's own ts, which kicks off a new thread the moment the bot replies. The agent never has to decide start-vs-continue.
  • reply_instruction: a one-line natural-language directive spelling out the exact SLACK_REPLY_IN_THREAD(channel, thread_ts) tool call, so prompt-driven subscribers see the contract inline.
  • Trigger definitions in trigger-store.ts now embed the contract in the description that studio (and any agent reading the schema) sees: "To respond, ALWAYS call SLACK_REPLY_IN_THREAD with channel=channel_id and thread_ts=reply_in_thread_ts so every answer lives inside the user's thread."

Test plan

  • In triggerOnly mode, send a top-level DM → reply_in_thread_ts in the payload equals event.ts.
  • Reply inside the bot's thread → reply_in_thread_ts equals the thread's thread_ts.
  • Trigger subscriber agent uses SLACK_REPLY_IN_THREAD(channel_id, reply_in_thread_ts, ...) and the reply appears in the right thread.
  • Studio shows the updated trigger description.

Summary by cubic

Make Slack agents always reply in the user’s thread. Adds reply_in_thread_ts and a reply_instruction to trigger payloads and documents the contract in trigger descriptions.

  • New Features
    • Compute reply_in_thread_ts = event.thread_ts ?? event.ts for slack.message.received and slack.app_mention, so agents never decide start vs continue.
    • Include reply_instruction that spells the exact SLACK_REPLY_IN_THREAD(channel_id, reply_in_thread_ts) call.
    • Update trigger descriptions to document the reply contract and keep all answers in the user’s thread.

Written for commit 78bd494. Summary will update on new commits.

Even with thread_messages and user_name in the payload, the trigger
subscriber had no explicit signal saying which thread_ts to use when
replying — and for a fresh top-level DM event.thread_ts is undefined,
so the agent could not derive it from the event alone.

Bake the contract into the payload and the trigger definition:

- Add `reply_in_thread_ts = event.thread_ts ?? event.ts` so the agent
  always has a concrete thread_ts to pass to SLACK_REPLY_IN_THREAD. For
  thread continuations this is the existing thread; for top-level
  messages this is the message's own ts, which kicks off a new thread
  the moment the bot replies. The agent NEVER has to decide
  start-vs-continue.
- Add `reply_instruction`: a one-line natural-language directive that
  spells out the tool call (channel + thread_ts pair) the agent should
  use, so prompt-driven subscribers see the contract inline.
- Update the trigger DEFINITIONS in trigger-store.ts so studio (and any
  agent reading the schema) sees the contract as part of the trigger
  description, not just inside the payload.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@decobot decobot merged commit 83f5457 into main May 14, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants