Discord vs Buzz

Agent access

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

   weight 2 · round to Discord
   Discord✓fullprobed9/10

   Direct probe evidence confirms Discord's developer docs serve a working llms.txt (HTTP 200) with an index of documentation pages, and individual doc pages are also available in .md format explicitly for agent consumption, pointing back to the llms.txt index. Missing for 10: no independent third-party confirmation of agent usage/adoption beyond the probe itself.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.discord.com/llms.txt # Documentation - Discord - [Discord Developer Platform](https://docs.discord…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.discord.com/developers/intro.md > ## Documentation Index > Fetch the complete documentation index at…”

   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 Discord
   Discord~partialclaimed6/10

   Discord's REST API, bot tokens, and webhooks are explicitly documented as usable without a GUI, including a direct example of 'CI/CD pipelines posting build results or deployment notifications' via webhooks, and bots can run headlessly against the Gateway/REST API using only a token. However there's no first-party CLI, headless test harness, or SDK-level guidance for running the whole platform in automated pipelines beyond webhooks/bots. Missing for 10: an official CLI or headless client mode, dedicated CI documentation/examples beyond webhooks, and independent confirmation of headless bot reliability in CI.

   • [claimed-docs] “CI/CD pipelines posting build results or deployment notifications”
   • [claimed-docs] “Send messages into Discord channels or receive event notifications from Discord delivered to your app over HTTP.”
   • [claimed-docs] “Webhooks are a low-effort way to post messages to channels in Discord. They do not require a bot user or authentication to use.”
   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways: 1. Using a bot token... 2. Using an OAuth2 bearer token”
   • [claimed-docs] “The Discord API is a REST API that allows you to interact with Discord data from your own applications.”

   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 userDrive the product through a documented public API

   weight 3 · round to Discord
   Discord✓fullprobed8/10

   Discord provides a well-documented REST API, Gateway WebSocket API, OAuth2, bot tokens, webhooks, and slash commands — all extensively documented for programmatic/AI-driven access (discord-docs-35, -10, -4, -5, -7). This gives an AI-native user a clear documented public API surface to drive the product. Missing for 10: no discoverable OpenAPI/Swagger spec (probe confirms 404s at standard paths), and no independent third-party verification of API completeness beyond first-party docs.

   • [claimed-docs] “The Discord API is a REST API that allows you to interact with Discord data from your own applications.”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”
   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways: 1. Using a bot token... 2. Using an OAuth2 bearer token”
   • [claimed-docs] “Webhooks are a low-effort way to post messages to channels in Discord. They do not require a bot user or authentication to use.”
   • [claimed-docs] “Slash commands are the most common type of command and are accessed by typing `/` in the chat input, or by opening the command picker.”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild, …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.discord.com/openapi.json, https://docs.discord.com/swagger.json, https://docs.discord.c…”

   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

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

   weight 2 · round drawn
   Discord~partialclaimed4/10

   Discord's API supports OAuth2 bearer tokens with defined scopes and bot tokens with granular permission bits (docs-4, docs-6, docs-17, docs-18, docs-27), which technically allow issuing narrower-than-full-access credentials for any integration, including an agent. However, there is no documentation framing this specifically for AI agents or describing least-privilege credential issuance workflows tailored to autonomous/agentic use. missing for 10: agent-specific scoped-credential guidance, examples of least-privilege bot/OAuth setups for AI agents, independent confirmation of scope granularity in practice.

   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways: 1. Using a bot token... 2. Using an OAuth2 bearer token”
   • [claimed-docs] “The first step in implementing OAuth2 is registering a developer application and retrieving your client ID and client secret.”
   • [claimed-docs] “Using a bot token found on the Bot page within your app’s settings... Using an OAuth2 bearer token gained through the OAuth2 API.”
   • [claimed-docs] “OAuth2 enables application developers to build applications that utilize authentication and data from the Discord API.”
   • [claimed-docs] “allows /users/@me/connections to return linked third-party accounts”

   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

5. ai-native userBuild against official SDKs

   weight 2 · round to Discord
   Discord✓fullclaimed8/10

   Discord provides extensive first-party documentation for building against official SDKs and APIs — the REST API, Gateway (WebSocket) API, OAuth2, Embedded App SDK, and a full Discord Social SDK with platform-specific guides for Unity, Unreal Engine, C++, iOS/Android, and web/mobile account linking. This gives builders (including AI-native developers) clear, well-documented interfaces to build bots, apps, and integrations. Missing for 10: independent/hands-on developer corroboration of SDK integration experience and AI-agent-specific SDK examples or tooling.

   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways: 1. Using a bot token... 2. Using an OAuth2 bearer token”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”
   • [claimed-docs] “Our Embedded App SDK makes it quick and easy to ship native web apps, games, and interactive experiences.”
   • [claimed-docs] “The Discord API is a REST API that allows you to interact with Discord data from your own applications.”
   • [claimed-docs] “allowing them to connect with their friends and communities on Discord without leaving your game”
   • [claimed-docs] “This guide will walk you through integrating the Discord Social SDK into a Unity project.”
   • [claimed-docs] “Get started with the Discord Social SDK in C++ applications.”
   • [claimed-docs] “Integrate the Discord Social SDK into Unreal Engine games.”
   • [claimed-docs] “With the Discord Social SDK, you can offer a seamless social experience for your players, allowing them to connect with their friends and co…”

   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

6. ai-native userSubscribe to events via webhooks

   weight 2 · round to Discord
   Discord~partialclaimed6/10

   Discord's webhook docs explicitly state apps can 'receive event notifications from Discord delivered to your app over HTTP,' confirming webhook-based event subscription exists alongside the Gateway websocket API for events. However, the evidence pack gives only a single line on this capability with no detail on which events are supported, setup/config steps, or independent developer confirmation. Missing for 10: full list of subscribable event types, setup/configuration docs, and third-party/community validation of webhook event delivery in practice.

   • [claimed-docs] “Send messages into Discord channels or receive event notifications from Discord delivered to your app over HTTP.”
   • [claimed-docs] “Webhooks are a low-effort way to post messages to channels in Discord. They do not require a bot user or authentication to use.”
   • [claimed-docs] “They do not require a bot user or authentication to use.”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”

   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 Buzz
   Discord—none0/10

   No evidence Discord itself generates AI insights or suggestions from a user's data; evidence only covers bots/APIs, webhooks, threads, Nitro perks, and the Social SDK, none of which describe native AI-generated insights inside the product.

   ⚑ 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 Buzz
   Discord~partialclaimed5/10

   Discord's developer platform provides Gateway (persistent WebSocket) and webhook APIs that let bots run continuously in the background reacting to events, and third parties can build bots that act autonomously (e.g., CI/CD notifications). However, this requires custom bot development rather than a built-in no-code 'automation' feature for end users, and there's no evidence of a first-party AI-native automation/workflow builder. Missing for 10: native no-code automation/workflow feature for non-developer users, AI-specific automation tooling, and independent evidence of autonomous background agents working reliably in practice.

   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild, …”
   • [claimed-docs] “Webhooks are a low-effort way to post messages to channels in Discord. They do not require a bot user or authentication to use.”
   • [claimed-docs] “CI/CD pipelines posting build results or deployment notifications”
   • [claimed-docs] “Send messages into Discord channels or receive event notifications from Discord delivered to your app over HTTP.”
   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways: 1. Using a bot token... 2. Using an OAuth2 bearer token”

   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 Buzz
   Discord—none0/10

   Discord's evidence covers building bots/apps via developer APIs, but there is no evidence of a built-in first-party AI assistant that users can delegate tasks to within the product itself.

   ⚑ 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 Buzz
   Discord—none0/10

   Discord's documented command system is built around structured slash commands, buttons, and modals (discord-docs-7/8/9/19/28/48), not natural-language interpretation of user requests; no evidence shows Discord itself parses free-form natural language to drive actions. The axis is plausible for a chat platform but nothing in the evidence demonstrates it.

   • [claimed-docs] “Slash commands are the most common type of command and are accessed by typing `/` in the chat input, or by opening the command picker.”
   • [claimed-docs] “Buttons are clickable components that can be customized with different styles, texts, and emoji.”
   • [claimed-docs] “Modals are single-user pop-up interfaces that allow apps to collect form-like data.”
   • [claimed-docs] “Application commands provide users a native way to invoke an app in Discord.”
   • [claimed-docs] “Application commands provide users a native way to invoke an app in Discord. They often map to an app’s core features or functionality.”
   • [claimed-docs] “Interactive features like commands and message components allows users to invoke an app natively within Discord.”

   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
   Discord—none0/10

   Discord's developer docs describe REST/Gateway/OAuth2 concepts and provide markdown-based reference pages, but the probe explicitly found no OpenAPI/Swagger spec (all candidate paths 404'd) and no evidence of an interactive, runnable-example API console or sandbox exists in the pack.

   • [claimed-docs] “The Discord API is a REST API that allows you to interact with Discord data from your own applications.”
   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways:”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.discord.com/openapi.json, https://docs.discord.com/swagger.json, https://docs.discord.c…”

   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 drawn
   Discord—none0/10

   Discord provides REST API documentation and an llms.txt for docs indexing, but a direct probe for OpenAPI/swagger specs at all standard paths (openapi.json, swagger.json, api/openapi.json, .well-known/openapi.json) returned 404s, indicating no downloadable machine-readable API spec is published.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.discord.com/openapi.json, https://docs.discord.com/swagger.json, https://docs.discord.c…”
   • [claimed-docs] “The Discord API is a REST API that allows you to interact with Discord data from your own applications.”

   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 userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Discord—none0/10

   The evidence pack covers Discord's API surfaces (REST, Gateway, OAuth2, webhooks, Social SDK) but contains no documentation or mention of API versioning scheme, version deprecation timelines, or a changelog/deprecation policy for developers to rely on. Missing for 10: explicit API version documentation (e.g., v9/v10), a published deprecation policy, and changelog/migration guides.

   • [claimed-docs] “The Discord API is a REST API that allows you to interact with Discord data from your own applications.”
   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways: 1. Using a bot token... 2. Using an OAuth2 bearer token”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”

   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 Discord
   Discord~partialclaimed6/10

   Discord's docs confirm an App Directory — a searchable hub where users can browse apps/bots by name, category, or collection and add them to servers — which functions as a marketplace for prebuilt integrations (bots/apps). However, the evidence is entirely first-party docs about developer discovery/listing mechanics, with no detail on the admin-side installation/permission flow or independent confirmation of the experience. Missing for 10: independent/hands-on evidence of the admin installation UX, documentation of admin permission controls for installing apps, and confirmation beyond discovery-focused developer docs.

   • [claimed-docs] “Once you've enabled discovery for your app, users can find it in the App Directory — a searchable hub where they can browse by name, categor…”
   • [claimed-docs] “Once you’ve enabled discovery for your app, users can find it in the App Directory — a searchable hub where they can browse by name, categor…”
   • [claimed-docs] “users can find it in the App Directory — a searchable hub where they can browse by name, category, or collection.”
   • [claimed-docs] “users can find it in the App Directory — a searchable hub where they can browse by name”
   • [claimed-docs] “Create shareable links to your app's profile page, store page, or specific items. Share these links in Discord, emails, or on your website.”

   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 to Discord
   Discord✓fullclaimed8/10

   Discord's docs clearly document slash commands ('application commands') as a native way for users to invoke apps by typing `/` in the chat box, with dedicated interactions/overview documentation covering registration and behavior. Missing for 10: independent hands-on developer corroboration and details on the actual registration API/code sample within this evidence pack.

   • [claimed-docs] “Slash commands are the most common type of command and are accessed by typing `/` in the chat input, or by opening the command picker.”
   • [claimed-docs] “Application commands provide users a native way to invoke an app in Discord.”
   • [claimed-docs] “Application commands provide users a native way to invoke an app in Discord. They often map to an app’s core features or functionality.”
   • [claimed-docs] “Interactive features like commands and message components allows users to invoke an app natively within Discord.”

   proof ↗⚑ 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 Discord
   Discord✓fullclaimed8/10

   Discord's developer docs explicitly document buttons, modals, slash/application commands, and message components as first-party interaction features for building rich in-chat UI (discord-docs-7,8,9,19,48). This directly matches the story's core ask. Missing for 10: no independent/hands-on developer corroboration of building a full interactive app, and no detail on select menus or full structured layout components beyond buttons/modals.

   • [claimed-docs] “Slash commands are the most common type of command and are accessed by typing `/` in the chat input, or by opening the command picker.”
   • [claimed-docs] “Buttons are clickable components that can be customized with different styles, texts, and emoji.”
   • [claimed-docs] “Modals are single-user pop-up interfaces that allow apps to collect form-like data.”
   • [claimed-docs] “Application commands provide users a native way to invoke an app in Discord.”
   • [claimed-docs] “Interactive features like commands and message components allows users to invoke an app natively within Discord.”
   • [claimed-docs] “Application commands provide users a native way to invoke an app in Discord. They often map to an app’s core features or functionality.”

   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
   Discord—none0/10

   The evidence pack covers Discord's bot/API docs, OAuth2, webhooks, slash commands, and Social SDK, but nothing describes bulk endpoints or batch operations (e.g., bulk message delete, mass channel/role management) that an AI-native user could invoke to act on many items at once.

   ⚑ 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 Buzz
   Discord~partialclaimed4/10

   Discord's Gateway API lets developer-built bots subscribe to server events and act on them, and webhooks let external systems post to Discord on events (e.g. CI/CD triggers), giving a technical path to event-driven automation. However, there is no evidence of a native, no-code 'if this then that' rule-builder for end users — all automation requires writing and hosting a bot/webhook integration. Missing for 10: a first-party no-code automation/rules UI, evidence of AI-native rule triggers, and independent confirmation that non-developer users can set this up.

   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild, …”
   • [claimed-docs] “CI/CD pipelines posting build results or deployment notifications”
   • [claimed-docs] “Send messages into Discord channels or receive event notifications from Discord delivered to your app over HTTP.”
   • [claimed-docs] “Webhooks are a low-effort way to post messages to channels in Discord. They do not require a bot user or authentication to use.”

   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

Ai agents

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

   weight 3 · round to Buzz
   Discord~partialclaimed6/10

   Discord's developer docs show a full bot platform — bot tokens, Gateway API for real-time message/event delivery, and application commands — that supports building an AI agent as a bot member of a server/channel, which is the standard mechanism for mention-triggered response bots. However, the evidence never explicitly documents mention-detection or an AI-agent-specific integration pattern, and there's no first-party or hands-on example of an AI agent responding when @mentioned in a channel. Missing for 10: explicit docs/example on mention-based triggering, hands-on/independent evidence of an AI agent bot working this way in production.

   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild, …”
   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways: 1. Using a bot token... 2. Using an OAuth2 bearer token”
   • [claimed-docs] “Application commands provide users a native way to invoke an app in Discord.”
   • [claimed-docs] “Slash commands are the most common type of command and are accessed by typing `/` in the chat input, or by opening the command picker.”
   • [claimed-docs] “Build bots and integrations on Discord, or connect your game with rich presence, voice chat, and more.”

   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 Discord
   Discord✓fullclaimed8/10

   Discord's official REST/Gateway API supports bot tokens and OAuth2 bearer tokens scoped to specific permissions, allowing an agent (bot) to read and post channel messages via documented endpoints and real-time Gateway events. missing for 10: no independent hands-on confirmation of an AI agent specifically using scoped tokens for message read/post, and no explicit documentation of granular message-read/post scopes beyond general bot/OAuth2 token mechanics.

   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways: 1. Using a bot token... 2. Using an OAuth2 bearer token”
   • [claimed-docs] “Using a bot token found on the Bot page within your app’s settings... Using an OAuth2 bearer token gained through the OAuth2 API.”
   • [claimed-docs] “The Discord API is a REST API that allows you to interact with Discord data from your own applications.”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild, …”
   • [claimed-docs] “OAuth2 enables application developers to build applications that utilize authentication and data from the Discord API.”
   • [claimed-docs] “The first step in implementing OAuth2 is registering a developer application and retrieving your client ID and client secret.”

   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 Discord
   Discord✓fullclaimed9/10

   Discord's docs explicitly describe incoming webhooks as a low-effort way to post messages to channels without requiring a bot user or authentication, and give concrete use cases like CI/CD pipelines posting notifications via HTTP. This directly matches the story of simple webhook-based posting. Missing for 10: independent hands-on developer confirmation of the webhook flow working in practice.

   • [claimed-docs] “Webhooks are a low-effort way to post messages to channels in Discord. They do not require a bot user or authentication to use.”
   • [claimed-docs] “They do not require a bot user or authentication to use.”
   • [claimed-docs] “CI/CD pipelines posting build results or deployment notifications”
   • [claimed-docs] “Send messages into Discord channels or receive event notifications from Discord delivered to your app over HTTP.”

   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 Discord
   Discord✓fullclaimed9/10

   Discord's documented Gateway API explicitly provides secure WebSocket connections for apps to receive real-time events (channel updates, role creation, etc.), and bot token authentication plus REST API access complete the developer bot-building path. Webhooks are also documented as an alternative for receiving/posting event notifications over HTTP. Missing for 10: independent hands-on developer confirmation of gateway reliability/rate limits and no direct community corroboration of real-time event handling in production.

   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild, …”
   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways: 1. Using a bot token... 2. Using an OAuth2 bearer token”
   • [claimed-docs] “The Discord API is a REST API that allows you to interact with Discord data from your own applications.”
   • [claimed-docs] “Send messages into Discord channels or receive event notifications from Discord delivered to your app over HTTP.”

   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 drawn
   Discord—none0/10

   No evidence of any AI-generated meeting notes, transcription, or recap feature for Discord voice/huddle calls; the evidence pack covers bots, APIs, webhooks, Social SDK, and Nitro perks but nothing about AI summarization of calls. Missing for 10: any documentation or feature reference to AI-generated call transcripts, summaries, or recap generation.

   ⚑ 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 Buzz
   Discord—none0/10

   The evidence pack contains only developer/API documentation (bots, webhooks, OAuth2, Social SDK for games) and community commentary on unrelated topics like verification and moderation; none of it documents the core client feature of a user/admin starting a voice or video call directly from a text channel or DM inside the Discord app itself. Mentions of 'voice chat' (discord-docs-3, discord-docs-41) refer to the Social SDK for third-party games, not native in-app calling.

   • [claimed-docs] “Add rich presence, voice chat, and social features to your game across all platforms.”
   • [claimed-docs] “Build bots and integrations on Discord, or connect your game with rich presence, voice chat, and more.”

   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 drawn
   Discord—none0/10

   The evidence pack contains extensive Discord developer/API docs and community commentary but no mention of native screen-sharing during voice/video calls, which is the core capability the story asks about. Absence of evidence for this mainstream Discord feature means it cannot be credited even though it likely exists in the product.

   ⚑ 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
   Discord—none0/10

   The evidence pack shows Discord's developer platform, threads, and Nitro features but contains no mention of guest accounts, cross-org shared channels, or admin-controlled limited-access partner collaboration akin to Slack Connect. Threads (discord-docs-37, discord-docs-38) are an internal channel-branching feature, not external partner access control.

   ⚑ 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
   Discord~partialclaimed5/10

   Evidence confirms Discord supports organizing conversations into public and private sub-conversations (Threads, including 'Private Threads... rolling out to all servers') via discord-docs-37/38, which aligns with channel-like organization, but the pack contains no documentation of full channel-level permission/role systems, member/channel visibility controls, or admin management of channel membership that would fully substantiate the 'membership controls' part of the story. Missing for 10: explicit docs on channel permission overwrites/roles, admin UI for private channel membership, and any independent confirmation of these controls working as described.

   • [claimed-docs] “A Thread is a quick way to branch a conversation off of a channel’s main feed without removing it from the channel itself.”
   • [claimed-docs] “Private Threads are now available for all servers! This exciting update is rolling out to both desktop and mobile users now.”

   proof ↗⚑ 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 Discord
   Discord~partialclaimed6/10

   Discord's blog docs confirm threads let users branch off a channel's main feed without removing context, including private threads for servers, which supports side-discussions staying attached to the original message. However, evidence doesn't explicitly confirm 'reply in thread' UX specifics or admin-specific thread controls. missing for 10: explicit documentation of admin thread permission controls, reply-to-message-in-thread UX detail, independent/hands-on corroboration beyond blog announcement.

   • [claimed-docs] “A Thread is a quick way to branch a conversation off of a channel’s main feed without removing it from the channel itself.”
   • [claimed-docs] “Private Threads are now available for all servers! This exciting update is rolling out to both desktop and mobile users now.”
   • [claimed-docs] “Connect the Conversation with Threads on Discord”

   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
   Discord!disputedcontradicted5/10

   Discord docs confirm threads let you branch conversations off a channel's main feed to organize topics (discord-docs-37, discord-docs-38, discord-docs-54), which is the core mechanism the story asks for. However, independent community reports describe channels/threads as chaotic when busy and poorly organized for catch-up, noting messages 'gate' content and become 'very chaotic when a lot of people are posting' and that Discord's UI/UX makes content hard to find intuitively (discord-comm-9, discord-comm-11). Missing for 10: evidence of thread-based read-state/summary tools for admins, and resolution of the chaos/discoverability complaints from real users.

   • [claimed-docs] “A Thread is a quick way to branch a conversation off of a channel’s main feed without removing it from the channel itself.”
   • [claimed-docs] “Private Threads are now available for all servers! This exciting update is rolling out to both desktop and mobile users now.”
   • [claimed-docs] “Connect the Conversation with Threads on Discord”
   • [community] “Discord, Slack, Gitter all gate messages so much, they are not well indexed by search engines and very chaotic when a lot of people are post…”
   • [community] “I think Discord UI/UX is beyond terrible and Discord is nothing more than a terrible walled garden where none of the content has any discove…”

   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
   Discord—none0/10

   The evidence pack covers developer APIs, Nitro perks, Social SDK, threads, and community complaints, but contains no mention of Discord's actual notification settings features (per-channel mute/notification level, keyword/mention alerts, or scheduled quiet hours/Do Not Disturb) that a team-admin would use to tune interruptions.

   ⚑ 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
   Discord—none0/10

   No evidence of any audit-log feature for admin/user actions across a Discord server or workspace; the evidence pack covers developer APIs, bots, Nitro, Social SDK, and community sentiment, but nothing about compliance/audit logging capabilities for platform engineers.

   ⚑ 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
   Discord—none0/10

   No evidence in the pack references message retention policies, legal holds, eDiscovery workflows, or compliance export tooling for platform engineers; the docs cover developer APIs, bots, Social SDK, and Nitro features only.

   ⚑ 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 drawn
   Discord—none0/10

   No evidence of any compliance-export tool, eDiscovery feature, or admin capability to export full message history (including private conversations) in machine-readable formats; the pack only covers developer APIs, bots, webhooks, Nitro, and Social SDK, none of which provide bulk/team-admin export of message history.

   ⚑ 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 to Buzz
   Discord~partialprobed5/10

   Discord's developer platform exposes a broad REST/Gateway API, OAuth2, webhooks, slash commands, interactions, and a Social SDK covering messaging, presence, and account linking, showing substantial API coverage of bot/integration functionality. However, this coverage is aimed at building bots/apps rather than giving an end-user full parity with everything doable in the Discord client (e.g., no evidence of API-equivalent actions for Nitro subscription features, personal account social actions, or general UI-only settings), and the probe confirms no discoverable OpenAPI spec, suggesting the API surface isn't exhaustively documented for 1:1 parity. missing for 10: evidence of full end-user (non-bot) API parity for all client actions, an official OpenAPI/spec confirming complete surface coverage, and independent confirmation that no UI action lacks an API equivalent.

   • [claimed-docs] “Build automated apps, commands, and integrations that run inside Discord servers.”
   • [claimed-docs] “Authenticating with the Discord API can be done in one of two ways: 1. Using a bot token... 2. Using an OAuth2 bearer token”
   • [claimed-docs] “Webhooks are a low-effort way to post messages to channels in Discord. They do not require a bot user or authentication to use.”
   • [claimed-docs] “Slash commands are the most common type of command and are accessed by typing `/` in the chat input, or by opening the command picker.”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”
   • [claimed-docs] “The Discord API is a REST API that allows you to interact with Discord data from your own applications.”
   • [claimed-docs] “Send messages into Discord channels or receive event notifications from Discord delivered to your app over HTTP.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.discord.com/openapi.json, https://docs.discord.com/swagger.json, https://docs.discord.c…”

   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
   Discord—none0/10

   No evidence of a user-facing data export/portability feature or open-format data takeout for personal Discord data; the evidence pack covers developer APIs, bots, Nitro, and community complaints (e.g., loss of contact info on server bans, walled-garden criticism) rather than any account data-export capability. Missing for 10: documented data export/takeout tool, open-format (e.g., JSON) download of messages/DMs/servers, and any account deletion+portability workflow.

   • [community] “One day I came to discover that Discord had banned the server for allegedly violating something. I wish I had written down everyone's emails…”
   • [community] “I think Discord UI/UX is beyond terrible and Discord is nothing more than a terrible walled garden where none of the content has any discove…”
   • [claimed-docs] “The Discord API is a REST API that allows you to interact with Discord data from your own applications.”

   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

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

   weight 2 · round drawn
   Discord—none0/10

   No evidence in the pack of Discord offering data residency/region selection controls for where user data is stored; documentation covers bots, APIs, SDKs, and Nitro features but nothing about data locality controls.

   ⚑ 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
   Discord—none0/10

   No evidence of any AI-training data opt-out control, privacy setting, or policy statement addressing use of user data for AI/ML model training; evidence pack covers developer platform, bots, Nitro features, and unrelated community complaints (verification, moderation, breaches).

   ⚑ 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 drawn
   Discord—none0/10

   The evidence pack contains no documentation of data retention settings, data export, or account/message deletion controls for Discord users; it only shows unrelated developer API docs and community complaints about ID verification and a data breach, none of which describe actual retention/deletion controls.

   ⚑ 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
   Discord—none0/10

   No evidence of any telemetry opt-out or privacy/data-tracking settings; the evidence pack covers developer APIs, Nitro features, and community complaints about verification/breaches, none of which address telemetry opt-out controls.

   ⚑ 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 drawn
   Discord—none0/10

   No evidence of any native Discord feature that generates AI summaries or recaps of missed channels/threads; docs cover bots, OAuth2, webhooks, threads, Social SDK, and Nitro perks but nothing about AI-generated recap/summary functionality. A third-party bot could theoretically add this, but no such capability is evidenced for Discord itself.

   • [claimed-docs] “A Thread is a quick way to branch a conversation off of a channel’s main feed without removing it from the channel itself.”
   • [claimed-docs] “Private Threads are now available for all servers! This exciting update is rolling out to both desktop and mobile users now.”
   • [claimed-docs] “Connect the Conversation with Threads on Discord”

   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 Buzz
   Discord—none0/10

   The evidence pack contains no documentation or first-party reference to Discord's message search feature or its filters (sender, channel, date); all docs items focus on the developer API, bots, Nitro, and Social SDK. Community evidence even suggests messages are 'chaotic' and poorly indexed, but that speaks to external search engines, not an admin search UI, so it doesn't confirm the capability either.

   • [community] “Discord, Slack, Gitter all gate messages so much, they are not well indexed by search engines and very chaotic when a lot of people are post…”

   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 drawn
   Discord—none0/10

   Discord's evidence pack shows only developer-oriented building blocks—webhooks, bot tokens, Gateway API events, slash commands—which require writing and hosting code, not a no-code workflow builder for triggers/schedules/forms. There is no mention of any built-in no-code automation canvas, scheduled triggers, or form-submission triggers akin to Slack Workflow Builder or Zapier.

   • [claimed-docs] “Webhooks are a low-effort way to post messages to channels in Discord. They do not require a bot user or authentication to use.”
   • [claimed-docs] “The Gateway API lets apps open secure WebSocket connections with Discord to receive events about actions that take place in a server/guild”
   • [claimed-docs] “CI/CD pipelines posting build results or deployment notifications”
   • [claimed-docs] “Send messages into Discord channels or receive event notifications from Discord delivered to your app over HTTP.”
   • [claimed-docs] “Modals are single-user pop-up interfaces that allow apps to collect form-like data.”

   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