Slack vs Buzz

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Slack
   Slack✓fullprobed8/10

   Slack has a confirmed llms.txt at docs.slack.dev/llms.txt (HTTP 200) plus llms-full-deno.txt variants, and its developer docs are explicitly agent-oriented (MCP server, AI build guides, quickstart) suitable for pointing an agent at. missing for 10: no independent/community confirmation of an agent successfully consuming llms.txt in practice, and OpenAPI-style machine spec endpoints under docs.slack.dev returned 404.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.slack.dev/llms.txt # Slack Developer Docs > The official documentation for building on the Slack p…”
   • [claimed-docs] “Once connected, your AI assistant can search channels, read messages, and use real conversation context to help you build.”
   • [claimed-docs] “You can create Slack-hosted workflows written in TypeScript using the Deno Slack SDK.”
   • [probe] “official MCP server documented at https://docs.slack.dev/ai/slack-mcp-server/”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.slack.dev/openapi.json, https://docs.slack.dev/swagger.json, https://docs.slack.dev/api…”

   proof ↗⚑ flag

   Buzz—none0/10

   A direct probe found no llms.txt at buzz.xyz (404), and no evidence pack item references agent-oriented documentation formats or discoverability files; only an MCP server and CLI are documented, which don't satisfy this specific story. Missing for 10: an llms.txt or equivalent agent-readable docs endpoint, any mention of agent-oriented documentation standards.

   • [probe] “PROBE llms.txt: HTTP 404 at https://buzz.xyz/llms.txt”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Slack
   Slack✓fullclaimed7/10

   Slack's Web API (chat.postMessage etc.) is a pure HTTP interface callable without any UI, the Events API supports webhook/Socket Mode server-side listening, Workflow Builder supports webhook triggers to kick off automations from outside Slack, and the Slack CLI/Bolt SDKs let apps be built, deployed, and run non-interactively — all enabling headless automation suitable for CI-like use. Missing for 10: explicit CI/CD pipeline examples (e.g. GitHub Actions integration), and no documentation of running the CLI/SDKs specifically inside a CI runner or headless test harness.

   • [claimed-docs] “The Slack Web API is an interface for querying information from and enacting change in a Slack workspace.”
   • [claimed-docs] “Sends a message to a channel.”
   • [claimed-docs] “Webhook triggers for workflows - How to start a workflow from outside of Slack.”
   • [claimed-docs] “When you use the Events API, _Slack_ calls _you_. ... you can either use Socket Mode or you can designate a public HTTP endpoint”
   • [claimed-docs] “When you use the Events API, Slack calls you.”
   • [claimed-docs] “The Slack command-line interface (CLI) allows you to create and manage Slack apps from the command line.”
   • [claimed-docs] “Send data to or query data from Slack using any of more than 200 methods.”
   • [claimed-docs] “Official slackapi/slack-api-specs repo: "This repository contains API specifications of Slack platform features and APIs... You'll find Open…”
   • [claimed-docs] “This quickstart guide covers how to create a Slack app using the Slack CLI and the Bolt frameworks, in either Python or JavaScript.”

   proof ↗⚑ flag

   Buzz~partialprobed5/10

   Buzz ships a CLI (buzz-cli) with scriptable commands for channels, workflows, repos, etc. (buzz-docs-5/7/8), which implies it can be driven non-interactively/automated, and agents have their own keys/audit trails (buzz-gh-4) suggesting programmatic access. However, there is no explicit documentation of a headless mode, CI pipeline integration, or CI-specific examples for Buzz itself. Missing for 10: explicit headless/CI-mode documentation, CI pipeline examples, and independent confirmation of running Buzz unattended in automation.

   • [claimed-docs] “buzz channels create --name "my-channel" --type stream --visibility open”
   • [claimed-docs] “buzz repos protect set --id my-repo --ref refs/heads/main --push admin --no-force-push --no-delete”
   • [claimed-docs] “buzz workflows trigger --workflow buzz workflows approve --token”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round to Buzz
   Slack—none0/10

   All evidence describes Slack exposing its own official MCP server so external AI clients (Claude, ChatGPT, custom agents) can call Slack's tools — the reverse direction of this story, which asks whether a user can plug external MCP servers into Slack so Slack's own agents (e.g., Slackbot) can use their tools. No evidence shows Slack acting as an MCP client that consumes third-party MCP servers.

   • [claimed-docs] “your integrated apps can search channels, send messages, and perform other Slack actions through MCP clients”
   • [claimed-docs] “The Slack MCP server provides tools for searching through Slack, retrieving and sending messages, managing canvases, managing users, uploadi…”
   • [claimed-docs] “Workspace admins can approve and manage all MCP client integrations, keeping your Slack data safe.”
   • [claimed-docs] “Once connected, your AI assistant can search channels, read messages, and use real conversation context to help you build.”
   • [claimed-docs] “Route work through Slackbot. Coordinate work by routing requests to agents and get results delivered right back into your workflow.”

   proof ↗⚑ flag

   Buzz~partialprobed3/10

   The only evidence is a documented file titled MCP_DRIVEN_HOOKS.md, suggesting Buzz supports MCP-driven hook integration, but no actual content, examples, or independent confirmation of plugging in third-party MCP servers is provided. Missing for 10: detailed docs on configuring/adding MCP servers, examples of tool usage via MCP, and community or hands-on validation.

   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Slack
   Slack✓fullprobed8/10

   Slack publishes an official MCP server (docs.slack.dev/ai/slack-mcp-server/) that lets MCP clients/agents search channels, send/draft messages, manage canvases, lists, files, and users, with admin approval controls for governance; this is corroborated by a direct probe confirming the docs page exists. Missing for 10: independent hands-on third-party verification of the MCP server's real-world reliability/performance beyond first-party docs.

   • [claimed-docs] “your integrated apps can search channels, send messages, and perform other Slack actions through MCP clients”
   • [claimed-docs] “The Slack MCP server provides tools for searching through Slack, retrieving and sending messages, managing canvases, managing users, uploadi…”
   • [claimed-docs] “Send messages — send messages to any type of conversation in Slack.”
   • [claimed-docs] “Create and read lists — create lists with custom schemas and read their contents.”
   • [claimed-docs] “Workspace admins can approve and manage all MCP client integrations, keeping your Slack data safe.”
   • [claimed-docs] “Draft messages — draft, format, and preview messages directly within AI clients.”
   • [probe] “official MCP server documented at https://docs.slack.dev/ai/slack-mcp-server/”

   proof ↗⚑ flag

   Buzz~partialprobed6/10

   Buzz is a chat/collaboration platform (not itself an agent), so shipping an MCP server axis applies; probe evidence confirms an official MCP-related doc (MCP_DRIVEN_HOOKS.md) exists in the repo, and the product's core design explicitly gives agents their own keys, channel memberships, and audit trails for connecting to the platform. However, the evidence pack lacks detailed documentation of the MCP server's setup, tool surface, or independent confirmation it works as described, and community commentary raises real concerns about the permission/auth model's real-world robustness. Missing for 10: full MCP server documentation/spec, independent hands-on verification of connecting an agent via MCP, and resolution of the permission-model critiques.

   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [community] “Commenter says Buzz uses channel-based scoping like humans would, but criticizes that it invented its own auth/permission protocol instead o…”
   • [community] “Critique of Buzz's group permission model: "These kinds of rules never survive real world tests. For example if I create a private group jus…”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round drawn
   Slack✓fullprobed8/10

   Slack ships an official CLI for building/managing Slack apps (slack-docs-9, slack-docs-1, slack-docs-26/40/60, slack-probe-4), with quickstart guides supporting Bolt frameworks in multiple languages, tied into an AI-native workflow (docs mention creating agents via 'slack create' and building AI-integrated apps). Missing for 10: independent/hands-on community corroboration of the CLI itself (community evidence in the pack is unrelated to CLI usage) and more detail on AI-native-specific CLI commands beyond scaffolding.

   • [claimed-docs] “The Slack command-line interface (CLI) allows you to create and manage Slack apps from the command line.”
   • [claimed-docs] “Download the command-line tool for developing Slack apps.”
   • [claimed-docs] “Set up a new Bolt project from a starter template. `slack create`”
   • [claimed-docs] “slack create”
   • [claimed-docs] “Set up a new Bolt project from a starter template.”
   • [claimed-docs] “This quickstart guide covers how to create a Slack app using the Slack CLI and the Bolt frameworks, in either Python or JavaScript.”
   • [probe] “official CLI documented at https://docs.slack.dev/tools/slack-cli/”

   proof ↗⚑ flag

   Buzz✓fullprobed8/10

   Buzz ships an official CLI (buzz-cli crate) with documented commands spanning channels, repos, workflows, and GIF search, confirming it's a first-class part of the product for agentic/scripted workflows. missing for 10: independent hands-on verification of the CLI beyond vendor docs, and no evidence of broader AI-native conveniences like an llms.txt or shell completions.

   • [claimed-docs] “buzz channels create --name "my-channel" --type stream --visibility open”
   • [claimed-docs] “buzz gifs search # trending GIFs”
   • [claimed-docs] “buzz repos protect set --id my-repo --ref refs/heads/main --push admin --no-force-push --no-delete”
   • [claimed-docs] “buzz workflows trigger --workflow buzz workflows approve --token”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round to Slack
   Slack✓fullprobed9/10

   Slack ships extensive documented public APIs (Web API with 200+ methods, Events API, Bolt/CLI SDKs, official OpenAPI/AsyncAPI specs in slackapi/slack-api-specs) plus an official MCP server enabling AI-native agents to search, message, upload files, manage lists/canvases — all first-party documented and independently verifiable via the public GitHub spec repo. missing for 10: no independent hands-on report specifically confirming the raw REST/Web API (vs MCP) working end-to-end from a third-party AI integrator, and the docs.slack.dev/openapi.json probe returned 404 suggesting the interactive spec isn't hosted at the expected discovery path.

   • [claimed-docs] “The Slack Web API is an interface for querying information from and enacting change in a Slack workspace.”
   • [claimed-docs] “The Slack Web API is an interface for querying information _from_ and enacting change _in_ a Slack workspace.”
   • [claimed-docs] “your integrated apps can search channels, send messages, and perform other Slack actions through MCP clients”
   • [claimed-docs] “The Slack MCP server provides tools for searching through Slack, retrieving and sending messages, managing canvases, managing users, uploadi…”
   • [claimed-docs] “Workspace admins can approve and manage all MCP client integrations, keeping your Slack data safe.”
   • [claimed-docs] “The Slack command-line interface (CLI) allows you to create and manage Slack apps from the command line.”
   • [claimed-docs] “This quickstart guide covers how to create a Slack app using the Slack CLI and the Bolt frameworks, in either Python or JavaScript.”
   • [claimed-docs] “Send data to or query data from Slack using any of more than 200 methods.”
   • [claimed-docs] “Official slackapi/slack-api-specs repo: "This repository contains API specifications of Slack platform features and APIs... You'll find Open…”
   • [probe] “official MCP server documented at https://docs.slack.dev/ai/slack-mcp-server/”
   • [probe] “official CLI documented at https://docs.slack.dev/tools/slack-cli/”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.slack.dev/openapi.json, https://docs.slack.dev/swagger.json, https://docs.slack.dev/api…”

   proof ↗⚑ flag

   Buzz~partialprobed6/10

   Buzz ships a documented CLI (buzz-cli commands for channels, repos, workflows, gifs) and an official MCP server for agent-driven hooks, plus agents get their own API keys/audit trails — all enabling AI-native programmatic control. However, probes show no formal public REST API docs (openapi.json/swagger 404, llms.txt 404), so there's no single canonical 'documented public API' surface, only CLI/MCP tooling. Missing for 10: a published OpenAPI/REST spec or llms.txt, and independent confirmation that agents actually use these interfaces successfully in production.

   • [claimed-docs] “buzz channels create --name "my-channel" --type stream --visibility open”
   • [claimed-docs] “buzz repos protect set --id my-repo --ref refs/heads/main --push admin --no-force-push --no-delete”
   • [claimed-docs] “buzz workflows trigger --workflow buzz workflows approve --token”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”
   • [probe] “PROBE llms.txt: HTTP 404 at https://buzz.xyz/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://buzz.xyz/openapi.json, https://buzz.xyz/swagger.json, https://buzz.xyz/api/openapi.json, htt…”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Slack~partialclaimed4/10

   Slack's API model implies scoped bot/user tokens (the OpenAPI spec notes 'user and bot user token usage of public Web API methods') and admin approval of MCP client integrations is described as keeping data safe, suggesting some governance over agent access, but there is no explicit documentation of an OAuth-scopes system or a user-facing flow to mint least-privilege credentials specifically for an agent. Missing for 10: explicit OAuth scope list/granularity docs, a documented workflow for a user to generate a scoped token for an agent, and any admin/user UI for restricting agent permissions beyond MCP client approval.

   • [claimed-docs] “Official slackapi/slack-api-specs repo: "This repository contains API specifications of Slack platform features and APIs... You'll find Open…”
   • [claimed-docs] “Workspace admins can approve and manage all MCP client integrations, keeping your Slack data safe.”
   • [claimed-docs] “A developer sandbox is an Enterprise org environment (a network of two or more Slack workspace instances) that can be used to build against …”

   proof ↗⚑ flag

   Buzz~partialcommunity4/10

   Buzz documents that each agent gets 'their own keys, their own channel memberships, and their own audit trail' (buzz-gh-4), implying some per-agent credential isolation, and CLI commands like `repos protect` show coarse-grained permission levels (buzz-docs-7). However there is no first-party documentation of a formal least-privilege API credential/scoping mechanism (e.g., issuing a key with defined capability sets), and community commentary raises concrete doubts about whether the permission model handles real-world scoping correctly (buzz-comm-3, buzz-comm-5, buzz-comm-6), though this is speculative critique rather than a confirmed hands-on failure. Missing for 10: explicit docs on scoped/limited-permission key issuance, examples of restricting an agent's API access to specific resources, and independent verification that the scoping works as intended.

   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [claimed-docs] “buzz repos protect set --id my-repo --ref refs/heads/main --push admin --no-force-push --no-delete”
   • [community] “A Slack employee argues multiplayer agents in Buzz risk leaking private data to teammates, requiring complex rulesets about resource access,…”
   • [community] “Commenter says Buzz uses channel-based scoping like humans would, but criticizes that it invented its own auth/permission protocol instead o…”
   • [community] “Critique of Buzz's group permission model: "These kinds of rules never survive real world tests. For example if I create a private group jus…”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to Slack
   Slack✓fullclaimed9/10

   Slack ships multiple official SDKs (Bolt for Java, node-slack-sdk, Deno Slack SDK), an official CLI, Web API with published OpenAPI spec, Events API, and Block Kit docs, all clearly documented as first-party developer tooling for building AI-native/agentic integrations, plus a developer sandbox for safe testing. Missing for 10: independent/hands-on developer corroboration beyond official docs and a fully discoverable OpenAPI endpoint (probe found candidate paths 404 despite spec repo existing).

   • [claimed-docs] “Bolt for Java is a framework on the JVM that offers an abstraction layer to build Slack apps using modern platform features.”
   • [claimed-docs] “Send data to or query data from Slack using any of more than 200 methods.”
   • [claimed-docs] “You can create Slack-hosted workflows written in TypeScript using the Deno Slack SDK.”
   • [claimed-docs] “The Slack command-line interface (CLI) allows you to create and manage Slack apps from the command line.”
   • [claimed-docs] “This quickstart guide covers how to create a Slack app using the Slack CLI and the Bolt frameworks, in either Python or JavaScript.”
   • [claimed-docs] “The Slack Web API is an interface for querying information from and enacting change in a Slack workspace.”
   • [claimed-docs] “The Slack Web API is an interface for querying information _from_ and enacting change _in_ a Slack workspace.”
   • [claimed-docs] “The Events API is a streamlined way to build apps and bots that respond to activities in Slack.”
   • [claimed-docs] “A developer sandbox is an Enterprise org environment (a network of two or more Slack workspace instances) that can be used to build against …”
   • [claimed-docs] “Official slackapi/slack-api-specs repo: "This repository contains API specifications of Slack platform features and APIs... You'll find Open…”
   • [claimed-docs] “Whether you're composing layouts for modals, messages, or tabs, the Block Kit building experience is the same — your app will be sculpting s…”

   proof ↗⚑ flag

   Buzz~partialprobed4/10

   Buzz ships a documented CLI (buzz-cli) and an MCP-driven hooks system that agents can call, and evidence notes agents have their own API keys — giving AI-native users some official programmatic surface. However, there is no evidence of a dedicated SDK library (Python/JS/etc.), and probes for an OpenAPI/swagger spec and llms.txt all returned 404, suggesting no formal SDK or API spec is published. Missing for 10: an actual SDK package/library, published API reference (OpenAPI/swagger), and independent confirmation of SDK usage by developers.

   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”
   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://buzz.xyz/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://buzz.xyz/openapi.json, https://buzz.xyz/swagger.json, https://buzz.xyz/api/openapi.json, htt…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Slack
   Slack✓fullclaimed8/10

   Slack's Events API lets developers subscribe to specific event types via webhook (public HTTP endpoint) or Socket Mode, with Slack calling the subscriber's endpoint on events — a core webhook-subscription mechanism well documented for building AI/agentic integrations. Workflow Builder also supports webhook triggers for starting workflows externally, reinforcing webhook-based event subscription. missing for 10: independent/hands-on corroboration of webhook reliability at scale, and more explicit framing of Events API webhooks specifically for AI-native/agent consumption (most AI-agent docs emphasize MCP/Web API rather than raw event webhooks).

   • [claimed-docs] “Subscribe to only the events you want; don't worry about the ones you don't need.”
   • [claimed-docs] “When you use the Events API, Slack calls you.”
   • [claimed-docs] “When you use the Events API, _Slack_ calls _you_. ... you can either use Socket Mode or you can designate a public HTTP endpoint”
   • [claimed-docs] “The Events API is a streamlined way to build apps and bots that respond to activities in Slack.”
   • [claimed-docs] “With the Events API, _Slack_ calls _you_.”
   • [claimed-docs] “Webhook triggers for workflows - How to start a workflow from outside of Slack.”
   • [claimed-docs] “Webhook triggers for workflows”

   proof ↗⚑ flag

   Buzz—none0/10

   No evidence of a webhook subscription mechanism; Buzz's architecture is built around Nostr-based signed events, CLI commands, and an MCP-driven hooks system, but nothing in the evidence pack mentions webhooks specifically for external event subscription. Missing for 10: any documentation of a webhook API, subscription endpoint, or event push mechanism.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Slack
   Slack✓fullclaimed7/10

   Slack ships built-in AI features (intelligent daily briefing, Slackbot summaries/recaps, channel/thread summarization, workspace-wide semantic search across integrated data, meeting notes from huddles) that surface AI-generated insights directly inside the product, per slack-docs-13/14/15/16/19/34/52. missing for 10: independent/hands-on verification of insight quality and accuracy, and detail on how suggestions are surfaced/actioned beyond marketing copy.

   • [claimed-docs] “Today is your new intelligent briefing that signals what needs your attention based on your priorities.”
   • [claimed-docs] “Slackbot is your personal AI agent in Slack that understands you and your workspace, helping you prepare for upcoming meetings, analyze repo…”
   • [claimed-docs] “AI in Slack can summarize channels and threads and serve up daily recaps, giving you the information you need to stay organized and in the k…”
   • [claimed-docs] “Conversations with coworkers, PDFs, images for your social campaign, decks buried in Google Drive, support tickets, customer records from Sa…”
   • [claimed-docs] “AI in Slack keeps you focused on the conversation by taking notes for you. Key takeaways, action items, and who said what are all neatly org…”
   • [claimed-docs] “AI in Slack keeps you focused on the conversation by taking notes for you. Key takeaways, action items, and who said what are all neatly org…”
   • [claimed-docs] “if it's shared in or integrated into Slack, it's searchable.”

   proof ↗⚑ flag

   Buzz~partialclaimed3/10

   Evidence shows agents can search history and 'post the threads, not vibes' and orchestrate workflows/reviews, implying some data-derived context surfacing, but there is no explicit documentation of dedicated AI-generated insights, summaries, or suggestion features surfaced to users. Missing for 10: dedicated insight/summary dashboards, proactive suggestion features, and independent confirmation that agents actually generate actionable insights rather than just retrieving raw history.

   • [github] “Agents search six months of history and post the threads, not vibes.”
   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [github] “Search the conversation, the patch, the workflow run, and the approval in one place”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Slack
   Slack✓fullclaimed7/10

   Slack's Workflow Builder lets users build no-code automations with triggers (including webhook triggers from outside Slack) and conditional branching that run autonomously in the background once configured, and the Events API/CLI/Bolt frameworks let developers build bots/apps that respond to activity without manual intervention. This directly satisfies the 'autonomous background automation' story for AI-native and non-technical users alike. missing for 10: independent/hands-on verification that these automations run reliably unattended over time, and explicit AI-agent-triggered automation examples beyond marketing copy

   • [claimed-docs] “Workflow Builder is a no-code way to build workflows, right in Slack. Any user can combine a limited set of steps and triggers to quickly se…”
   • [claimed-docs] “Webhook triggers for workflows - How to start a workflow from outside of Slack.”
   • [claimed-docs] “Add a branch to a workflow - How to add conditional branching that will present users with different options based on their interaction with…”
   • [claimed-docs] “Workflow Builder is a no-code way to build workflows, right in Slack.”
   • [claimed-docs] “Webhook triggers for workflows”
   • [claimed-docs] “Add a branch to a workflow”
   • [claimed-docs] “Subscribe to only the events you want; don't worry about the ones you don't need.”
   • [claimed-docs] “When you use the Events API, Slack calls you.”
   • [claimed-docs] “The Events API is a streamlined way to build apps and bots that respond to activities in Slack.”

   proof ↗⚑ flag

   Buzz~partialprobed6/10

   Buzz's docs show agents with their own keys/channels/audit trail, workflow-trigger CLI commands, and an MCP-driven-hooks system that lets agents act on events without direct human invocation, all pointing to autonomous background automation. However there is no first-party documentation of scheduling, persistence, or long-running unattended jobs, and no independent hands-on report confirming such automations work reliably in practice. Missing for 10: explicit scheduling/trigger-on-interval docs, independent verification of autonomous background runs, and detail on failure/retry handling.

   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [claimed-docs] “buzz workflows trigger --workflow buzz workflows approve --token”
   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Slack
   Slack✓fullclaimed7/10

   Slack ships Slackbot as a built-in AI agent that can summarize channels, prepare meeting briefs, analyze reports, answer open-ended questions, and act on tasks like updating deals or routing work to other agents (slack-docs-13,14,15,38,55,57,69). This is a native, in-product delegation capability, not just a third-party integration. Missing for 10: independent/hands-on user reports confirming Slackbot's agentic task delegation works as advertised, and more detail on the scope of actions it can autonomously perform beyond summarization/Q&A.

   • [claimed-docs] “Today is your new intelligent briefing that signals what needs your attention based on your priorities.”
   • [claimed-docs] “Slackbot is your personal AI agent in Slack that understands you and your workspace, helping you prepare for upcoming meetings, analyze repo…”
   • [claimed-docs] “AI in Slack can summarize channels and threads and serve up daily recaps, giving you the information you need to stay organized and in the k…”
   • [claimed-docs] “Update deals just by asking Slackbot”
   • [claimed-docs] “Slackbot can now dig deep on open-ended questions, not just quick ones.”
   • [claimed-docs] “Slackbot just got a full-screen workspace built for deeper work.”
   • [claimed-docs] “Route work through Slackbot. Coordinate work by routing requests to agents and get results delivered right back into your workflow.”

   proof ↗⚑ flag

   Buzz~partialprobed6/10

   Buzz's docs/GitHub describe agents as first-class participants that can open repos, send patches, review code, run workflows, and orchestrate other agents inside the product, and it ships MCP-driven hooks for agent integration (buzz-gh-2, buzz-gh-4, buzz-probe-3). However this is framed as a multi-agent chat/dev platform where external agents join with their own keys, rather than a single dedicated 'built-in assistant' persona users delegate to by default. Missing for 10: a documented default/first-party assistant persona, evidence of a simple task-delegation UX (vs. general agent orchestration infrastructure), and independent hands-on confirmation that delegation works reliably (community threads mostly debate permissions/architecture, not task delegation itself).

   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”
   • [github] “Agents search six months of history and post the threads, not vibes.”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Slack
   Slack✓fullclaimed7/10

   Slack ships Slackbot as an in-product AI agent that responds to natural-language requests (e.g., 'Update deals just by asking Slackbot', daily briefings, summarization, open-ended Q&A) and exposes an official MCP server so AI assistants can search, message, and manage Slack objects via natural language. This directly supports NL-command operation for AI-native users. missing for 10: independent/hands-on validation of Slackbot NL command accuracy and reliability, and clearer documentation of the scope/limits of what natural-language commands can trigger (vs. workflow builder's no-code but still menu-driven automations).

   • [claimed-docs] “Today is your new intelligent briefing that signals what needs your attention based on your priorities.”
   • [claimed-docs] “Slackbot is your personal AI agent in Slack that understands you and your workspace, helping you prepare for upcoming meetings, analyze repo…”
   • [claimed-docs] “AI in Slack can summarize channels and threads and serve up daily recaps, giving you the information you need to stay organized and in the k…”
   • [claimed-docs] “Update deals just by asking Slackbot”
   • [claimed-docs] “Slackbot can now dig deep on open-ended questions, not just quick ones.”
   • [claimed-docs] “Slackbot just got a full-screen workspace built for deeper work.”
   • [claimed-docs] “AI agents can now read, write, and manage your Slack Lists directly.”
   • [claimed-docs] “Once connected, your AI assistant can search channels, read messages, and use real conversation context to help you build.”
   • [claimed-docs] “your integrated apps can search channels, send messages, and perform other Slack actions through MCP clients”
   • [claimed-docs] “The Slack MCP server provides tools for searching through Slack, retrieving and sending messages, managing canvases, managing users, uploadi…”

   proof ↗⚑ flag

   Buzz~partialprobed5/10

   Buzz is agent-native chat where agents interact via structured commands, channels, and an MCP/CLI interface (buzz-gh-2, buzz-probe-3, buzz-docs-5/7/8), but the CLI commands shown are structured flags/subcommands rather than natural-language input, and there's no evidence of a conversational NL interface for operating the product. missing for 10: documentation or demo of actual natural-language command parsing/interpretation (vs. structured CLI/MCP calls), independent confirmation that NL commands work in practice.

   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [claimed-docs] “buzz channels create --name "my-channel" --type stream --visibility open”
   • [claimed-docs] “buzz repos protect set --id my-repo --ref refs/heads/main --push admin --no-force-push --no-delete”
   • [claimed-docs] “buzz workflows trigger --workflow buzz workflows approve --token”
   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Slack—none0/10

   Slack has API method reference docs (e.g. chat.postMessage) and an OpenAPI/AsyncAPI spec repo, but there is no evidence of an interactive, runnable API reference (e.g. a Swagger/try-it console); a direct probe for openapi.json/swagger.json on the docs site returned 404s, indicating no in-browser interactive reference exists.

   • [claimed-docs] “Sends a message to a channel.”
   • [claimed-docs] “Official slackapi/slack-api-specs repo: "This repository contains API specifications of Slack platform features and APIs... You'll find Open…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.slack.dev/openapi.json, https://docs.slack.dev/swagger.json, https://docs.slack.dev/api…”

   proof ↗⚑ flag

   Buzz—none0/10

   There is no evidence of an interactive API reference or runnable examples; the probe explicitly found no OpenAPI/Swagger spec and no llms.txt at Buzz's domain. Only a CLI and MCP hooks documentation exist, which do not constitute an interactive API reference with runnable examples. Missing for 10: any API reference site, OpenAPI/Swagger spec, or interactive/runnable example sandbox.

   • [probe] “PROBE llms.txt: HTTP 404 at https://buzz.xyz/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://buzz.xyz/openapi.json, https://buzz.xyz/swagger.json, https://buzz.xyz/api/openapi.json, htt…”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Slack
   Slack~partialprobed6/10

   An official OpenAPI 2.0 spec for the Web API (and AsyncAPI spec for Events API) exists in the slackapi/slack-api-specs GitHub repo, satisfying the core ask of a machine-readable spec. However, live probes show the obvious/expected locations on docs.slack.dev (openapi.json, swagger.json, etc.) all 404, meaning the spec isn't directly downloadable from the primary docs site and requires knowing about a separate GitHub repo. Missing for 10: direct download link from docs.slack.dev, first-party documentation pointing users to the spec repo, and independent confirmation the spec is kept in sync with the live API.

   • [claimed-docs] “Official slackapi/slack-api-specs repo: "This repository contains API specifications of Slack platform features and APIs... You'll find Open…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.slack.dev/openapi.json, https://docs.slack.dev/swagger.json, https://docs.slack.dev/api…”
   • [claimed-docs] “The Slack Web API is an interface for querying information from and enacting change in a Slack workspace.”
   • [claimed-docs] “The Slack Web API is an interface for querying information _from_ and enacting change _in_ a Slack workspace.”

   proof ↗⚑ flag

   Buzz—none0/10

   Direct probes for OpenAPI/swagger specs and llms.txt all returned 404, and no evidence pack item mentions a downloadable API spec; only a CLI and MCP hooks are documented.

   • [probe] “PROBE llms.txt: HTTP 404 at https://buzz.xyz/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://buzz.xyz/openapi.json, https://buzz.xyz/swagger.json, https://buzz.xyz/api/openapi.json, htt…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Slack
   Slack✓fullclaimed7/10

   Slack's official docs describe a 'developer sandbox' as an Enterprise org environment explicitly built to let developers 'build against all Slack features safely and securely' and 'empower teams to build without putting production at risk,' directly matching the story of testing without touching production data. However, missing for 10: independent/hands-on confirmation of the sandbox in use, clarity on whether this is available outside Enterprise plans, and detail on how it isolates AI/agent-specific testing (e.g., MCP server or bot testing) within that sandbox.

   • [claimed-docs] “A developer sandbox is an Enterprise org environment (a network of two or more Slack workspace instances) that can be used to build against …”
   • [claimed-docs] “Empower teams to build without putting production at risk”

   proof ↗⚑ flag

   Buzz—none0/10

   No evidence in the pack describes a sandbox/staging environment or test mode distinct from production data; Buzz's evidence focuses on chat rooms, channels, code review, and agent orchestration, not on data isolation for testing.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Slack
   Slack~partialclaimed6/10

   Slack maintains official OpenAPI specs for its Web API and a dated, running deprecation changelog with explicit migration windows (e.g., classic app deprecation date), which supports documented deprecation policy; the Web API and Events API references also show first-party API documentation. However, there's no explicit evidence of a formal API versioning scheme (e.g., v1/v2 endpoint versioning) beyond method-level docs and changelog dates. Missing for 10: explicit versioning scheme documentation, independent/community corroboration of deprecation practices being honored reliably.

   • [claimed-docs] “Official slackapi/slack-api-specs repo: "This repository contains API specifications of Slack platform features and APIs... You'll find Open…”
   • [claimed-docs] “api.slack.com/changelog/deprecations is a running, dated log of API deprecation announcements with migration windows, e.g. "We'd like to upd…”
   • [claimed-docs] “The Slack Web API is an interface for querying information from and enacting change in a Slack workspace.”
   • [claimed-docs] “The Slack Web API is an interface for querying information _from_ and enacting change _in_ a Slack workspace.”

   proof ↗⚑ flag

   Buzz—none0/10

   No evidence of API versioning or a documented deprecation policy; openapi probes returned 404 and no changelog/versioning docs are cited. Missing for 10: versioned API docs, deprecation policy documentation, changelog or stability guarantees.

   • [probe] “PROBE openapi: all candidate paths 404 (https://buzz.xyz/openapi.json, https://buzz.xyz/swagger.json, https://buzz.xyz/api/openapi.json, htt…”

   proof ↗⚑ flag

Apps

1. team-adminInstall prebuilt integrations from an app directory or marketplace

   weight 3 · round to Slack
   Slack✓fullclaimed8/10

   Slack explicitly advertises an App Directory with 2,600+ prebuilt apps (Salesforce, Jira, Google Drive, ChatGPT, etc.) and a help doc specifically for admins on how to add apps to a workspace. This directly matches the team-admin persona and app-platform theme. missing for 10: independent/hands-on confirmation of the admin install/approval workflow beyond the docs, and no detail on admin-specific approval controls for directory apps (only MCP client approval is mentioned).

   • [claimed-docs] “Choose from over 2,600 apps in the Slack App Directory — from Salesforce, Jira, Google Drive, ChatGPT, and more.”
   • [claimed-docs] “Add apps to your Slack workspace”
   • [claimed-docs] “Connect, simplify, and automate. Discover the power of apps and tools.”

   proof ↗⚑ flag

   Buzz—none0/10

   No evidence of an app directory or marketplace for prebuilt integrations that a team-admin could browse and install; Buzz's evidence covers CLI commands, agent orchestration, MCP hooks, and chat/dev workflows but nothing about an installable integrations marketplace. Missing for 10: any mention of an app directory, marketplace listing, or one-click integration install flow.

   ⚑ flag

2. developerRegister custom slash commands that users invoke from the message box

   weight 2 · round drawn
   Slack—none0/10

   The evidence pack covers Slack's general app-platform tooling (CLI, Bolt frameworks, Web/Events APIs, Block Kit, Workflow Builder, MCP server) but never mentions slash commands specifically as a registrable app feature invoked from the message box.

   ⚑ flag

   Buzz—none0/10

   No evidence of a slash-command registration API or SDK for developers to add custom commands invoked from the message box; evidence only covers CLI usage, channels, workflows, and MCP hooks. missing for 10: slash command registration API/SDK, documentation of command syntax, examples of third-party commands appearing in the message box.

   ⚑ flag

3. developerBuild apps with rich interactive UI inside chat — modals, buttons, and structured message layouts

   weight 2 · round to Slack
   Slack✓fullclaimed9/10

   Slack's Block Kit is explicitly documented as the JSON-based framework for building modals, messages, and tabs with the same building blocks, backed by chat.postMessage's structured 'blocks' parameter, plus SDKs (Bolt for Java/Python/JS, Node Slack SDK) and CLI tooling to build these apps. This directly matches the story of building rich interactive UI (modals, buttons, structured layouts) inside Slack chat. Missing for 10: no independent/hands-on developer corroboration of the Block Kit UI-building experience beyond first-party docs.

   • [claimed-docs] “Whether you're composing layouts for modals, messages, or tabs, the Block Kit building experience is the same — your app will be sculpting s…”
   • [claimed-docs] “A JSON-based array of structured blocks, presented as a URL-encoded string.”
   • [claimed-docs] “Sends a message to a channel.”
   • [claimed-docs] “This quickstart guide covers how to create a Slack app using the Slack CLI and the Bolt frameworks, in either Python or JavaScript.”
   • [claimed-docs] “Bolt for Java is a framework on the JVM that offers an abstraction layer to build Slack apps using modern platform features.”
   • [claimed-docs] “Send data to or query data from Slack using any of more than 200 methods.”
   • [claimed-docs] “The Slack command-line interface (CLI) allows you to create and manage Slack apps from the command line.”

   proof ↗⚑ flag

   Buzz—none0/10

   Evidence shows Buzz as a chat/collaboration platform with channels, canvases, CLI, and agent integration, but there is no mention of a developer-facing SDK or API for building interactive UI elements like modals, buttons, or structured message layouts inside chat — this is a distinct app-platform capability (like Slack's Block Kit) that is not documented anywhere in the pack. Missing for 10: any API/SDK for interactive components, modal/button primitives, message-layout builder documentation.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Slack—none0/10

   Slack's Web API and MCP server document single-item actions (send one message, upload one file, create one list entry, etc.) with no documented batch/bulk endpoints or MCP tools for operating across many items in one call. Workflow Builder and automations are trigger-based, not bulk-operation mechanisms, and export tools are admin-only data dumps rather than AI-native bulk actions.

   ⚑ flag

   Buzz—none0/10

   Evidence shows CLI/agent commands operating on single items (one channel, one repo, one workflow) but no documented bulk/batch operations across many items at once; no evidence of scripting loops, batch APIs, or multi-item commands.

   • [claimed-docs] “buzz channels create --name "my-channel" --type stream --visibility open”
   • [claimed-docs] “buzz repos protect set --id my-repo --ref refs/heads/main --push admin --no-force-push --no-delete”
   • [claimed-docs] “buzz workflows trigger --workflow buzz workflows approve --token”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Slack
   Slack✓fullclaimed8/10

   Slack's Workflow Builder lets users define triggers, conditional branches, and webhook-based automations that fire actions on events (message posted, emoji reaction, webhook call, etc.), directly matching the story; the Events API further supports event-driven automation. missing for 10: independent/hands-on verification of workflow trigger reliability and no evidence of AI-native rule authoring beyond no-code builder.

   • [claimed-docs] “Workflow Builder is a no-code way to build workflows, right in Slack. Any user can combine a limited set of steps and triggers to quickly se…”
   • [claimed-docs] “Webhook triggers for workflows - How to start a workflow from outside of Slack.”
   • [claimed-docs] “Add a branch to a workflow - How to add conditional branching that will present users with different options based on their interaction with…”
   • [claimed-docs] “Webhook triggers for workflows”
   • [claimed-docs] “Add a branch to a workflow”
   • [claimed-docs] “Subscribe to only the events you want; don't worry about the ones you don't need.”
   • [claimed-docs] “When you use the Events API, Slack calls you.”
   • [claimed-docs] “The Events API is a streamlined way to build apps and bots that respond to activities in Slack.”

   proof ↗⚑ flag

   Buzz~partialprobed5/10

   Buzz documents workflow triggers (buzz-docs-8) and a dedicated 'MCP-driven hooks' doc (buzz-probe-3) implying event-based automation tied to agent actions, but there is no detailed spec of rule syntax, supported event types, or conditions, and no independent confirmation of reliability. missing for 10: full rule-definition schema/docs, breadth of triggerable events, hands-on/independent verification that hooks fire reliably.

   • [claimed-docs] “buzz workflows trigger --workflow buzz workflows approve --token”
   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Slack
   Slack~partialclaimed4/10

   Slack's Workflow Builder is documented as a no-code automation tool with webhook triggers and conditional branching, which are automation-depth building blocks, but the evidence never explicitly mentions a 'scheduled' or 'recurring' trigger type for jobs/workflows. AI-native automation is described mostly around single-shot chat/AI features (summaries, briefings) rather than recurring job scheduling. missing for 10: explicit documentation of scheduled/recurring trigger type in Workflow Builder, independent confirmation of recurring automation use, and any AI-agent-specific recurring job scheduling capability.

   • [claimed-docs] “Workflow Builder is a no-code way to build workflows, right in Slack. Any user can combine a limited set of steps and triggers to quickly se…”
   • [claimed-docs] “Webhook triggers for workflows - How to start a workflow from outside of Slack.”
   • [claimed-docs] “Add a branch to a workflow - How to add conditional branching that will present users with different options based on their interaction with…”
   • [claimed-docs] “Workflow Builder is a no-code way to build workflows, right in Slack.”
   • [claimed-docs] “Webhook triggers for workflows”
   • [claimed-docs] “Add a branch to a workflow”

   proof ↗⚑ flag

   Buzz—none0/10

   No evidence of any scheduling/cron/recurring-trigger capability in Buzz — workflows can be triggered manually or via CLI/MCP hooks, but nothing documents recurring or time-based scheduling. Missing for 10: any docs/CLI command for cron-style or recurring job scheduling, evidence of scheduled workflow runs.

   ⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Buzz
   Slack—none0/10

   The evidence covers Workflow Builder's creation, branching, and webhook triggers, but nothing describes version history, change review, or rollback capabilities for workflows/automations built in Slack. The axis is applicable (automation platforms commonly offer versioning/rollback) but no supporting evidence exists.

   • [claimed-docs] “Workflow Builder is a no-code way to build workflows, right in Slack. Any user can combine a limited set of steps and triggers to quickly se…”
   • [claimed-docs] “Webhook triggers for workflows - How to start a workflow from outside of Slack.”
   • [claimed-docs] “Add a branch to a workflow - How to add conditional branching that will present users with different options based on their interaction with…”
   • [claimed-docs] “Workflow Builder is a no-code way to build workflows, right in Slack.”
   • [claimed-docs] “Webhook triggers for workflows”
   • [claimed-docs] “Add a branch to a workflow”

   proof ↗⚑ flag

   Buzz~partialclaimed5/10

   Buzz's core model treats automations as git-style patches with review and merge decisions baked into the channel (buzz-gh-1, buzz-gh-5), and the CLI exposes workflow trigger/approve commands (buzz-docs-8) plus repo protection rules (buzz-docs-7), giving some versioning and review capability for automation-like workflows. However, there is no explicit evidence of a 'rollback' mechanism for workflows/automations specifically, nor of automation-specific version history beyond generic git patch review. Missing for 10: explicit rollback/undo functionality for workflows, and dedicated versioning UI/CLI for automations distinct from general code patches.

   • [github] “Turn a feature branch into a room where patches, CI, review, and the merge decision live together — so the channel becomes the record of why…”
   • [github] “Search the conversation, the patch, the workflow run, and the approval in one place”
   • [claimed-docs] “buzz repos protect set --id my-repo --ref refs/heads/main --push admin --no-force-push --no-delete”
   • [claimed-docs] “buzz workflows trigger --workflow buzz workflows approve --token”

   proof ↗⚑ flag

Ai agents

1. ai-native userAdd an AI agent as a member of a channel that participates in conversations when mentioned

   weight 3 · round drawn
   Slack✓fullclaimed7/10

   Slack's Events API lets bots/apps respond to activity in channels ('Slack calls you'), and its ecosystem explicitly supports adding AI agents like ChatGPT, Claude, and Slackbot as channel-integrated participants that act on mentions/requests (e.g. 'start using tools like ChatGPT, Claude... within your chats', 'Route work through Slackbot... routing requests to agents', 'Coding agents can now work with your whole team'). Combined with the CLI/Bolt SDKs for building bot apps that join channels, this shows the underlying capability is well supported. Missing for 10: explicit first-party documentation of the app_mention event/scope specifically triggering agent responses, and independent hands-on confirmation that a mentioned agent reliably replies in-channel.

   • [claimed-docs] “The Events API is a streamlined way to build apps and bots that respond to activities in Slack.”
   • [claimed-docs] “When you use the Events API, Slack calls you.”
   • [claimed-docs] “With the Events API, _Slack_ calls _you_.”
   • [claimed-docs] “Slackbot is your personal AI agent in Slack that understands you and your workspace, helping you prepare for upcoming meetings, analyze repo…”
   • [claimed-docs] “Coding agents can now work with your whole team, not just you.”
   • [claimed-docs] “Route work through Slackbot. Coordinate work by routing requests to agents and get results delivered right back into your workflow.”
   • [claimed-docs] “Easily connect agents, software, and all your apps in just a few clicks, and start using tools like ChatGPT, Claude, and Asana right within …”
   • [claimed-docs] “By connecting them to your conversations and data in Slack, agents like Agentforce, ChatGPT, Claude, Notion, Slackbot, and Writer become eve…”
   • [claimed-docs] “The Slack command-line interface (CLI) allows you to create and manage Slack apps from the command line.”
   • [claimed-docs] “This quickstart guide covers how to create a Slack app using the Slack CLI and the Bolt frameworks, in either Python or JavaScript.”

   proof ↗⚑ flag

   Buzz✓fullcommunity7/10

   Buzz's core design explicitly gives agents their own channel memberships, keys, and audit trail, and describes agents participating in channel conversations (searching history, posting threads, orchestrating other agents) — directly matching the story of adding an AI agent as a channel member that engages when mentioned. However, there's no explicit documentation of an '@mention triggers agent response' mechanism, and community commentary treats it simply as 'bots in chat rooms' without confirming mention-based triggering specifics. Missing for 10: explicit documentation of mention-triggered activation, independent hands-on confirmation of this exact UX flow.

   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [github] “Agents search six months of history and post the threads, not vibes.”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [community] “"Marketing bullshit aside, this is just bots in chat rooms, right? Am I the crazy one?"”

   proof ↗⚑ flag

2. ai-native userHave an agent read and post channel messages through the official API using scoped tokens

   weight 3 · round to Slack
   Slack✓fullclaimed8/10

   Slack's official Web API (chat.postMessage, chat.history-type methods via OpenAPI spec covering user/bot token usage) plus scoped OAuth tokens is well documented, enabling agents to read and post channel messages programmatically; the MCP server and SDKs (Bolt, node-slack-sdk) further formalize agent access with admin-approved scopes. missing for 10: no independent hands-on developer report confirming real-world token-scoping friction or reliability at scale, and no explicit doc excerpt enumerating channel-read scopes (e.g., channels:history) alongside chat:write in one place.

   • [claimed-docs] “The Slack Web API is an interface for querying information from and enacting change in a Slack workspace.”
   • [claimed-docs] “The Slack Web API is an interface for querying information _from_ and enacting change _in_ a Slack workspace.”
   • [claimed-docs] “Sends a message to a channel.”
   • [claimed-docs] “Official slackapi/slack-api-specs repo: "This repository contains API specifications of Slack platform features and APIs... You'll find Open…”
   • [claimed-docs] “your integrated apps can search channels, send messages, and perform other Slack actions through MCP clients”
   • [claimed-docs] “The Slack MCP server provides tools for searching through Slack, retrieving and sending messages, managing canvases, managing users, uploadi…”
   • [claimed-docs] “Workspace admins can approve and manage all MCP client integrations, keeping your Slack data safe.”
   • [claimed-docs] “Send data to or query data from Slack using any of more than 200 methods.”

   proof ↗⚑ flag

   Buzz~partialprobed6/10

   Buzz is explicitly agent-first: agents have their own keys, channel memberships, and audit trails, can search history and post threads, and there's a documented CLI and MCP server for programmatic interaction. However, no OpenAPI/API spec was found (404s on all probed endpoints), and no explicit documentation of 'scoped tokens' for API access was cited, so the 'official API with scoped tokens' framing is only partially evidenced. missing for 10: explicit scoped-token/auth-scope documentation, a discoverable official REST/HTTP API spec (openapi.json returned 404).

   • [github] “Agents search six months of history and post the threads, not vibes.”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [claimed-docs] “buzz channels create --name "my-channel" --type stream --visibility open”
   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://buzz.xyz/openapi.json, https://buzz.xyz/swagger.json, https://buzz.xyz/api/openapi.json, htt…”

   proof ↗⚑ flag

Bot api

1. developerPost a message into a channel with a simple incoming webhook URL

   weight 2 · round to Slack
   Slack~partialclaimed5/10

   Slack's docs evidence shows webhook-based triggers for Workflow Builder ("how to start a workflow from outside of Slack") and the chat.postMessage Web API method for sending messages, both of which can be used to post into a channel from an external system, but neither is the classic single-URL 'Incoming Webhook' integration developers commonly expect. Missing for 10: explicit documentation of the dedicated Incoming Webhooks app/URL for zero-config posting, and any hands-on confirmation that a bare webhook POST (without workflow setup or OAuth token) posts a message.

   • [claimed-docs] “Webhook triggers for workflows - How to start a workflow from outside of Slack.”
   • [claimed-docs] “Webhook triggers for workflows”
   • [claimed-docs] “Sends a message to a channel.”
   • [claimed-docs] “The Slack Web API is an interface for querying information from and enacting change in a Slack workspace.”

   proof ↗⚑ flag

   Buzz—none0/10

   No evidence of a simple incoming webhook URL feature for posting messages; Buzz's integration surface described is CLI commands, agent keys/channel membership, and MCP hooks, not a plug-and-play webhook URL. Missing for 10: any documentation of a webhook endpoint, webhook URL generation, or simple HTTP POST-to-channel mechanism.

   • [claimed-docs] “buzz channels create --name "my-channel" --type stream --visibility open”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”

   proof ↗⚑ flag

2. developerBuild a bot that receives messages and events in real time through an events API or gateway connection

   weight 3 · round to Slack
   Slack✓fullclaimed9/10

   Slack's Events API is explicitly documented to push real-time events to developer-built apps/bots via HTTP endpoint or Socket Mode, with subscription filtering, and this is complemented by SDKs (Bolt for Java, Node SDK) and quickstart guides for building bots. Missing for 10: independent hands-on developer corroboration of reliability/latency of the events pipeline beyond first-party docs.

   • [claimed-docs] “Subscribe to only the events you want; don't worry about the ones you don't need.”
   • [claimed-docs] “When you use the Events API, Slack calls you.”
   • [claimed-docs] “When you use the Events API, _Slack_ calls _you_. ... you can either use Socket Mode or you can designate a public HTTP endpoint”
   • [claimed-docs] “The Events API is a streamlined way to build apps and bots that respond to activities in Slack.”
   • [claimed-docs] “With the Events API, _Slack_ calls _you_.”
   • [claimed-docs] “Bolt for Java is a framework on the JVM that offers an abstraction layer to build Slack apps using modern platform features.”
   • [claimed-docs] “Send data to or query data from Slack using any of more than 200 methods.”
   • [claimed-docs] “This quickstart guide covers how to create a Slack app using the Slack CLI and the Bolt frameworks, in either Python or JavaScript.”

   proof ↗⚑ flag

   Buzz~partialprobed5/10

   Buzz's architecture gives agents their own keys, channel memberships, and audit trails, and documents MCP-driven hooks for agent integration, implying some event-driven mechanism for bots to react to chat activity. However, there is no explicit documentation of a formal events API, WebSocket/gateway protocol, or real-time subscription model comparable to Slack's Events API, and probes for openapi/llms.txt returned 404s. Missing for 10: explicit gateway/WebSocket protocol docs, formal events API reference, and independent confirmation that bots receive events in real time.

   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [probe] “official MCP server documented at https://raw.githubusercontent.com/block/buzz/main/docs/MCP_DRIVEN_HOOKS.md”
   • [probe] “PROBE llms.txt: HTTP 404 at https://buzz.xyz/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://buzz.xyz/openapi.json, https://buzz.xyz/swagger.json, https://buzz.xyz/api/openapi.json, htt…”

   proof ↗⚑ flag

Ai notes

1. ai-native userGet AI-generated notes and recaps from meetings and huddles I attended or missed

   weight 2 · round to Slack
   Slack✓fullclaimed8/10

   Slack's docs directly claim AI note-taking for huddles (key takeaways, action items, who said what compiled at huddle end) and AI-generated channel/thread summaries and daily recaps for content missed, matching the story's core ask. Missing for 10: independent/hands-on corroboration of huddle-note accuracy or completeness, and no explicit confirmation that recaps cover 'missed' meetings specifically (recaps are framed around channels/threads more than scheduled meetings).

   • [claimed-docs] “AI in Slack keeps you focused on the conversation by taking notes for you. Key takeaways, action items, and who said what are all neatly org…”
   • [claimed-docs] “AI in Slack keeps you focused on the conversation by taking notes for you. Key takeaways, action items, and who said what are all neatly org…”
   • [claimed-docs] “AI in Slack can summarize channels and threads and serve up daily recaps, giving you the information you need to stay organized and in the k…”
   • [claimed-docs] “Create time-saving automations in a few clicks, translate conversations into any language, and even use AI to take meeting notes.”
   • [claimed-docs] “translate conversations into any language, and even use AI to take meeting notes”
   • [claimed-docs] “If it's shared in a huddle, it's saved in Slack. Any links, documents, and messages shared during a huddle are automatically saved once the …”
   • [claimed-docs] “If it's shared in a huddle, it's saved in Slack.”

   proof ↗⚑ flag

   Buzz—none0/10

   Buzz's evidence covers voice huddles, channels, agent search of history, and repo/workflow features, but there is no mention of AI-generated meeting notes, recaps, or summaries for huddles attended or missed. Missing for 10: any documentation of automatic meeting/huddle transcription or summary generation, evidence of a recap feature for missed huddles.

   ⚑ flag

Calls

1. team-adminStart an audio or video call directly from a channel or DM without leaving the app

   weight 3 · round to Slack
   Slack✓fullclaimed8/10

   Slack's Huddles feature lets any user click the headphones icon in a channel/DM header to instantly start audio or video calls with screen sharing, all inside the app, and includes admin-manageable extras like AI notes and saved shared content. missing for 10: no explicit documentation of admin-specific controls/permissions for enabling or restricting huddles, and no independent hands-on corroboration beyond Slack's own marketing docs.

   • [claimed-docs] “Simply click on the headphones icon in the conversation header to start a huddle with your team.”
   • [claimed-docs] “Huddles happen right in Slack. Instantly connect over audio or video and share screens so you can get more done where you're already working…”
   • [claimed-docs] “Bring the feeling of working side-by-side to a virtual space that lets you collaborate and co-create live.”
   • [claimed-docs] “AI in Slack keeps you focused on the conversation by taking notes for you. Key takeaways, action items, and who said what are all neatly org…”
   • [claimed-docs] “If it's shared in a huddle, it's saved in Slack. Any links, documents, and messages shared during a huddle are automatically saved once the …”
   • [claimed-docs] “Emoji reactions. Colorful backgrounds. Delightful effects. In huddles, teams can express themselves to make being together even better.”

   proof ↗⚑ flag

   Buzz~partialclaimed4/10

   Evidence mentions 'drop into voice huddles' as a feature (buzz-gh-2), suggesting audio/video calling exists within the app, but there is no documentation on how to initiate a call from a channel/DM, no UI walkthrough, and no independent confirmation it works as described. Missing for 10: dedicated call-initiation documentation, admin-specific controls, video call evidence beyond a single passing mention, and hands-on/community confirmation of the feature working.

   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”

   proof ↗⚑ flag

2. team-adminShare my screen during a call for live collaboration

   weight 2 · round to Slack
   Slack✓fullclaimed7/10

   Slack huddles explicitly support instant audio/video connection with screen sharing directly in the conversation, usable by any team member including admins, per first-party docs (slack-docs-33, slack-docs-66, slack-docs-18). However, missing for 10: independent/hands-on corroboration of screen-share quality or reliability, and no explicit admin-specific controls or documentation around screen sharing during calls beyond the general huddles feature description.

   • [claimed-docs] “Huddles happen right in Slack. Instantly connect over audio or video and share screens so you can get more done where you're already working…”
   • [claimed-docs] “Huddles happen right in Slack. Instantly connect over audio or video and share screens so you can get more done where you’re already working…”
   • [claimed-docs] “Simply click on the headphones icon in the conversation header to start a huddle with your team.”
   • [claimed-docs] “Bring the feeling of working side-by-side to a virtual space that lets you collaborate and co-create live.”

   proof ↗⚑ flag

   Buzz—none0/10

   Buzz documents voice huddles (buzz-gh-2) and video-with-comments features (buzz-docs-3), but no evidence anywhere describes screen sharing during a call. Missing for 10: any mention of screen-share functionality, UI, or CLI command for sharing a screen in a huddle.

   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [claimed-docs] “A video playing in Buzz with frame-anchored comments in a side panel”

   proof ↗⚑ flag

External collaboration

1. team-adminCollaborate with external partners through guest accounts or shared channels with limited access

   weight 2 · round drawn
   Slack—none0/10

   The evidence pack contains no mention of guest accounts, Slack Connect, or shared/external channels with limited access — nothing about admin controls for external collaboration appears anywhere in the docs, community, or probe items. This is a mainstream, applicable capability for a workspace chat product, but absence of evidence means it cannot be credited.

   ⚑ flag

   Buzz—none0/10

   Evidence covers channel creation, visibility settings, and agent-specific permissions, but nothing describes guest accounts for external partners or a limited-access sharing model for outside collaborators. Missing for 10: guest account mechanism, external-partner access controls, documentation of restricted/limited-access collaboration for non-org members.

   ⚑ flag

Messaging model

1. team-adminOrganize conversations into public and private channels with membership controls

   weight 3 · round to Buzz
   Slack—none0/10

   The evidence pack focuses almost entirely on Slack's AI/MCP tooling, developer SDKs, huddles, and integrations, with no first-party documentation describing channel creation, public vs. private channel types, or admin membership controls. The only channel-related mentions (e.g., MCP 'search channels', a raw SEO keyword list) do not document this admin capability.

   ⚑ flag

   Buzz~partialcommunity6/10

   Buzz supports creating channels/rooms with a visibility flag ('make it private', CLI --visibility open) and per-agent/user channel memberships, indicating basic public/private organization with membership. However, evidence for granular admin membership controls (e.g., invite management, role-based permissions, moderation) is thin, and community critique raises concrete doubts about the robustness of its custom permission model in real-world edge cases (e.g., auto-invite conflicts). missing for 10: detailed admin UI/CLI for managing membership/invites, documented role-based access control, independent verification that private channels reliably restrict access.

   • [claimed-docs] “Spin up a room in seconds. Name it, describe it, make it private.”
   • [claimed-docs] “buzz channels create --name "my-channel" --type stream --visibility open”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [community] “Commenter says Buzz uses channel-based scoping like humans would, but criticizes that it invented its own auth/permission protocol instead o…”
   • [community] “Critique of Buzz's group permission model: "These kinds of rules never survive real world tests. For example if I create a private group jus…”

   proof ↗⚑ flag

2. team-adminReply in threads so side discussions stay attached to the original message

   weight 3 · round to Slack
   Slack~partialcommunity3/10

   No first-party Slack documentation in this evidence pack describes the threading/reply feature directly; the only evidence that threads exist comes from community complaints (comm-12, comm-14) confirming the feature is used but describing it as poorly notified, hard to find replies, and 'close to impossible to use' as a tiny side panel with missing capabilities (snippets/files/slash commands not working in threads). This suggests threads function but with real UX friction, not a clean full delivery. Missing for 10: official docs/screenshots describing thread-reply UX, independent confirmation that reply notifications and thread views work smoothly, and resolution of the cited usability complaints.

   • [community] “My biggest pain point is Slack's awful implementation of threads - you only get notified of new thread replies in a 'New Threads' view that …”
   • [community] “Zulip is a very good fit for open source communities, and much much better for communication than Slack. Slack encourages saying everything …”

   proof ↗⚑ flag

   Buzz—none0/10

   The evidence pack describes channels, search across conversations, and agent chat rooms, but no documentation or feature mentions threaded replies to keep side discussions attached to an original message. missing for 10: any mention of a reply/thread UI or API, docs on thread creation, or community confirmation of threading behavior.

   ⚑ flag

3. team-adminCatch up on busy channels efficiently because every conversation is organized under a named topic or thread

   weight 2 · round to Buzz
   Slack!disputedcontradicted5/10

   Slack does support channel/thread organization plus AI features to summarize channels and threads for catching up (slack-docs-15, slack-docs-19, slack-docs-34), but concrete hands-on community reports say the thread implementation itself is poorly organized and hard to use — notifications don't auto-update, threads are 'a tiny section off to the side,' and Slack 'encourages saying everything in the main channel' rather than threads (slack-comm-12, slack-comm-14). This directly contradicts the premise that conversations are cleanly organized under threads for efficient catch-up. Missing for 10: independent verification that threading/summarization actually resolves the catch-up problem in practice, admin-specific tooling for enforcing thread discipline.

   • [claimed-docs] “AI in Slack can summarize channels and threads and serve up daily recaps, giving you the information you need to stay organized and in the k…”
   • [claimed-docs] “AI in Slack keeps you focused on the conversation by taking notes for you. Key takeaways, action items, and who said what are all neatly org…”
   • [claimed-docs] “AI in Slack keeps you focused on the conversation by taking notes for you. Key takeaways, action items, and who said what are all neatly org…”
   • [community] “My biggest pain point is Slack's awful implementation of threads - you only get notified of new thread replies in a 'New Threads' view that …”
   • [community] “Zulip is a very good fit for open source communities, and much much better for communication than Slack. Slack encourages saying everything …”

   proof ↗⚑ flag

   Buzz~partialclaimed7/10

   Buzz documents named rooms/channels created per feature or topic (buzz-docs-4, buzz-docs-5) and shows agents searching and posting 'threads, not vibes' with unified search across conversation, patch, workflow and approval (buzz-gh-3, buzz-gh-5), supporting organized, catch-up-friendly channels. However there's no explicit catch-up/unread-summary tooling or independent hands-on evidence that this actually makes busy-channel triage efficient for a human admin. missing for 10: explicit catch-up/digest feature, independent/hands-on validation of thread organization reducing admin overhead.

   • [claimed-docs] “Spin up a room in seconds. Name it, describe it, make it private.”
   • [claimed-docs] “buzz channels create --name "my-channel" --type stream --visibility open”
   • [github] “Agents search six months of history and post the threads, not vibes.”
   • [github] “Search the conversation, the patch, the workflow run, and the approval in one place”

   proof ↗⚑ flag

Notifications

1. team-adminTune notifications per channel, keyword, and schedule so only what matters interrupts me

   weight 2 · round drawn
   Slack—none0/10

   The evidence pack contains no documentation on per-channel/keyword/schedule notification preferences (e.g., mute channels, keyword alerts, do-not-disturb scheduling) — Slack's actual notification settings are not represented anywhere in this pack, only unrelated AI, workflow, MCP, and integration docs. Missing for 10: any mention of notification preferences, keyword alerts, per-channel mute/schedule controls, or admin-level notification policy tools.

   ⚑ flag

   Buzz—none0/10

   No evidence of notification tuning by channel, keyword, or schedule anywhere in the docs, CLI reference, or README; the CLI examples cover channels, repos, workflows, and GIFs but nothing about notification preferences or muting/alerting rules. Missing for 10: any mention of notification settings, keyword alerts, schedule/quiet-hours controls, or per-channel notification toggles.

   ⚑ flag

Compliance

1. platform-engineerReview audit logs of admin and user actions across the workspace

   weight 2 · round to Buzz
   Slack—none0/10

   The evidence pack includes only workspace data export/import documentation (e.g., slack-docs-22/23/35/36) and community complaints about export restrictions (slack-comm-2), but nothing that documents an audit log capability tracking admin and user actions across the workspace. This is a fair and applicable axis for an enterprise collaboration platform, so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “Export your workspace data | Slack”
   • [claimed-docs] “Guide to Slack import and export tools | Slack”
   • [claimed-docs] “Guide to Slack import and export tools”
   • [claimed-docs] “Export your workspace data”
   • [community] “Wow, Slack does not allow business customers to export their chats freely. Corporate Export requires legal/compliance justification and Slac…”

   proof ↗⚑ flag

   Buzz~partialclaimed3/10

   The only relevant evidence is a passing mention that agents have 'their own audit trail' alongside keys and channel memberships, which hints at some logging of agent actions but says nothing about a queryable/reviewable log covering both admin and human user actions across the workspace, nor any export/compliance tooling. Missing for 10: documented audit log viewer or export, coverage of admin actions and human user actions (not just agent actions), retention/compliance controls, and any independent corroboration.

   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”

   proof ↗⚑ flag

2. platform-engineerEnforce message retention policies and legal holds for compliance and eDiscovery

   weight 2 · round drawn
   Slack—none0/10

   The evidence pack shows generic data export/import guides (slack-docs-22/23/35/36) and a community note that Corporate Export requires legal/compliance justification and Slack approval (slack-comm-2), but nothing documents actual retention-policy enforcement, legal-hold placement, or eDiscovery tooling. Missing for 10: retention policy configuration, legal hold mechanism, eDiscovery search/export APIs, admin documentation on compliance holds.

   • [claimed-docs] “Export your workspace data | Slack”
   • [claimed-docs] “Guide to Slack import and export tools | Slack”
   • [claimed-docs] “Guide to Slack import and export tools”
   • [claimed-docs] “Export your workspace data”
   • [community] “Wow, Slack does not allow business customers to export their chats freely. Corporate Export requires legal/compliance justification and Slac…”

   proof ↗⚑ flag

   Buzz—none0/10

   No evidence of retention policy configuration, legal hold mechanisms, or eDiscovery/compliance export tooling in Buzz's docs or CLI; the product focuses on chat/agent collaboration and repo protection, not compliance retention. missing for 10: retention policy controls, legal hold feature, eDiscovery export capability, compliance documentation.

   ⚑ flag

Exports

1. team-adminExport the full message history of my workspace in machine-readable formats, including private conversations where policy allows

   weight 3 · round to Slack
   Slack!disputedcontradicted5/10

   Slack does document official export tools for workspace data (slack-docs-22/23/35/36), which nominally support the compliance-export story, but community evidence directly contradicts free/easy access: Corporate Export of DMs and private channels requires legal/compliance justification and Slack's approval, and users questioned whether migrating years of full message history out of Slack is even feasible under these restrictions. Missing for 10: no first-party documentation of a machine-readable format spec (JSON/CSV schema details), no evidence addressing the approval-gate friction, and no independent confirmation that large-scale/private-channel exports actually work in practice.

   • [claimed-docs] “Export your workspace data | Slack”
   • [claimed-docs] “Guide to Slack import and export tools | Slack”
   • [claimed-docs] “Guide to Slack import and export tools”
   • [claimed-docs] “Export your workspace data”
   • [community] “Wow, Slack does not allow business customers to export their chats freely. Corporate Export requires legal/compliance justification and Slac…”
   • [community] “Is it even possible to migrate 10 years of message history out of Slack? Users questioned whether such an export was even feasible given Sla…”

   proof ↗⚑ flag

   Buzz—none0/10

   No evidence of any export/compliance feature for full workspace message history in machine-readable formats; evidence covers CLI for channels, workflows, repos, but nothing about admin data export or e-discovery. missing for 10: export/download tooling, machine-readable format documentation, admin controls over private conversation export, compliance/legal-hold features.

   ⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   Slack~partialprobed6/10

   Slack ships an extensive Web API (200+ methods per slack-docs-74), an Events API, official OpenAPI/AsyncAPI specs (slack-supp-openapi-spec), a CLI, SDKs, and an MCP server covering messaging, search, canvases, lists, and file uploads (slack-docs-8, slack-docs-28-30, slack-docs-48). However, community evidence shows a concrete gap: exporting DMs and private channel content requires legal/compliance justification and Slack approval, not open self-serve API access (slack-comm-2, slack-comm-4), and moderation tooling is described as 'purposefully useless' compared to UI expectations (slack-comm-9). Missing for 10: verified parity for admin/compliance-only UI actions (e.g., full data export, moderation controls) via API, and a public discoverable OpenAPI schema (probe shows standard openapi.json paths 404, slack-probe-2).

   • [claimed-docs] “The Slack Web API is an interface for querying information from and enacting change in a Slack workspace.”
   • [claimed-docs] “Send data to or query data from Slack using any of more than 200 methods.”
   • [claimed-docs] “Official slackapi/slack-api-specs repo: "This repository contains API specifications of Slack platform features and APIs... You'll find Open…”
   • [claimed-docs] “The Slack MCP server provides tools for searching through Slack, retrieving and sending messages, managing canvases, managing users, uploadi…”
   • [claimed-docs] “Sends a message to a channel.”
   • [community] “Wow, Slack does not allow business customers to export their chats freely. Corporate Export requires legal/compliance justification and Slac…”
   • [community] “Is it even possible to migrate 10 years of message history out of Slack? Users questioned whether such an export was even feasible given Sla…”
   • [community] “I think 'less capable moderation tools' really undersells how purposefully useless and nonexistent Slack's moderation tools are for open com…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.slack.dev/openapi.json, https://docs.slack.dev/swagger.json, https://docs.slack.dev/api…”

   proof ↗⚑ flag

   Buzz~partialprobed6/10

   Buzz's CLI (buzz-cli) and agent capabilities (buzz-gh-2, buzz-docs-5/7/8) show many UI actions—creating channels, protecting repos, triggering/approving workflows—are exposed programmatically, and agents are described as having full access to open repos, review code, run workflows, and join channels (buzz-gh-2, buzz-gh-4). However, there's no documented OpenAPI/REST spec (buzz-probe-2 shows 404s) confirming full API parity, and some UI-only features like video comments or huddles are not shown as CLI/API accessible. missing for 10: a public API/OpenAPI reference proving complete UI-API parity, evidence that video/canvas/huddle features are scriptable via API.

   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [github] “Agents have their own keys, their own channel memberships, and their own audit trail.”
   • [claimed-docs] “buzz channels create --name "my-channel" --type stream --visibility open”
   • [claimed-docs] “buzz repos protect set --id my-repo --ref refs/heads/main --push admin --no-force-push --no-delete”
   • [claimed-docs] “buzz workflows trigger --workflow buzz workflows approve --token”
   • [probe] “PROBE openapi: all candidate paths 404 (https://buzz.xyz/openapi.json, https://buzz.xyz/swagger.json, https://buzz.xyz/api/openapi.json, htt…”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Buzz
   Slack!disputedcontradicted4/10

   Slack documents a workspace data export feature (slack-docs-22/23/35/36), but concrete community evidence shows this is heavily restricted in practice: Corporate Export of DMs/private channels requires legal/compliance justification and Slack's approval (slack-comm-2), users openly question whether multi-year history can even be exported (slack-comm-4), and Slack has shut down open-protocol (IRC/XMPP) access that once enabled third-party/portable access (slack-comm-11). There's no evidence the export format is genuinely open/interoperable rather than a locked-down archive. Missing for 10: documented open export format specification, independent confirmation of unrestricted self-service export, and no contradicting reports of approval gating.

   • [claimed-docs] “Export your workspace data | Slack”
   • [claimed-docs] “Guide to Slack import and export tools | Slack”
   • [claimed-docs] “Guide to Slack import and export tools”
   • [claimed-docs] “Export your workspace data”
   • [community] “Wow, Slack does not allow business customers to export their chats freely. Corporate Export requires legal/compliance justification and Slac…”
   • [community] “Is it even possible to migrate 10 years of message history out of Slack? Users questioned whether such an export was even feasible given Sla…”
   • [community] “Slack decided to close down IRC and XMPP gateways, ending third-party client access via open protocols; the IRC gateway was the only thing t…”

   proof ↗⚑ flag

   Buzz~partialprobed4/10

   Buzz's open-source, self-hostable design and Nostr-based signed-event architecture imply data ownership and portability ('the project lives in one place, and that place is yours'; run your own relay), but no CLI command or documented feature explicitly exports data in an open format for a user to leave with. Missing for 10: an explicit export/backup command, documentation of the open data format schema, and independent confirmation that self-hosted data can be fully extracted and reused elsewhere.

   • [claimed-docs] “No GitHub. No Discord. No stitching five services together. The project lives in one place, and that place is yours.”
   • [claimed-docs] “Run your own relay for one community, or let an operator host thousands on shared infrastructure — same OSS codebase, same URL-is-your-works…”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Buzz
   Slack—none0/10

   Slack is closed-source proprietary SaaS; no evidence of any open-licensed source code release. Its CLI, MCP server, and APIs are tools around a closed core, not the product's source itself.

   ⚑ flag

   Buzz✓fullprobed8/10

   Buzz's source is hosted publicly on GitHub (block/buzz) with docs, CLI code, and README all visible, and community discussion confirms it's treated as an open-source project ('decentralized, self-sovereign, and open source'). However, the evidence pack never explicitly states or cites a specific OSI license file/name. Missing for 10: explicit citation of the license type (e.g., Apache/MIT) confirming open-license terms, independent verification of license terms.

   • [github] “Turn a feature branch into a room where patches, CI, review, and the merge decision live together — so the channel becomes the record of why…”
   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [claimed-docs] “No GitHub. No Discord. No stitching five services together. The project lives in one place, and that place is yours.”
   • [community] “"Excited for 'decentralized, self-sovereign, and open source.' Indifferent to 'groupchat for agents'."”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Buzz
   Slack—none0/10

   Slack is a cloud SaaS product; the evidence pack shows only hosted/cloud offerings, developer sandboxes, CLI, SDKs, and export tools—no self-hosted deployment option is documented anywhere, and community evidence even discusses difficulty exporting data or migrating off Slack's hosted service.

   • [claimed-docs] “A developer sandbox is an Enterprise org environment (a network of two or more Slack workspace instances) that can be used to build against …”
   • [claimed-docs] “A developer sandbox is an Enterprise org environment ... that can be used to build against all Slack features safely and securely, without a…”
   • [community] “Wow, Slack does not allow business customers to export their chats freely. Corporate Export requires legal/compliance justification and Slac…”
   • [community] “Is it even possible to migrate 10 years of message history out of Slack? Users questioned whether such an export was even feasible given Sla…”

   proof ↗⚑ flag

   Buzz✓fullprobed8/10

   Buzz is explicitly open source and self-hostable: docs state 'Run your own relay for one community... same OSS codebase' and 'The project lives in one place, and that place is yours,' with a public GitHub repo and CLI for setup. Missing for 10: no independent/hands-on report confirming a successful self-hosted deployment, and community comments raise skepticism about maturity/reliability rather than confirming self-hosting works in practice.

   • [claimed-docs] “No GitHub. No Discord. No stitching five services together. The project lives in one place, and that place is yours.”
   • [claimed-docs] “Run your own relay for one community, or let an operator host thousands on shared infrastructure — same OSS codebase, same URL-is-your-works…”
   • [github] “Turn a feature branch into a room where patches, CI, review, and the merge decision live together — so the channel becomes the record of why…”
   • [probe] “official CLI documented at https://github.com/block/buzz/tree/main/crates/buzz-cli”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Slack—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic data controls for Slack; the evidence covers MCP servers, APIs, workflows, and AI features but nothing about choosing where data is stored. This is a fair axis for an enterprise SaaS product, but absence of evidence means it cannot be credited.

   ⚑ flag

   Buzz—none0/10

   The evidence pack mentions self-hosting relay options (buzz-docs-2) but nowhere addresses data residency, regional storage choice, or compliance-driven data location controls. Buyers cannot determine whether or where data can be pinned to a specific region.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Slack—none0/10

   No evidence in the pack addresses AI training data opt-out or controls preventing Slack/customer data from being used to train AI models; the pack covers unrelated AI features (search, summarization, MCP server) and export/pricing controversies but nothing about AI-training data usage or opt-out settings.

   ⚑ flag

   Buzz—none0/10

   No evidence in the pack addresses AI training data usage or opt-out controls for Buzz; nothing discusses data being used to train models or a way to prevent it.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Slack
   Slack!disputedcontradicted3/10

   Slack documents workspace export/import tools (data retention/deletion-adjacent controls), but community evidence explicitly says business customers can't freely export their own chats — Corporate Export requires legal/compliance justification and Slack's approval, and even feasibility of full history export is questioned. This directly contradicts the notion of straightforward user/admin control over data retention and deletion. Missing for 10: explicit documentation of configurable retention periods, deletion policies/workflows, and independent confirmation that exports/deletions can be self-served without gatekeeping.

   • [claimed-docs] “Export your workspace data | Slack”
   • [claimed-docs] “Guide to Slack import and export tools | Slack”
   • [claimed-docs] “Guide to Slack import and export tools”
   • [claimed-docs] “Export your workspace data”
   • [community] “Wow, Slack does not allow business customers to export their chats freely. Corporate Export requires legal/compliance justification and Slac…”
   • [community] “Is it even possible to migrate 10 years of message history out of Slack? Users questioned whether such an export was even feasible given Sla…”

   proof ↗⚑ flag

   Buzz—none0/10

   No evidence in the pack describes any data retention policy, deletion controls, export, or purge mechanisms in Buzz; self-hosting (buzz-docs-2) implies ownership of infrastructure but says nothing about controlling retention/deletion of data itself.

   ⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Slack—none0/10

   No evidence in the pack addresses telemetry or usage-tracking opt-out controls for Slack; the privacy/data-export items (slack-comm-2, slack-docs-22/23/35/36) relate to data export/retention, not telemetry opt-out. This axis plausibly applies to a SaaS collaboration product, but no supporting capability is documented.

   ⚑ flag

   Buzz—none0/10

   No evidence in the pack mentions telemetry, usage tracking, or an opt-out mechanism; while Buzz is self-hostable, that alone doesn't confirm a telemetry opt-out exists. missing for 10: any documentation of telemetry collection or an opt-out setting/flag.

   ⚑ flag

Ai catchup

1. ai-native userGet AI-generated summaries and recaps of channels and threads I missed

   weight 2 · round to Slack
   Slack✓fullclaimed8/10

   Slack's first-party AI features docs explicitly state AI in Slack can summarize channels and threads and serve daily recaps (slack-docs-15), backed by Slackbot as an intelligent daily briefing/agent (slack-docs-13, slack-docs-14) and huddle note-taking/recaps (slack-docs-19, slack-docs-34). This directly matches the story of AI-generated summaries/recaps of missed channels/threads. Missing for 10: independent/hands-on verification of summary quality or accuracy, and no community evidence corroborating real-world reliability of this specific feature (community evidence pack focuses on unrelated pain points like pricing/export/threads UX).

   • [claimed-docs] “Today is your new intelligent briefing that signals what needs your attention based on your priorities.”
   • [claimed-docs] “Slackbot is your personal AI agent in Slack that understands you and your workspace, helping you prepare for upcoming meetings, analyze repo…”
   • [claimed-docs] “AI in Slack can summarize channels and threads and serve up daily recaps, giving you the information you need to stay organized and in the k…”
   • [claimed-docs] “AI in Slack keeps you focused on the conversation by taking notes for you. Key takeaways, action items, and who said what are all neatly org…”
   • [claimed-docs] “AI in Slack keeps you focused on the conversation by taking notes for you. Key takeaways, action items, and who said what are all neatly org…”

   proof ↗⚑ flag

   Buzz—none0/10

   Buzz evidence focuses on agents searching history and pulling up relevant threads (buzz-gh-3, buzz-gh-5) but there's no documentation of an AI-generated summary/recap feature for channels or threads a user missed; the CLI and docs list channel creation, repo management, and workflow triggers with no summarization command or feature mentioned.

   ⚑ flag

Search

1. team-adminSearch the full message history with filters like sender, channel, and date

   weight 3 · round to Slack
   Slack~partialclaimed6/10

   Slack docs confirm full, unlimited searchable message history (slack-docs-43, slack-docs-16/52) and Slack's native search supports filtering, but the evidence pack does not explicitly document admin-specific advanced search operators (from:, in:, before:/after:) or an admin-console-level cross-workspace search UI beyond general user search claims; the MCP server also offers 'searching through Slack' but is a separate API-driven tool rather than the admin search UI itself. missing for 10: explicit documentation of native in-app search filter syntax (sender/channel/date), evidence of admin-level search scope (e.g. Enterprise-wide search across workspaces), and independent/hands-on confirmation of filter functionality.

   • [claimed-docs] “Unlimited message history Every message, file, and conversation shared in Slack is saved and fully searchable.”
   • [claimed-docs] “Conversations with coworkers, PDFs, images for your social campaign, decks buried in Google Drive, support tickets, customer records from Sa…”
   • [claimed-docs] “if it's shared in or integrated into Slack, it's searchable.”
   • [claimed-docs] “The Slack MCP server provides tools for searching through Slack, retrieving and sending messages, managing canvases, managing users, uploadi…”

   proof ↗⚑ flag

   Buzz~partialclaimed3/10

   Buzz claims agents can 'search six months of history' and 'search the conversation, patch, workflow run, and approval in one place,' implying a search capability across history, but no evidence describes structured filters like sender, channel, or date, nor a team-admin-specific search UI or command. missing for 10: documented filter parameters (sender/channel/date), admin-facing search tool or CLI command, independent confirmation of filter functionality.

   • [github] “Agents search six months of history and post the threads, not vibes.”
   • [github] “Search the conversation, the patch, the workflow run, and the approval in one place”

   proof ↗⚑ flag

Workflow builder

1. team-adminBuild no-code workflows triggered by events, schedules, or form submissions inside the chat tool

   weight 3 · round to Slack
   Slack✓fullclaimed8/10

   Slack's Workflow Builder is documented as a no-code way to build workflows directly in Slack, supporting event/schedule/form-submission triggers, webhook triggers, and conditional branching. missing for 10: independent/hands-on corroboration of the builder in use, and detail on schedule-based triggers specifically beyond webhook/event mentions.

   • [claimed-docs] “Workflow Builder is a no-code way to build workflows, right in Slack. Any user can combine a limited set of steps and triggers to quickly se…”
   • [claimed-docs] “Webhook triggers for workflows - How to start a workflow from outside of Slack.”
   • [claimed-docs] “Add a branch to a workflow - How to add conditional branching that will present users with different options based on their interaction with…”
   • [claimed-docs] “Workflow Builder is a no-code way to build workflows, right in Slack.”
   • [claimed-docs] “Webhook triggers for workflows”
   • [claimed-docs] “Add a branch to a workflow”

   proof ↗⚑ flag

   Buzz—none0/10

   Evidence shows Buzz has developer-oriented 'workflows' tied to CI/CD and code review (e.g., 'buzz workflows trigger/approve' CLI commands, 'run workflows' in agent capabilities) but nothing describing a no-code workflow builder for team-admins with triggers from events, schedules, or form submissions. This is a CLI/agent-driven automation surface, not a no-code admin tool.

   • [github] “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels”
   • [claimed-docs] “buzz workflows trigger --workflow buzz workflows approve --token”

   proof ↗⚑ flag