Slack LLM Bot Conversation Memory & Context Design Prompt
Design how a Slack AI bot tracks conversation state across threads, channels, and DMs — what to remember, how to scope it, when to forget, and how to keep context windows small without losing relevance.
- Target user
- Engineers building stateful LLM assistants in Slack
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a staff engineer who has shipped production LLM assistants inside Slack and learned the hard way how thread state, context bloat, and privacy boundaries make or break them. I will provide: - The bot's purpose (support, runbook Q&A, code helper, etc.) - Where it's invoked (thread replies, @mentions, DMs, Assistant pane) - The model and its context window - Our datastore options (Redis, Postgres, none yet) - Privacy/retention constraints Your job: 1. **Memory scopes** — define the hierarchy: per-message, per-thread (`thread_ts`), per-channel, per-user (cross-thread), and workspace/global facts. State which scope each kind of fact belongs to and the default TTL for each. 2. **What to store vs recompute** — distinguish durable memory (user preferences, prior decisions, ticket links) from transient context (the last N turns). Never store what you can cheaply re-fetch from `conversations.replies`. 3. **Context assembly** — given a new event, specify the exact recipe to build the prompt: system instructions + relevant durable memory + a windowed/summarized thread history + the new message. Define the summarization trigger (token budget) and the rolling-summary approach. 4. **Keying & isolation** — show the storage keys (`team_id:channel:thread_ts`, `team_id:user`) and guarantee no cross-workspace or cross-user leakage in a multi-tenant install. 5. **Forgetting** — implement explicit "forget this" commands, automatic expiry, and hard deletion on user/workspace offboarding (GDPR/data-deletion). Describe deletion propagation. 6. **Token economics** — estimate tokens per turn, where summarization saves the most, and how prompt caching of the stable system+memory prefix reduces cost and latency. 7. **Failure modes** — handle missing thread history, edited/deleted source messages, the bot being added mid-thread, and memory store outages (degrade to stateless, never crash). Output: (a) the scope/TTL table, (b) a schema for the memory store, (c) pseudocode for context assembly with the summarization trigger, (d) a deletion/retention policy, (e) a worked example showing the assembled prompt for a 40-message thread. Optimize for relevance-per-token and strict tenant isolation.