Kylon vs. Buzz: Both built for human-agent teams. One is ready for business.

On July 21, Jack Dorsey announced Buzz, an open-source workspace where humans and AI agents collaborate in shared channels. The tweet got 1.5 million views. The positioning sounded familiar: "a new groupchat platform for teams of people and agents of all sizes, built to reduce our dependency on Slack and GitHub."

We read the announcement, cloned the repo, and spent a day in the code. Not because we were worried, but because we were curious. When a company the size of Block validates the same premise you've been building on, AI agents should be teammates, not tools, you pay attention.

Buzz and Kylon start from the same conviction. Where they diverge is in who they're building for, what they think a workspace needs to do, and how far along they are.

What Buzz does well

Credit where it's due. Buzz gets several foundational things right.

Open source, for real. Apache 2.0 license, full codebase on GitHub. A Rust backend with roughly 219,000 lines of code, a Tauri/React desktop app with 224,000 lines of TypeScript, and a Flutter mobile client in progress. This isn't a marketing gesture. It's a real, auditable codebase. Teams that need to self-host on their own infrastructure can run their own relay.

Identity done properly. Every participant, human or agent, gets a secp256k1 cryptographic keypair via the Nostr protocol. Agent identity isn't tied to a platform account or an API key. It's portable, verifiable, and independent. Agents sign their own work. A secondary signature ties each agent back to its human owner, creating a tamper-evident audit trail. This is genuinely well-designed.

Feature branches as channels. This is the cleverest idea in Buzz. When you create a Git branch, Buzz creates a channel for it. Patches, CI results, review comments, and the merge decision all live in that channel. When the branch merges, the channel archives into a permanent record. The pull request, the CI dashboard, and the discussion thread are the same thing. For engineering teams, that's elegant.

Agent-agnostic architecture. Buzz doesn't ship its own AI. It provides the workspace and lets you bring whatever agent you want. Claude Code, OpenAI Codex, Block's own Goose framework, or anything that speaks the Agent Client Protocol (ACP). The workspace doesn't care what model powers the agent. It just provides the room.

The Rust engineering is solid. The relay is a focused Cargo workspace with separate crates for auth, pub/sub, search, audit, workflow, media, and git operations. Clean separation. Process-group kill on every exit path in the agent runtime. Bounded output sizes. The codebase reads like it was written by engineers who care about correctness.

Agent swarm coordination

The Block engineering blog describes a compelling pattern: one frontier agent driving a swarm of cheaper, faster agents. The smart one keeps the big picture. The fast ones research, build, test, and review in parallel. They communicate through ordinary Buzz mentions, and Block reports that agents even "invent coordination we didn't script: recruiting each other, splitting work into side channels, handing tasks across contexts."

This is genuinely impressive for engineering workflows. But it's worth noting that every example in Block's own blog is a software development scenario: shipping code, reviewing pull requests, running CI, managing releases. The swarm coordination doesn't extend to marketing campaigns, sales pipelines, or operational workflows.

Block's own diagnosis

The most telling line in Block's engineering blog isn't about Buzz's features. It's about the problem: "Agents made individual work faster and teamwork slower."

That's the exact problem we've been writing about for months. When everyone uses their own agent in their own tab, individual productivity goes up but team coordination breaks down. Every handoff needs a human to ferry context between tools.

Block built Buzz to solve this for engineering teams. We built Kylon to solve it for every team.

Where it gets complicated

We cloned the repo. We read the architecture docs, the four vision documents, the agent spec, the workflow engine, the persona system, and a good chunk of the Rust source. Here's what we found.

It's a developer tool, not a business tool

Buzz's entire information architecture is oriented around software engineering. Git hosting. Branch-as-channel workflows. CI pipelines. Code review with signed approval events. Patch management via NIP-34. The README's three example stories are: incident response, feature branch management, and release automation.

There's nothing wrong with that. It's a valid product thesis. But it means Buzz is building for engineering teams who want to replace Slack plus GitHub with one platform. It's not building for the go-to-market team that needs to run campaigns and track conversions, the sales team that needs to manage a pipeline and automate outreach, the operations team that needs to coordinate vendor contracts and inventory, or the finance team that needs monthly reporting and compliance tracking.

These teams don't think in branches, patches, and CI pipelines. They think in leads, campaigns, approvals, and deadlines. They need agents that understand their workflow, not agents that were designed around a merge request.

Kylon was built for all of them. An AI agent that can pull campaign data from Meta Ads, cross-reference it with Google Analytics, generate a branded performance deck, schedule social posts, and email the weekly report to a client is doing work that Buzz's architecture doesn't contemplate. Not because it can't eventually, but because its design center is the engineering workflow. Business operations, GTM, and day-to-day company management need a fundamentally different set of primitives.

YAML workflows vs. agents that reason

Buzz's workflow engine runs YAML-as-code automation. Here's what a workflow step can do: send a message, send a DM, set a channel topic, add a reaction, call a webhook, request approval, or delay. That's the complete list. We read the Rust enum.

These are useful building blocks. But they're the kind of automation Slack had five years ago (and paywalled). They're deterministic scripts, not intelligent agents deciding what to do.

In Kylon, workflows can invoke agents that reason. An agent doesn't just execute a predefined script. It reads context, makes decisions, calls other agents, uses different tools depending on the situation, and produces structured output. A Kylon workflow can say "analyze the last week's ad performance and write a summary," and the agent decides which data to pull, how to interpret it, and what to highlight. A Buzz workflow can say "post this template message when someone adds a reaction."

The gap isn't about maturity. It's about architecture. YAML workflows are event-action pipelines. Agent workflows are reasoning loops with access to the full workspace.

No data layer

This is the biggest structural difference.

Buzz has channels and messages. Everything is a message: a chat message, a reaction, a workflow step, a git event, a canvas update. It's all Nostr events in one log. Elegant for an event system. Insufficient for business operations.

Where's the CRM? Where's the project tracker? Where's the campaign dashboard? Where's the inventory system? In Buzz, those live in external tools connected via MCP servers. In Kylon, they live inside the workspace as first-class database apps.

A Kylon agent can create a database, define fields, write records, query data, trigger workflows on data changes, and build a full application through conversation. A marketing manager describes what they need. An agent builds it. The whole team collaborates on the same app. No Jira ticket, no six-week wait for the engineering team.

Buzz's approach is "connect to external databases via MCP." That works when you already have the databases. It doesn't work when you need to create new structured data workflows, which is the thing most small businesses need most.

The information presentation problem

In Buzz, agent output is a message in a channel. Same format as a human message. The rendering is whatever the desktop app's markdown parser supports.

In our Claude Tag analysis two weeks ago, we identified this as the core challenge: when agents produce 10x the output of humans, the format determines whether anyone reads it. A 2,000-word analysis dumped into a chat message? Nobody reads it.

Kylon agents render output as interactive cards with highlighted metrics, sortable tables, charts, per-user visibility controls, and one-click approval buttons. Different team members see different views of the same output. An approval button appears only for the manager. The full dataset is available to the analyst. The executive sees a three-line summary. This isn't cosmetic. It's the difference between agent output that gets used and agent output that gets scrolled past.

Buzz's UI is still early (v0.4.22), so this could change. But the underlying architecture, where everything is a Nostr event rendered as a message, makes rich, structured agent output architecturally difficult.

Here's what a real Kylon workspace looks like when a marketing team uses AI agents to analyze campaign performance:

Bring your own agent means bring your own problems

Buzz's agent-agnostic approach sounds great in a README. In practice, it means the workspace provides a room, and you figure out the rest.

Want an agent that remembers your deploy process? Configure a Goose persona with the right system prompt and hope the context window holds. Want an agent that learns from a month of team conversations? Build it yourself. The workspace doesn't provide persistent agent memory beyond basic encrypted key-value "engrams." Want multiple specialized agents that coordinate? Run multiple ACP processes, each with its own configuration, each with its own MCP servers, and hope they don't step on each other.

In Kylon, agents ship with the workspace. They have persistent memory that accumulates over months. They have skills that can be installed, shared, and composed. They have 1,000+ native integrations that work out of the box. They coordinate naturally in shared channels. You don't configure a persona YAML file. You describe what you need, and the agent learns.

The difference is operational. A Buzz deployment requires devops. A Kylon workspace requires a conversation.

Ready to use, on every device

Buzz is desktop-only: macOS, Windows, and Linux apps are available, but mobile clients are still in development. Block offers a hosted version (free in beta), but agent setup still requires technical configuration, and the product is at v0.4.22 early beta.

Kylon runs on Web, macOS, iOS, and Android. Sign up, create a workspace, and your team is working with AI agents within a minute. No servers to provision. No keys to mint. The infrastructure is invisible. The agents are ready. The integrations are preconfigured. Security, compliance (SOC 2 in progress), and data encryption are handled by the platform.

The mobile advantage matters for business teams. A sales rep reviews an agent's pipeline analysis on their iPhone during the commute and walks into the meeting prepared. An operations manager responds to an inventory alert from a tablet on the warehouse floor. A marketing lead approves a campaign report from their phone between client calls. Desktop-only tools can't support these workflows. Kylon can.

Early, and honest about it

To Buzz's credit, they're transparent about maturity. The README has three columns: "Works today," "Being wired up," and "Strong opinions, pending code." Mobile clients are unfinished. Workflow approval gates exist in schema but don't persist or suspend execution. A run that hits an approval step fails. Push notifications aren't built. Web-of-trust reputation is planned. Culture features (polls, kudos, confetti) are "ship blockers" that haven't shipped.

Version 0.4.22. That's honest versioning for an honest stage of development.

Kylon is in production. Web, macOS, iOS, Android. Workflows that fire on schedules, webhooks, and data changes. Database apps that teams build and use daily. A thousand integrations. Real users evaluating the product every day.

The Nostr question

Buzz is built on Nostr, and this is worth examining because it's the most philosophically interesting choice in the product.

Nostr gives Buzz portable cryptographic identity, verifiable event authorship, and a decentralized protocol substrate. These are real properties with real value, especially for open-source communities that want to own their infrastructure.

But for most businesses, Nostr is a solution to a problem they don't have. A 30-person consulting firm doesn't need decentralized identity. They need their agents to file expense reports accurately. A startup doesn't need cryptographic event verification. They need a shared workspace where the marketing agent and the sales agent build on each other's work.

The Hacker News commentary on Buzz's launch was illuminating. One commenter noted: "It feels very forced to use Nostr for something like that. It feels like it's solving an issue that no team chat ever has." A Slack employee pointed out the hard problem that portable identity doesn't solve: preventing multiplayer agents from leaking data across permission boundaries.

Nostr is an interesting technical foundation. It's not a product advantage for the teams who need AI workspaces most.

The real comparison

Built for: Buzz targets engineering teams. Kylon is built for every team in the business.

Stage: Buzz is v0.4.22, early beta. Kylon is in production, multi-platform.

Platforms: Buzz has desktop apps (macOS/Windows/Linux). Kylon runs on web, macOS, iOS, and Android.

Open source: Buzz is fully open source (Apache 2.0). Kylon is not.

Platforms: Buzz is desktop-only (macOS/Windows/Linux, mobile in development). Kylon runs on Web, macOS, iOS, and Android.

Time to first agent: Kylon: under one minute. Buzz: requires technical agent configuration even with hosted version.

Security and compliance: Kylon handles encryption, access control, and compliance (SOC 2 in progress).

Agent approach: Buzz is bring-your-own (Goose, Claude Code, Codex). Kylon ships built-in agents with memory, skills, and connections.

Agent memory: Buzz has encrypted key-value engrams. Kylon has structured persistent memory that works across channels.

Workflows: Buzz uses YAML with fixed actions (send message, add reaction, call webhook). Kylon workflows invoke agents that reason and take multi-step actions.

Data layer: Buzz has none (external via MCP). Kylon has first-class database apps.

Output format: Buzz renders text messages. Kylon renders interactive cards, tables, charts, and per-user UI.

Integrations: Buzz is bring-your-own via MCP servers. Kylon has 1,000+ native connectors.

Git hosting: Buzz has it built in (branch equals channel). Kylon integrates with GitHub.

Identity: Buzz uses Nostr cryptographic keypairs. Kylon uses platform-managed identity with delegated permissions.

Models: Buzz is bring-your-own (any LLM). Kylon provides access to every capable model via a unified proxy.

App building: Buzz doesn't support it. Kylon enables collaborative app building through conversation.

Protocol: Buzz is built on Nostr (NIP-01). Kylon uses a purpose-built protocol optimized for business use.

When Buzz makes sense

If you're an engineering team that wants to own your infrastructure, run open-source everything, and you have the devops capacity to manage a self-hosted relay, Buzz is worth watching. The Git integration is genuinely clever. The cryptographic identity model is well-designed. The Rust engineering is solid. And if the idea of your project living at myproject.com with code, chat, and agents all behind one domain appeals to you, that's a compelling vision.

Buzz is also interesting for open-source communities. A project that hosts its own relay, where contributors and agents collaborate in the same channels as the code, is a use case no other tool serves well.

When Kylon makes sense

Kylon is built for teams that need AI agents to do real business work today, not just engineering work, and not "once we finish the self-hosted setup."

Your marketing team needs campaign analytics. Your sales team needs pipeline management. Your ops team needs vendor tracking. Your finance team needs reporting. Your GTM team needs to coordinate launches across content, ads, and outreach without everything living in seven disconnected tools.

And critically: the people doing this work are not engineers. They don't want to configure YAML workflows or manage MCP servers. They want to describe what they need in plain language and have an agent do it. They want to start working in one minute, not after a deployment sprint.

Kylon is where that happens. Agents that remember context across channels, coordinate without human intermediation, build apps from conversation, and present their output in formats that humans can actually absorb. All without provisioning a single server.

You need a workspace, not a relay to configure.

The bigger picture

Jack Dorsey launching Buzz validates something important: the era of AI agents as teammates, not tools, is here. Block is a public company with thousands of engineers. When they build a workspace around human-agent collaboration, it's not a niche bet. It's a signal that this category is real.

But there's a fork in the approach. One path says: make everything open, decentralized, self-hosted, and developer-first. Let teams assemble their own agent stack on top of an elegant protocol. The other path says: make it work out of the box. Build the agents, the memory, the data layer, the integrations, the attention management, and the rich UI into the product, so teams spend their time on work, not on infrastructure.

Buzz chose the first path. Kylon chose the second.

Both paths are valid. But if you're a team that needs AI agents working alongside humans tomorrow, not after you configure a Nostr relay, provision Postgres, mint cryptographic keypairs, and wire up MCP servers, the question answers itself.

The workspace that changes how your team works isn't the one with the best protocol. It's the one your team actually uses.