Zulip vs Buzz

Agent access

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

   weight 2 · round to Zulip
   Zulip~partialprobed3/10

   No llms.txt exists (confirmed 404) and other agent-friendly doc endpoints (openapi.json, docs.md) also 404 on the primary domain, but Zulip does publish a full machine-readable OpenAPI spec in its GitHub repo that an agent could be pointed at to understand the API surface. This is a weak substitute for a true llms.txt/agent-docs entry point. Missing for 10: an actual llms.txt file, any officially surfaced agent-oriented documentation page, and discoverability of the OpenAPI spec from the main docs site rather than only via GitHub raw.

   • [probe] “PROBE llms.txt: HTTP 404 at https://zulip.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://zulip.com/api/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://zulip.com/openapi.json, https://zulip.com/swagger.json, https://zulip.com/api/openapi.json, …”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”

   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 Zulip
   Zulip~partialprobed6/10

   Zulip ships a documented REST API (OpenAPI spec verified live), a keyless-working API endpoint, and an official Python CLI (zulip-send) that installs via pip and runs headlessly from scripts, supporting basic CI automation like sending messages. However, there's no evidence of first-class CI/CD integration patterns, GitHub Actions examples, containerized headless server mode, or broader automation tooling beyond bots/webhooks. missing for 10: CI-specific documentation or examples, containerized/headless deployment guidance for automation pipelines, evidence of use in real CI workflows.

   • [probe] “PROBE api-live: GET https://chat.zulip.org/api/v1/server_settings → HTTP 200 {"result":"success",...,"zulip_version":"12.0-919-gb1bd7d7d3e"}…”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [probe] “PROBE cli-runtime: pip install zulip (v0.9.1) → official zulip-send CLI installs from PyPI and runs headlessly (--help prints usage for send…”
   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Eventually, you’ll probably want to run it in a production environment where it’ll stay up, by deploying it on a server using the Zulip Bots…”

   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 userConnect an agent via an official MCP server

   weight 3 · round to Buzz
   Zulip—none0/10

   Zulip is a chat platform, so publishing an official MCP server to let AI agents connect is a plausible axis, but no evidence pack item mentions MCP at all — only bots, webhooks, REST API, and OpenAPI spec are documented. missing for 10: any mention of an MCP server (official or community), MCP protocol support, or agent-connection tooling beyond generic bots/API.

   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”

   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

4. ai-native userUse an official CLI

   weight 2 · round to Buzz
   Zulip~partialprobed6/10

   Hands-on evidence confirms an official 'zulip-send' CLI installs via PyPI and runs headlessly for scripting message sends, which supports agentic/automation use cases. However, the evidence pack shows no broader CLI feature set (e.g., reading messages, managing channels, bots) beyond sending, and no first-party docs elaborating CLI capabilities beyond the probe. Missing for 10: documented full CLI command reference, evidence of read/administrative CLI operations, and independent community corroboration of CLI use in agentic workflows.

   • [probe] “PROBE cli-runtime: pip install zulip (v0.9.1) → official zulip-send CLI installs from PyPI and runs headlessly (--help prints usage for send…”

   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

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

   weight 3 · round to Zulip
   Zulip✓fullprobed9/10

   Zulip publishes a documented REST API (zulip.com/api) backed by a full OpenAPI 3.0 spec in its repo, verified live against a public server responding to documented endpoints, plus an official Python CLI (zulip-send) installable via pip for scripting/automation. This directly supports an AI-native user driving the product programmatically. Missing for 10: no discoverable llms.txt or machine-readable docs endpoint for LLM consumption, and no independent third-party corroboration beyond hands-on probes.

   • [claimed-docs] “Send a message”
   • [probe] “PROBE api-live: GET https://chat.zulip.org/api/v1/server_settings → HTTP 200 {"result":"success",...,"zulip_version":"12.0-919-gb1bd7d7d3e"}…”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [probe] “PROBE cli-runtime: pip install zulip (v0.9.1) → official zulip-send CLI installs from PyPI and runs headlessly (--help prints usage for send…”

   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

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

   weight 2 · round to Buzz
   Zulip—none0/10

   Zulip documents bot accounts and API keys for automation, but no evidence shows a mechanism for issuing scoped or least-privilege credentials (e.g., restricted permission bots, granular API scopes) specifically for AI agents — bots appear to get a single API key without documented fine-grained access controls.

   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”
   • [claimed-docs] “Eventually, you’ll probably want to run it in a production environment where it’ll stay up, by deploying it on a server using the Zulip Bots…”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”

   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

7. ai-native userBuild against official SDKs

   weight 2 · round to Zulip
   Zulip✓fullprobed8/10

   Zulip ships an official Python SDK/CLI installable via PyPI (pip install zulip) with hands-on verified functionality (zulip-send), a full machine-readable OpenAPI 3.0.1 spec covering the REST API, and a live documented REST API confirmed working on a public server. This directly satisfies building against official SDKs for an AI-native/agentic workflow. Missing for 10: no evidence of SDKs in other languages (JS/Node, Go, etc.), no llms.txt or dedicated agent-facing docs, and no independent third-party corroboration of SDK quality beyond the hands-on probe.

   • [probe] “PROBE api-live: GET https://chat.zulip.org/api/v1/server_settings → HTTP 200 {"result":"success",...,"zulip_version":"12.0-919-gb1bd7d7d3e"}…”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [probe] “PROBE cli-runtime: pip install zulip (v0.9.1) → official zulip-send CLI installs from PyPI and runs headlessly (--help prints usage for send…”
   • [claimed-docs] “Send a message”

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Zulip—none0/10

   Evidence only shows Zulip supports *incoming* webhooks for pushing external events into Zulip (zulip-docs-19) and a bot framework for reacting to messages (zulip-docs-4/12/24), but nothing documents an outgoing webhook mechanism for an AI-native user to subscribe to Zulip's own events. missing for 10: documentation of outgoing/subscription webhooks, event-type configuration, or webhook payload schema for external consumers.

   • [claimed-docs] “Incoming webhooks”
   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”

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

   No evidence of any AI-generated insights, summarization, or suggestion features surfaced within Zulip itself; evidence covers topics, channels, search, bots (rule-based), integrations, and hosting/export, none of which involve AI analysis of data. Missing for 10: any AI summarization/insight feature, AI-generated suggestions, or documented AI assistant surfaced in the product UI.

   ⚑ 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
   Zulip~partialprobed5/10

   Zulip supports bots that run autonomously in the background via its bot API framework and Botserver for production deployment, plus a full REST/OpenAPI API and CLI tools for scripting automations. However, this is a general chatbot/integration framework rather than an AI-native agentic automation platform with built-in scheduling, triggers, or autonomous task orchestration. Missing for 10: evidence of AI-specific agent orchestration, native scheduling/triggering beyond message-reactive bots, and independent hands-on validation that bots run reliably unattended in production.

   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”
   • [claimed-docs] “Eventually, you’ll probably want to run it in a production environment where it’ll stay up, by deploying it on a server using the Zulip Bots…”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [probe] “PROBE cli-runtime: pip install zulip (v0.9.1) → official zulip-send CLI installs from PyPI and runs headlessly (--help prints usage for send…”

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

   Zulip's evidence covers bots/integrations built by users via its API, but there is no mention of a built-in AI assistant that users can delegate tasks to directly within the product.

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

   Zulip's docs describe channels, topics, search filters, and a bot API for building reactive bots, but none of this constitutes an AI-native natural-language command interface for operating the product itself — no evidence of NLU-driven commands, AI assistant, or agentic control layer. missing for 10: any natural-language command parsing/interface, AI assistant for operating Zulip, evidence of NL-driven actions beyond keyword search filters.

   • [claimed-docs] “channel:design has:image new logo: Search for messages in #design that include an image and contain the keywords new and logo.”
   • [claimed-docs] “Zulip also offers a wide array of search filters, which can be used on their own, or in combination with keywords.”
   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”

   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 to Zulip
   Zulip~partialprobed5/10

   Zulip publishes a full machine-readable OpenAPI 3.0 spec for its REST API (zulip-probe-5) and a public API reference site with example endpoints like 'Send a message' (zulip-docs-5), and the API is confirmed live and functional hands-on (zulip-probe-4). However, there is no direct evidence that the API reference page itself offers interactive 'try it out' runnable examples in-browser rather than just documented curl/code snippets. Missing for 10: explicit confirmation of an in-browser interactive/try-it console on the API docs, independent user reports of using runnable examples.

   • [claimed-docs] “Send a message”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [probe] “PROBE api-live: GET https://chat.zulip.org/api/v1/server_settings → HTTP 200 {"result":"success",...,"zulip_version":"12.0-919-gb1bd7d7d3e"}…”

   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 Zulip
   Zulip✓fullprobed9/10

   Zulip's REST API ships a machine-readable OpenAPI 3.0.1 spec (zulip.yaml, ~1.5MB) directly in its repo, confirmed hands-on, and the live API docs at zulip.com/api/ are generated from this spec. Missing for 10: no dedicated discoverable download link/endpoint on the main docs site itself (openapi.json probes 404'd, so it's not trivially discoverable without knowing the GitHub path).

   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [claimed-docs] “Send a message”
   • [probe] “PROBE openapi: all candidate paths 404 (https://zulip.com/openapi.json, https://zulip.com/swagger.json, https://zulip.com/api/openapi.json, …”

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

   The evidence pack covers self-hosting, export/import, integrations, and API access, but nowhere mentions a dedicated sandbox, staging, or test-mode instance that is separate from production data. Nothing describes a way to safely test bots/integrations against non-production data without standing up and fully configuring an entirely separate self-hosted server.

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

   While Zulip clearly has a documented, machine-readable REST API (OpenAPI spec, live endpoint, CLI) per zulip-docs-5, zulip-probe-4/5/6, the evidence pack contains no mention of API versioning scheme or a deprecation policy for changed/removed endpoints. Missing for 10: documentation of API version numbers, backward-compatibility guarantees, or a deprecation/changelog process.

   ⚑ 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 Zulip
   Zulip✓fullclaimed7/10

   Zulip provides an official integrations directory (zulip.com/integrations) listing 130+ native prebuilt integrations plus Zapier/IFTTT for hundreds more, which team-admins can browse and install/configure (e.g., via incoming webhooks) without custom coding. missing for 10: no evidence of an in-app 'install with one click' marketplace UI or independent hands-on confirmation of the install flow.

   • [claimed-docs] “Over 130 native integrations. And hundreds more through Zapier and IFTTT.”
   • [claimed-docs] “Over 130 native integrations.”
   • [claimed-docs] “Incoming webhooks”

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

   Zulip's docs describe an interactive-bot framework that reacts to messages, but there is no evidence of a slash-command registration API or mechanism where a developer registers a custom command invoked via '/' in the message box, distinct from Slack-style slash commands.

   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Eventually, you’ll probably want to run it in a production environment where it’ll stay up, by deploying it on a server using the Zulip Bots…”

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

   Evidence covers Zulip's bot/API framework, integrations, and messaging features but contains no mention of interactive UI elements like modals, buttons, or structured message layouts within chat (unlike Slack's Block Kit or similar). Missing for 10: any documentation of interactive message components, modal dialogs, button widgets, or structured layout building blocks for developers.

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

   While Zulip exposes a full REST API and CLI tooling (zulip-probe-5, zulip-probe-6, zulip-docs-5) that could theoretically be scripted, the evidence pack contains no documentation or hands-on proof of a bulk/batch endpoint (e.g., mass message updates, bulk channel management, batch subscribe/unsubscribe) that lets an AI-native user act on many items in one call. missing for 10: documented bulk-update/bulk-delete/batch endpoints, evidence of batch request support, any example of operating on multiple items in a single API call.

   • [claimed-docs] “Send a message”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [probe] “PROBE cli-runtime: pip install zulip (v0.9.1) → official zulip-send CLI installs from PyPI and runs headlessly (--help prints usage for send…”

   proof ↗⚑ 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
   Zulip~partialclaimed4/10

   Zulip has no documented native rules/automation engine; the closest capabilities are a bot framework requiring custom code (zulip-docs-4/12/24) and webhook/Zapier/IFTTT integrations (zulip-docs-9/19) that let external tools trigger actions on Zulip events. This is automation via third-party glue or coding, not a built-in 'define rules' feature. Missing for 10: a native no-code rules/trigger builder, first-party documentation of event-condition-action automation, and any evidence of it working out-of-the-box without external services or custom bot code.

   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Over 130 native integrations. And hundreds more through Zapier and IFTTT.”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”
   • [claimed-docs] “Incoming webhooks”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”

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

   Zulip is a team chat platform with bots, integrations, and an API for sending messages, but there is no evidence of any scheduler, cron-like feature, or recurring workflow/job automation capability — only reactive bots and one-off messages are documented.

   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”
   • [claimed-docs] “Eventually, you’ll probably want to run it in a production environment where it’ll stay up, by deploying it on a server using the Zulip Bots…”
   • [claimed-docs] “Send a message”

   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

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
   Zulip~partialprobed6/10

   Zulip's documented bot framework lets you write and run custom bots (including via a dedicated Botserver for production) that 'react to messages,' and the full REST/API surface (confirmed live and via OpenAPI spec) supports sending/receiving messages, which is the technical substrate needed for an AI-agent-as-channel-member use case. However, this requires custom bot development rather than a first-party 'add an AI agent to a channel' feature, and there's no explicit documentation or evidence of native @-mention-triggered AI agent participation out of the box. Missing for 10: explicit first-party AI-agent bot support (vs generic bot framework), documentation of mention-triggered behavior specifically, and independent/hands-on confirmation of an AI agent actually participating in a channel conversation.

   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”
   • [claimed-docs] “Eventually, you’ll probably want to run it in a production environment where it’ll stay up, by deploying it on a server using the Zulip Bots…”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [probe] “PROBE api-live: GET https://chat.zulip.org/api/v1/server_settings → HTTP 200 {"result":"success",...,"zulip_version":"12.0-919-gb1bd7d7d3e"}…”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”

   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 Zulip
   Zulip✓fullprobed7/10

   Zulip ships a documented, versioned REST API (OpenAPI spec, live endpoint confirmed) with a bot framework specifically designed to read and react to channel messages and a documented message-sending endpoint, plus an official CLI/Python client for scripting — bots authenticate via their own per-bot API key, which functions as a scoped credential distinct from a user's. missing for 10: explicit documentation of granular token scopes/permissions (vs. just per-bot keys), and an explicit documented 'read messages' endpoint (only send-message and bot-reacts-to-message are directly evidenced).

   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Send a message”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”
   • [claimed-docs] “Eventually, you’ll probably want to run it in a production environment where it’ll stay up, by deploying it on a server using the Zulip Bots…”
   • [probe] “PROBE api-live: GET https://chat.zulip.org/api/v1/server_settings → HTTP 200 {"result":"success",...,"zulip_version":"12.0-919-gb1bd7d7d3e"}…”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [probe] “PROBE cli-runtime: pip install zulip (v0.9.1) → official zulip-send CLI installs from PyPI and runs headlessly (--help prints usage for send…”

   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 Zulip
   Zulip✓fullprobed8/10

   Zulip explicitly documents incoming webhooks as a native integration type (zulip-docs-19) alongside 130+ native integrations (zulip-docs-9/13), and its API includes a straightforward 'send a message' endpoint (zulip-docs-5) backed by a full OpenAPI spec (zulip-probe-5) and live-verified API (zulip-probe-4). This matches the standard incoming-webhook-posts-to-channel pattern. Missing for 10: a first-party doc snippet showing the exact incoming-webhook URL format/config screen, and independent third-party confirmation of webhook setup ease.

   • [claimed-docs] “Incoming webhooks”
   • [claimed-docs] “Over 130 native integrations. And hundreds more through Zapier and IFTTT.”
   • [claimed-docs] “Send a message”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [probe] “PROBE api-live: GET https://chat.zulip.org/api/v1/server_settings → HTTP 200 {"result":"success",...,"zulip_version":"12.0-919-gb1bd7d7d3e"}…”

   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 Zulip
   Zulip✓fullprobed7/10

   Zulip explicitly documents a bot framework that lets developers write custom bots that 'react to messages in Zulip' in real time, deployable persistently via the Zulip Botserver, backed by a full OpenAPI-documented REST API and a working live API endpoint plus an installable CLI/client library for scripting integrations. This maps to Zulip's known events/register API model for real-time bots, though the evidence pack never names the events/register endpoints or long-polling mechanics explicitly. Missing for 10: explicit documentation/citation of the events/register API endpoints and real-time event queue mechanics, and independent hands-on confirmation of a bot actually receiving live events.

   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”
   • [claimed-docs] “Eventually, you’ll probably want to run it in a production environment where it’ll stay up, by deploying it on a server using the Zulip Bots…”
   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [probe] “PROBE api-live: GET https://chat.zulip.org/api/v1/server_settings → HTTP 200 {"result":"success",...,"zulip_version":"12.0-919-gb1bd7d7d3e"}…”
   • [probe] “PROBE cli-runtime: pip install zulip (v0.9.1) → official zulip-send CLI installs from PyPI and runs headlessly (--help prints usage for send…”

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

   No evidence of any meeting/huddle recording, transcription, or AI-generated recap/notes feature; Zulip's evidence covers topics, channels, bots, integrations, and self-hosting but nothing about calls, huddles, or AI summarization of conversations.

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

   No evidence in the pack mentions audio/video calling features in Zulip; all documentation and community references cover topics, channels, search, bots, integrations, export/import, and self-hosting, but nothing about starting a call from a channel or DM.

   ⚑ 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

External collaboration

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

   weight 2 · round to Zulip
   Zulip~partialclaimed3/10

   Zulip docs mention that 'guests' are a distinct role with restricted channel subscription ability (zulip-docs-22), implying a guest-account mechanism exists, but the evidence pack contains no documentation of inviting external partners, guest account setup/permissions, or any shared-channel/cross-organization collaboration feature. Missing for 10: explicit guest-invite workflow docs, permission scoping details for guests, and any shared-channel-with-external-org capability or independent confirmation it works in practice.

   • [claimed-docs] “Everyone other than guests can subscribe to any public or web-public channel.”

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

   Docs confirm channels can be public/private/web-public with subscription controls (zulip-docs-2, zulip-docs-22), and channel-scoped search/export tools acknowledge private channel membership boundaries (zulip-docs-14, zulip-docs-17). However, there is no explicit documentation of admin-side membership management workflows (adding/removing members, role-based permissions per channel) or granular channel permission settings. missing for 10: detailed admin UI/API for managing channel membership and permissions, evidence of private channel invite-only enforcement, independent corroboration of admin controls in practice.

   • [claimed-docs] “Subscribing to a channel makes conversations in that channel appear in your inbox, recent conversations, combined feed and left sidebar.”
   • [claimed-docs] “Everyone other than guests can subscribe to any public or web-public channel.”
   • [claimed-docs] “Public and private data (with consent): Everything in the export of public data, plus all the private channel messages and direct messages t…”
   • [claimed-docs] “channels:public: Search messages in all public and web-public channels.”

   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 Zulip
   Zulip✓fullcommunity8/10

   Zulip's core topic-based threading model lets users reply within a topic to keep side discussions attached to the original conversation, and community evidence strongly corroborates this as a standout feature ('the killer feature', 'fundamentally superior model' to Slack threads). Docs describe starting/joining topics and searching within them, and admins have the same messaging capabilities as any user. missing for 10: explicit admin-specific documentation on replying in threads (evidence is general-user focused), and some community reports note UX friction/confusion for non-technical users when threading.

   • [claimed-docs] “To get the full benefits of Zulip's topic model, when starting a new conversation, you should start a new topic!”
   • [claimed-docs] “Lots of conversations can happen in the same channel at the same time, each in its own topic. You never have to worry about interrupting — e…”
   • [claimed-docs] “Click the start a new topic () button next to the name of the channel where you’d like to start a conversation.”
   • [community] “The 'threaded' part is key here. Slack threads are useless compared to Zulip. In Zulip you can create threads on the fly from existing messa…”
   • [community] “Threads are one major reason I like Zulip over Slack, but speed is another... For some reason when I use Slack, the keys feel mushy.”
   • [community] “I used Zulip while at Akamai... My experience was so positive that I've continued to evangelize it at other companies since then... The most…”
   • [community] “I use Zulip all the time at work. It is ugly, sometimes will post to a different thread than you expect... has an infuriating tick that if y…”

   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 Zulip
   Zulip✓fullcommunity8/10

   Zulip's topic model is core to the product: docs explain starting new topics per conversation, subscribing to channels surfaces conversations in inbox/feed, and topic-scoped search lets admins filter busy channels. Community reports strongly corroborate that this threading model is 'fundamentally superior' to Slack for following busy, high-volume discussions without being overwhelmed, and the 'all messages' view helps catch up chronologically across channels. Missing for 10: independent measurement of catch-up efficiency and some community reports note UX friction (miscasting to wrong topic, non-technical user confusion) that slightly tempers the ideal experience.

   • [claimed-docs] “To get the full benefits of Zulip's topic model, when starting a new conversation, you should start a new topic!”
   • [claimed-docs] “Subscribing to a channel makes conversations in that channel appear in your inbox, recent conversations, combined feed and left sidebar.”
   • [claimed-docs] “channel:design has:image new logo: Search for messages in #design that include an image and contain the keywords new and logo.”
   • [claimed-docs] “Lots of conversations can happen in the same channel at the same time, each in its own topic. You never have to worry about interrupting — e…”
   • [claimed-docs] “Click the start a new topic () button next to the name of the channel where you’d like to start a conversation.”
   • [community] “We've been using Zulip internally for a couple of years now... It lets us have real, ongoing, and substantive conversations with a large num…”
   • [community] “The 'threaded' part is key here. Slack threads are useless compared to Zulip. In Zulip you can create threads on the fly from existing messa…”
   • [community] “We used Zulip (then a commercial product) at FoundationDB, and really liked it... the killer feature is the 'all messages' view that merges …”
   • [community] “I used Zulip while at Akamai... My experience was so positive that I've continued to evangelize it at other companies since then... The most…”
   • [community] “I use Zulip all the time at work. It is ugly, sometimes will post to a different thread than you expect... has an infuriating tick that if y…”
   • [community] “Zulip seemed like technically the most polished product... what ended up being the showstopper was that new users were very confused about h…”

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

   The evidence pack contains no documentation or mentions of per-channel, per-keyword, or scheduled notification controls (e.g., no citations about notification settings, alert words, or do-not-disturb/quiet hours) — only topics, channels, search, bots, and export/import material. Notification tuning is a standard, fair axis for a chat product, but nothing in the pack demonstrates it.

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

   No evidence pack items mention audit logs, admin action logs, or user activity tracking features in Zulip; the evidence covers topics, channels, search, bots, integrations, and export/import tools but nothing about auditability of admin/user actions.

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

   The evidence pack only covers data export/import tools for migrating organizations, with no mention of configurable message retention policies, automatic deletion schedules, or legal hold/eDiscovery preservation features. No documentation or community evidence addresses compliance-driven retention enforcement.

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

   Zulip's docs explicitly describe an export tool that can include 'public and private data (with consent)' — private channel messages and DMs from consenting members — in a machine-readable export format used for migration/backup, directly matching the compliance-export story for a team-admin. This is corroborated by general export/import documentation and self-hosting docs confirming full data portability. Missing for 10: independent/hands-on verification of the export tool's exact output format and confirmation of admin-level override for private data without member consent.

   • [claimed-docs] “Zulip has high quality export tools that can be used to migrate between the hosted Zulip Cloud service and your own servers.”
   • [claimed-docs] “Public and private data (with consent): Everything in the export of public data, plus all the private channel messages and direct messages t…”
   • [claimed-docs] “You can move freely between Zulip Cloud hosting and your own servers with our high quality export and import tools.”
   • [claimed-docs] “To import data from Slack, Mattermost, Rocket.Chat, Zulip Cloud, or another Zulip server, follow the linked instructions.”

   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 to Zulip
   Zulip~partialprobed7/10

   Zulip ships a large, machine-readable OpenAPI spec (~1.5MB) covering messaging, bots, integrations, and administration, with a live public endpoint confirming the API works and an official CLI/bot framework for scripting (zulip-probe-5, zulip-probe-4, zulip-probe-6, zulip-docs-5, zulip-docs-12). However, there is no explicit vendor or independent claim that every UI action (e.g., search filters, topic management UI nuances) has a 1:1 API equivalent. Missing for 10: explicit UI-API parity documentation/audit, independent confirmation that all UI-only features (e.g., advanced search UX, settings toggles) are scriptable via API.

   • [probe] “PROBE openapi-spec: fetched zerver/openapi/zulip.yaml from the Zulip repo → HTTP 200, ~1.5 MB spec beginning 'openapi: 3.0.1' — the complete…”
   • [probe] “PROBE api-live: GET https://chat.zulip.org/api/v1/server_settings → HTTP 200 {"result":"success",...,"zulip_version":"12.0-919-gb1bd7d7d3e"}…”
   • [probe] “PROBE cli-runtime: pip install zulip (v0.9.1) → official zulip-send CLI installs from PyPI and runs headlessly (--help prints usage for send…”
   • [claimed-docs] “Send a message”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”

   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 Zulip
   Zulip✓fullcommunity8/10

   Zulip documents high-quality export tools that let users take both public and private (consented) data out in open formats, explicitly for migrating away from Zulip Cloud to self-hosted servers, and is fully open-source/self-hostable so no vendor lock-in exists. This directly matches 'export data and leave.' Missing for 10: no independent/hands-on verification of the export file format's openness or completeness, and no community testimonial specifically confirming a successful full data exodus.

   • [claimed-docs] “Zulip has high quality export tools that can be used to migrate between the hosted Zulip Cloud service and your own servers.”
   • [claimed-docs] “You can move freely between Zulip Cloud hosting and your own servers with our high quality export and import tools.”
   • [claimed-docs] “Public and private data (with consent): Everything in the export of public data, plus all the private channel messages and direct messages t…”
   • [claimed-docs] “When you self-host Zulip, you get the same software as our Zulip Cloud customers.”
   • [community] “Zulip is my favorite modern chat program because it's actually 100% FOSS, unlike Mattermost and RocketChat, which are only 'open core'.”

   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 drawn
   Zulip✓fullcommunity8/10

   Zulip's source code is hosted publicly on GitHub with a contributing guide, and Zulip is widely documented (including in community evidence) as being fully open-source (100% FOSS, not open-core), consistent with its known Apache 2.0 licensing. Missing for 10: explicit citation of the license file/text itself and independent third-party confirmation of the specific license terms.

   • [github] “Contributing code. Check out our guide for new contributors to get started.”
   • [community] “Zulip is my favorite modern chat program because it's actually 100% FOSS, unlike Mattermost and RocketChat, which are only 'open core'.”

   proof ↗⚑ 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
   Zulip~partialcommunity7/10

   Zulip is documented as fully open-source and self-hostable, with official production install docs, import/export tools to migrate between cloud and self-host, and a GitHub repo for contributing (zulip-docs-8, zulip-docs-25, zulip-docs-7, zulip-gh-1). However, community hands-on reports describe real friction: installs require a dedicated server/VM with poor containerization support, heavy RAM requirements, and limited distro support beyond Ubuntu (zulip-comm-18, zulip-comm-13, zulip-comm-14, zulip-comm-3). Missing for 10: independent verification that installation friction has been resolved, broader OS/container support, and clearer resource-requirement documentation.

   • [claimed-docs] “When you self-host Zulip, you get the same software as our Zulip Cloud customers.”
   • [claimed-docs] “install a self-hosted Zulip server on a system of your choice”
   • [claimed-docs] “To import data from Slack, Mattermost, Rocket.Chat, Zulip Cloud, or another Zulip server, follow the linked instructions.”
   • [claimed-docs] “Then, run the installer, providing your email address and the public hostname that users will be able to access your server with”
   • [github] “Contributing code. Check out our guide for new contributors to get started.”
   • [community] “On the downside, if you are self-hosting, Zulip requires a dedicated server (or VM). There are some efforts to make it run in a container bu…”
   • [community] “I love Zulip... what Zulip lacks right now is polish. Server installation for example is a mess. You basically need a dedicated Debian machi…”
   • [community] “The install procedure looks like a bad joke. So if I'm using RHEL, Fedora, Arch or any other Linux distribution, tough luck. If they're supp…”
   • [community] “Something has gone horribly wrong when a chat server can barely run on 2G... recommended 4GB of RAM for production use.”

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

   Zulip's self-hosting docs let users install the server 'on a system of your choice' anywhere they want, effectively giving control over data location/residency, and full export/import tools support migrating data between Zulip Cloud and self-hosted servers. However, there is no evidence of a built-in region-selection feature within Zulip Cloud itself (e.g., choosing EU vs US data centers) — the only residency mechanism is self-hosting your own infrastructure. Missing for 10: explicit multi-region hosting options within Zulip Cloud, documented data-residency guarantees, and independent confirmation of regional deployment support.

   • [claimed-docs] “When you self-host Zulip, you get the same software as our Zulip Cloud customers.”
   • [claimed-docs] “install a self-hosted Zulip server on a system of your choice”
   • [claimed-docs] “Zulip has high quality export tools that can be used to migrate between the hosted Zulip Cloud service and your own servers.”
   • [claimed-docs] “You can move freely between Zulip Cloud hosting and your own servers with our high quality export and import tools.”
   • [claimed-docs] “Then, run the installer, providing your email address and the public hostname that users will be able to access your server with”

   proof ↗⚑ 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
   Zulip—none0/10

   No evidence in the pack addresses AI training data usage, opt-out controls, or any explicit AI-training privacy policy for Zulip; self-hosting is mentioned but not tied to preventing AI training use of data. missing for 10: explicit policy/statement on AI model training use of data, opt-out mechanism, or contractual guarantee against training use.

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

   Zulip's self-hosting option and data export/import tools (including exporting private data with consent) give users significant control over where their data lives and how it can be extracted or migrated, which touches on data retention/portability. However, there is no direct evidence of message retention policies, auto-deletion settings, or a documented data-deletion workflow for accounts/messages. Missing for 10: explicit retention-policy controls, message/account deletion documentation, and any GDPR-style data-deletion API or admin setting.

   • [claimed-docs] “Zulip has high quality export tools that can be used to migrate between the hosted Zulip Cloud service and your own servers.”
   • [claimed-docs] “You can move freely between Zulip Cloud hosting and your own servers with our high quality export and import tools.”
   • [claimed-docs] “Public and private data (with consent): Everything in the export of public data, plus all the private channel messages and direct messages t…”
   • [claimed-docs] “When you self-host Zulip, you get the same software as our Zulip Cloud customers.”
   • [claimed-docs] “install a self-hosted Zulip server on a system of your choice”

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

   No evidence in the pack addresses telemetry, usage tracking, analytics collection, or an opt-out setting for Zulip; the self-hosting docs discuss data export/import and deployment but never mention telemetry 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
   Zulip—none0/10

   No evidence of any AI-generated summary, recap, or digest feature for missed channels/threads; documentation focuses on topics, search, bots, integrations, and export/import but never mentions AI summarization.

   ⚑ 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 Zulip
   Zulip~partialcommunity6/10

   Zulip's docs confirm a full-text search with real filter syntax (channel:design, has:image, channels:public) and state it offers 'a wide array of search filters', but the evidence pack never shows explicit sender: or date-range filter syntax, and one community report from 2016 claims the search function 'barely works'. missing for 10: explicit sender: and date/time filter documentation, independent verification of search accuracy, resolution of the community complaint about search reliability.

   • [claimed-docs] “channel:design has:image new logo: Search for messages in #design that include an image and contain the keywords new and logo.”
   • [claimed-docs] “channels:public: Search messages in all public and web-public channels.”
   • [claimed-docs] “Zulip also offers a wide array of search filters, which can be used on their own, or in combination with keywords.”
   • [community] “I love Zulip... what Zulip lacks right now is polish. Server installation for example is a mess. You basically need a dedicated Debian machi…”

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

   Zulip's evidence shows only custom-coded bots, webhooks, and 130+ integrations plus optional Zapier/IFTTT connections (external tools), but no built-in no-code workflow/automation builder with triggers, schedules, or form submissions inside the chat product itself.

   • [claimed-docs] “Zulip's API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot”
   • [claimed-docs] “Over 130 native integrations. And hundreds more through Zapier and IFTTT.”
   • [claimed-docs] “Zulip’s API has a powerful framework for interactive bots that react to messages in Zulip. You can write and run a custom bot, or run an exi…”
   • [claimed-docs] “Incoming webhooks”

   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