Summary

Aspire's daily-call-summary digest posts each customer call to Slack with a "Go Deeper" button meant to post a fuller breakdown back into the thread on click. In production, clicking it completed successfully server-side but nothing useful ever reached Slack , only a one-line confirmation sentence landed on the original message, describing a breakdown that was never actually written down anywhere.

Root cause: "Go Deeper" reuses the generic Slack approval-button machinery (agent_prompt op), whose shared wrapper prompt caps the model's <final_answer> text at "ONLY a short confirmation (1-2 sentences)". That's correct for apply-style buttons (CRM field change, task update) where the real effect already happened via a tool call and the text is just a receipt , but Go Deeper has no other effect; the breakdown is the deliverable, and it was silently discarded.

Changes

• handleSlackInteraction now derives the real Slack channel + thread from the click payload itself (the only place it can be known , a button's prompt is authored before the thread's ts exists) and passes it through OperationContext.
• agent_prompt gains an opt-in deliverContentToThread arg. When set, the wrapper prompt instructs the run to post its real output via notify-user into that channel/thread, and lets <final_answer> stay a short receipt.
• Kept opt-in, not automatic: my first pass injected the new instruction unconditionally into every agent_prompt run. agent_prompt also backs the "Accept" button on essentially every CRM-approval card across every Cedar customer (crm-updater.ts, plus pipeline-review.ts, inbound-email-notifier.ts, ambiguity-ping-message.ts) , those must see an unchanged prompt. Caught this in a thermo-review pass on the diff before opening this PR; fixed by gating behind the new opt-in arg, with a regression test locking in that ordinary approval buttons are unaffected.
• Also updates Aspire's live daily-call-summary org subagent doc to set deliverContentToThread: true on its button and documents the failure mode directly in the doc so it doesn't quietly regress.

Test plan

• pnpm --filter @zero/server run types , clean
• pnpm --filter @zero/server exec vitest run src/mastra/operations/__tests__/operation-registry.test.ts , 6/6 passing (3 new: instruction present when opted in, "lost" warning present, and , the regression guard , absent entirely when not opted in)
• pnpm deps:check , 0 violations
• Traced every existing call site of dispatchOperation/agent_prompt (Slack buttons, Slack reactions, iMessage tapbacks) to confirm no other surface is affected
• Manual: next daily-call-summary digest run in Aspire's #cedar-call-reviews, click "Go Deeper" on a call entry, confirm the real breakdown posts as a new thread reply

🤖 Generated with Claude Code

https://claude.ai/code/session_01GPYHTQhFJ4WuDvsnoUVHy3

Greptile Summary

This PR adds opt-in delivery of substantive agent_prompt output to the Slack thread where a button was clicked.

• Captures the Slack channel and parent-thread timestamp from block_actions payloads.
• Adds deliverContentToThread to agent_prompt and instructs the agent to use a notification tool for long-form content.
• Adds prompt-level regression tests ensuring ordinary approval buttons remain unchanged.
• The delivery instruction currently names only the granular notification tool, leaving the feature broken when the family-agent surface is selected.

Confidence Score: 4/5

This PR is not yet safe to merge because threaded content delivery remains broken whenever the family-agent feature flag selects the notify tool surface.

The new prompt always mandates the granular notify-user interface, while the existing runtime can select a family toolset that exposes only notify with a different argument schema, preventing the substantive Slack