Context

Companies operate across an average of 275 applications, and critical knowledge fragments across all of them. Even when you find the answer, taking action means jumping between systems. Slack sits in the sweet spot of the work graph — 1 hour 42 minutes of daily use on average, a billion messages a day, and the story behind every decision that doesn’t get recorded anywhere else. The brief: embed AI into Slack search so users can find what they’re looking for, take action without swiveling, and move work into channels — all from one search box.

Two paths

We pursued two tracks: a scrappy prototype built into Slack using federated search connectors and Claude-based tools, and a long-term unified platform powered by Salesforce’s Data Cloud and Agentforce. We dogfooded the prototype on our own Slack instance within five weeks, with one question: would users find value in multi-turn search?

Search prototype demo — internal dogfood (2024)
Internal Slack prototype: AI answer with key-message unfurl, citations, and LLM-generated follow-up suggestions
In-line hero message unfurl, embedded citations, and follow-ups next to the composer.
Slack omniswitcher with a toggle between traditional search and agentic search, suggesting conversational prompts
Toggle between traditional search and agentic search inside the Slack omniswitcher.
Full-screen AI Search workspace with a centered input, suggested prompt cards, and a left rail of chat history grouped by day
'Good afternoon, Carmen!' landing page with 'Pick up where you left off' history and contextual follow-up chips
Two early prototypes for the agentic-search welcome mat — a full-screen workspace and a chat-style landing page.

What landed

  • Key message unfurls. When the LLM promoted a single high-relevance message inside the answer, the message did more work than any synthesis paragraph.
  • Citations with hover previews. Trust scaled with citation visibility; without them, even correct answers got dismissed.
  • LLM-generated follow-ups. Users said “I didn’t even think to ask that question, but it was perfect.”

What didn’t

  • The interaction felt unfamiliar. A clean answer pane didn’t fit Slack’s core messaging framework.
  • Answers weren’t shareable. The rich UI wasn’t built on Block Kit, so answers couldn’t move into channels — the conversational unit died on the search page.

The deeper signal was in the engagement data: only about 10% of users asked a follow-up, and most picked from pre-generated suggestions. Search alone wasn’t a product — it was an answer with no exit.

The layout exploration

The unified-platform work had a different shape: cross-ranked results from Data Cloud, an Agentforce answer, and a leadership ask to show both on the first turn — not progressively. Most agentic search products show the answer first and reveal results on demand; showing both at once meant a layout that didn’t make either feel secondary.

Layout exploration: agentic answer pane on the left, search results on the right
Layout exploration: agentic answer pane on the right, search results on the left
Layout exploration: stacked — agentic answer at top, search results below in a single column
Mobile stacked layout: agentic answer at top, top results below

The product at pilot

What shipped: the unified search experience with an Agentforce answer pane and cross-ranked results pulled from across the company’s tools.

Pilot product: unified search with cross-ranked results from Slack, Salesforce, Google Drive, GitHub, and other connected sources
Cross-ranked results across Slack, Salesforce, Drive, GitHub, and connected tools.
Mobile: Agentforce answer with inline citations and source links
Mobile: Agentforce answer with inline citations.

The redirection

A week before pilot, the frame shifted. A small engineering team had been prototyping Slackbot — a conversational agent with deep access to the work graph. The question became: if the conversational entry point can do everything search-with-an-answer was trying to do, what’s standalone agentic search?

The honest answer: a capability inside Slackbot, not a standalone product. The prototype data had already pointed there — users wanted to take action, share answers, follow up. Things a chat surface does naturally and a search page doesn’t.

The architectural case sealed it. Slackbot ran directly on the latest frontier models, while the unified-platform path was tied to a slower model lifecycle. We had full control over the system prompt and agent harness — the platform was a black box we could only configure around. And the extensibility story was night-and-day: building primitives like MCP and skills inside Slackbot took weeks, not quarters.

The search prototype had already become a chat product. Naming the redirection just made it official.

Outcomes

Slackbot launched January 13, 2025, carrying the patterns the search work had surfaced.

Slackbot end-state: agent-to-agent handoff closing an opportunity, with record details and editable transactional confirmations
Agent-to-agent handoff inside Slackbot, closing an opportunity with editable transactional confirmations.

Reflection

The lesson I’ll carry is about context. Agent failures in enterprise search look like model failures — wrong answer, missed source, hallucinated detail — but they’re rarely model failures. They’re context failures: the agent didn’t have the right data, didn’t know the user’s role, didn’t get the permission scope right. Most of the design work that mattered turned out to be context work — what to surface, hide, cite, hand off. The model is the easy part.

The other lesson is about the right granularity of “product.” Sometimes the right move is to stop being a standalone thing and become a capability an adjacent thing can use. Knowing when to make that move cleanly is its own design judgment — and in my experience, the part most teams get wrong by trying to ship too late, after the case for the standalone product has already collapsed under its own data.