Building an AI Slack Command Center — Lessons from the Arcade AI Project

When I joined the Arcade AI project, the team already had powerful agent capabilities — but they lived behind internal dashboards. Operators still copied prompts into separate tools and pasted results back into Slack. That friction killed velocity.

This post is my original write-up of how we turned Slack into the primary command surface for AI workflows: what we built, why we made specific tradeoffs, and what I learned shipping it toward production.

The problem we were solving

Arcade AI needed a way for engineers and ops to:

• Trigger agent runs from a familiar interface
• Share results in-channel so context stayed visible
• Chain tool calls (search, summarize, act) without writing scripts

Slack wasn't an afterthought — it became the control plane.

Architecture overview

Our stack split into three layers:

1. Slack Bolt app — listens for slash commands, mentions, and button actions
2. Agent router (LangChain) — classifies intent and selects the right tool chain
3. Tool adapters — thin Node.js wrappers over internal REST APIs

// Simplified intent routing pattern we used
async function handleSlackMessage(event: SlackEvent) {
  const intent = await classifyIntent(event.text);
  const agent = selectAgent(intent); // e.g. "research", "ops", "summarize"
  const result = await agent.invoke({ input: event.text, userId: event.user });
  return formatSlackBlocks(result);
}

The critical design choice: never let the LLM call Slack APIs directly. We kept Slack I/O in Bolt handlers and passed only sanitized text into LangChain. That boundary made debugging ten times easier.

What worked well

Channel-scoped memory

We scoped conversation memory by channelId + threadTs, not globally per user. In incident channels, that meant the agent retained context for the active thread without bleeding secrets from DMs.

Structured block responses

Free-text replies were hard to scan. We standardized on Slack Block Kit for:

• Summary header
• Bullet action items
• Collapsible "details" section for raw agent output

Explicit tool failures

When a tool timed out, we returned a visible error block instead of letting the model improvise. Users trusted the bot more once failures were honest.

What I'd do differently

1. Rate limiting per channel — early versions got spammed during load tests
2. Observability first — add trace IDs on every agent run before adding features
3. Smaller default models for routing — intent classification doesn't need the largest model

How this differs from product documentation

The Arcade AI ecosystem publishes SDK and integration guides. This post focuses on our implementation choices on the Arcade project — Slack as command center, LangChain routing patterns, and production lessons — not a reproduction of upstream docs.

If you're building something similar, start with one slash command, one agent, and one tool. Expand only after latency and error budgets are measured.

Key takeaways

• Slack works well as an AI command center when you treat it as an I/O layer, not the brain
• LangChain shines at tool routing; keep Slack-specific code out of chains
• Structured responses beat prose for operational use cases
• Fail loudly — operators forgive errors they can see

Written by Mikey Sharma as part of hands-on work on the Arcade AI platform. For questions, reach out via mikeysharma.com/contact.