Keep users engaged with continuous status updates during operations
After this lesson, you'll see this difference:
❌ BEFORE (7 seconds of silence = user thinks bot is broken):
User: "@bot what did we discuss about the API changes?"
[silence...]
[silence...]
[silence...]
Bot: "Here's what you discussed about API changes..."
✅ AFTER (continuous feedback = user knows bot is working):
User: "@bot what did we discuss about the API changes?"
Bot: "is reading thread history..." (0-1s)
Bot: "is analyzing 23 messages..." (2-3s)
Bot: "is identifying key decisions..." (4-5s)
Bot: "Here's what you discussed about API changes..." (final)
What changed? Added status update rules to the system prompt. No new infrastructure required.
Users abandon bots that go silent for 3+ seconds. When your bot fetches context, calls APIs, or processes complex requests, silence feels like failure. Three seconds of nothing and users assume it broke. Always-on status communication keeps them engaged and sets proper expectations about what's actually happening.
Outcome
Implement always-on status communication that provides continuous feedback during every bot operation.
Visual Flow
┌─────────────────────────────────────────────────────────────────┐
│ Never-Silent Status Communication │
└─────────────────────────────────────────────────────────────────┘
Timeline: 0s ──────── 2s ──────── 4s ──────── 6s ──────── 8s
User: "@bot what did we discuss about API changes?"
↓
┌─────────────────┐ 0-1s
│ "is processing │ ────────────────────────────────────────────→
│ request..." │
└─────────────────┘
↓ 1-2s
┌─────────────────┐
│ "is reading │ ────────────────────────→
│ thread history" │
└─────────────────┘
↓ 3-4s
┌─────────────────┐
│ "is analyzing │ ──────→
│ 23 messages..." │
└─────────────────┘
↓ 5-6s
┌─────────────────┐
│ "is composing │
│ response..." │
└─────────────────┘
↓ 7s
┌─────────────────┐
│ Final Response: │
│ "Based on the │
│ discussion..." │
└─────────────────┘
❌ BAD: 7 seconds of silence → User thinks bot is broken
✅ GOOD: Continuous updates → User knows bot is working
Key Principles:
- < 1 second: Initial acknowledgment ("is processing request...")
- Every 2-3 seconds: Progress update with specifics
- Include counts: "is analyzing 23 messages..." vs "is analyzing..."
- Never go silent: If operation > 2s, show what you're doing
Fast Track
- Update system prompt to require status updates before every operation
- Add status calls before each tool execution in existing prompts
- Test with complex query and observe continuous feedback
Hands-On Exercise 4.3
Implement always-on status communication by enhancing the existing system prompt:
Requirements:
- Update system prompt in
respond-to-message.tsto mandate status updates - Ensure status updates happen before every tool call
- Use descriptive, progress-aware status messages
- Maintain 10-40 character status format: "is [verb]ing [object]..."
Implementation hints:
- Modify the existing system prompt's status rules (lines 64-66)
- Add status requirements for tool sequences
- Use present continuous tense: "is reading", "is analyzing", "is composing"
- Include progress indicators when available: "is analyzing 23 messages"
Status update pattern:
1. Immediate acknowledgment: "is processing request..."
2. Before each tool: "is reading thread history..."
3. During processing: "is analyzing messages..."
4. Before response: "is composing answer..."
Try It
-
Test complex context query:
@bot what did we decide about the database migration?You should see:
- "is processing request..." (immediate)
- "is reading thread history..." (before getThreadMessagesTool)
- "is analyzing messages..." (after tool, before response)
- Final answer with decisions
-
Test simple query:
@bot explain how webhooks workYou should see:
- "is processing request..." (immediate)
- "is composing response..." (before generating answer)
- Final explanation
-
Observe continuous feedback:
- No gaps longer than 2 seconds without status updates
- Each status describes current operation
- Progress indicators when available
On Enterprise Sandbox/Enterprise Grid, assistant status updates generally work out of the box. On Pro/Business+, if assistants aren't visible, continue with message-based status (e.g., text updates or reactions) and skip assistant-specific UI.
Commit
git add -A
git commit -m "feat(ai): implement always-on status communication for continuous UX"Done-When
- Every operation longer than 2 seconds shows status updates
- Status messages are descriptive and progress-aware
- No dead air between user message and bot activity
- Complex queries show multi-stage status progression
Solution
Replace the entire system prompt in /slack-agent/server/lib/ai/respond-to-message.ts with:
system: `You are Slack Agent, a helpful assistant in Slack.
${
"channel_type" in event && event.channel_type === "im"
? "You are in a direct message with the user."
: "You are in a channel with multiple users."
}
RESPONSE RULES:
1. Give a direct answer immediately - no preambles like "I'd be happy to help"
2. Be concise but complete
3. ALWAYS end with exactly two next steps
4. When users ask to "thumbs up", "react", "add emoji", or "celebrate" - use the reactToMessageTool
Format your response like this:
[Direct answer to the question]
**Next steps:**
• [Specific action the user can take right now]
• [Alternative approach or follow-up action]
CRITICAL: ALWAYS-ON STATUS COMMUNICATION
- IMMEDIATELY update status when you receive any request: "is processing request..."
- UPDATE STATUS BEFORE every tool call: "is reading thread history...", "is analyzing messages..."
- INCLUDE PROGRESS when possible: "is analyzing 23 messages...", "is checking 3 channels..."
- NEVER GO SILENT - if processing takes >2 seconds, show what you're doing
- STATUS FORMAT: "is [verb]ing [object]..." (10-40 characters)
Core Rules
1. Decide if Context Is Needed
- If the message is related to general knowledge, such as "Who is the president of the USA", show "is processing request..." then respond.
- If the message references earlier discussion, uses vague pronouns, or is incomplete → fetch context with status updates.
- If unsure → fetch context with status updates.
2. Status Communication Protocol
- FIRST: Always updateAgentStatusTool("is processing request...") immediately
- BEFORE EACH TOOL: updateAgentStatusTool with specific operation
- INCLUDE NUMBERS: "is reading thread history...", "is analyzing 47 messages..."
- BEFORE FINAL RESPONSE: "is composing answer..." or "is finalizing response..."
- Use multiple tool calls at once whenever possible.
3. Fetching Context
- If the message is a direct message, you don't have access to the channel, you only have access to the thread messages.
- ALWAYS update status: "is reading thread history..." → getThreadMessagesTool
- If thread messages don't answer: "is reading channel messages..." → getChannelMessagesTool
- Progress updates: "is analyzing X messages...", "is searching for relevant context..."
- Use the combination of thread and channel messages to answer the question.
4. Titles
- You can only update the title if you are in a direct message.
- New conversation started → updateChatTitleTool with a relevant title.
- Topic change → updateChatTitleTool with a new title.
- Never update your status or inform the user when updating the title. This is an invisible action the user does not need to know about.
5. Responding
- BEFORE generating final answer: updateAgentStatusTool("is composing response...")
- After fetching context, answer clearly and helpfully.
- Include progress indicators in status when available
- Slack markdown does not support language tags in code blocks.
- If your response includes a user's id like U0931KUHGC8, you must tag them. You cannot respond with just the id. You must use the <@user_id> syntax.
OPERATION FLOW WITH STATUS:
Message received → "is processing request..." → decide context needs
├─ Needs context:
│ ├─ "is reading thread history..." → getThreadMessagesTool
│ ├─ "is analyzing X messages..." → process results
│ ├─ If needed: "is reading channel messages..." → getChannelMessagesTool
│ └─ "is composing response..." → respond
└─ No context needed:
├─ "is composing response..." → respond
└─ End
Remember: NEVER go silent. Every operation gets a status update.`,Building on Previous Lessons
This lesson solves a critical UX problem in stateless systems:
- From Bolt Middleware: Middleware adds cross-cutting concerns like status and correlation tracking
- From system prompts: System prompts now mandate status updates as a core behavior pattern
- From AI tools:
updateAgentStatusToolprovides the mechanism for continuous feedback during multi-step operations - Production reasoning: Stateless functions can't maintain WebSocket connections - status updates prevent perceived failures during long operations
- Sets up error handling: Error handling will maintain status communication even during retries and fallbacks
Was this helpful?