Respuesta rápida: Buzz es un espacio de trabajo en equipo, gratuito y de código abierto, creado por Block (la empresa de Jack Dorsey) y lanzado el 21 de julio de 2026. Se parece a Slack con canales, hilos, mensajes directos y voz, con una diferencia de fondo: los agentes de IA no son integraciones ni bots, sino miembros del equipo con identidad propia, permisos propios y su propio rastro de auditoría. Además incorpora repositorios de código, por lo que también compite con GitHub.
Si trabajas con Claude Code, Codex o goose y estás cansado de que el contexto de tu proyecto viva desperdigado entre pestañas, este lanzamiento te interesa. Vamos a ver qué es exactamente, qué funciona hoy y qué no, y cómo probarlo.
Quién está detrás de Buzz
Buzz lo ha construido Block, Inc., la empresa de Jack Dorsey (cofundador de Twitter y de Square/Block). El propio Dorsey lo describe como "model-agnostic, decentralized, self-sovereign, and open source".
El origen es interno y bastante honesto: lo construyeron para reducir su propia dependencia de Slack y de GitHub, y decidieron publicarlo para que cualquiera pueda hacer lo mismo. Bradley Axen, Head of AI Capabilities de Block, lo resume así: toda empresa va a necesitar un sitio donde humanos y agentes trabajen juntos, y ese sitio debería ser abierto.
El código est á en github.com/block/buzz bajo licencia Apache 2.0, escrito principalmente en Rust, y superó las 16.000 estrellas en cuestión de días.
En qué se diferencia realmente de Slack
La comparación fácil es "Slack con IA metida dentro". Es más profundo que eso.
| Slack | Buzz | |
|---|---|---|
| Agentes de IA | Integraciones y bots con tokens de app | Miembros con clave criptográfica propia, perfil y permisos |
| Código | Enlazas a GitHub | Repositorios y hosting git dentro de la propia plataforma |
| Tus datos | En infraestructura de Slack | En un relay que puedes autohospedar |
| Modelo de IA | El que decida el proveedor | Cualquiera: Claude, Codex, goose o un modelo local |
| Licencia | Propietario | Apache 2.0, código abierto |
| Automatizaciones | Workflow Builder propietario | Workflows en YAML sobre protocolos abiertos |
La diferencia clave está en el último punto de la tabla y no es cosmética. En Slack, para conectar una app tuya necesitas crear una aplicación en su plataforma, gestionar tokens y aprender su estructura. En Buzz, al estar construido sobre protocolos abiertos, conectar tu propia herramienta es cuestión de minutos.
Cómo funciona Buzz por dentro
Aquí está lo que hace que la propuesta se sostenga técnicamente. Buzz no es una aplicación de chat con una base de datos de mensajes: es un relay del protocolo Nostr con una interfaz de espacio de trabajo encima.
Eso significa que cada mensaje, cada reacción, cada patch de código, cada paso de una automatización y cada aprobación son eventos firmados criptográficamente dentro de un mismo registro. Da igual que quien firme sea una persona o un proceso: mismo formato, mismo modelo de identidad, misma auditoría.
De ese diseño se derivan tres consecuencias prácticas. Primera: un agente es un miembro, no una integración. Tiene su par de claves, sus canales y su historial. Lo añades a un canal igual que a una persona, y puedes revisar exactamente qué hizo. Segunda: el relay es tuyo. La URL del relay es la comunidad. Si un día quieres mudarte, tus datos se mueven contigo, algo que en Slack, en la práctica, es muy difícil. Tercera: todo es buscable a la vez. La conversación, el cambio de código, el resultado del CI y la aprobación son el mismo tipo de evento y viven en el mismo índice.
La infraestructura, por si te toca desplegarla: relay en Rust, PostgreSQL para eventos y búsqueda, Redis para presencia y tiempo real, S3 o MinIO para archivos, y una app de escritorio construida con Tauri y React.
La función más útil: cambiar de modelo sin perder el contexto
Si solo te quedas con una cosa de este artículo, que sea esta.
Buzz separa el agente (su identidad, su personalidad, su historial en el canal) del harness (el programa que ejecuta el modelo). El puente entre ambos es ACP (Agent Client Protocol). Hoy soporta goose (el framework open source del propio Block), Codex de OpenAI mediante el adaptador codex-acp, Claude Code mediante claude-agent-acp, y buzz-agent, el agente minimalista propio de Block.
¿Por qué importa tanto? Porque puedes cambiar el motor de un agente desde la interfaz y el contexto acumulado se queda donde está. Todo lo que hablaste con ese agente, los proyectos en marcha, las decisiones tomadas: sigue ahí, porque no vive dentro del harness, vive en el registro de eventos.
Cualquiera que haya sufrido la "fatiga de modelos", cambiar de herramienta cada dos meses y empezar de cero explicando el proyecto, entiende de inmediato el valor. Y tus skills instaladas globalmente siguen funcionando independientemente del harness que elijas.
Consejo práctico: asigna a cada agente el modelo que corresponde a su trabajo. Un modelo potente para razonar sobre arquitectura, uno más barato para tareas rutinarias. No todas las tareas merecen quemar los tokens caros.
Qué puedes hacer con Buzz: dos casos reales
1. Un agente que construye y despliega una app entera
En el episodio de Startup Ideas Pod donde se analizó la herramienta, Vinny (del equipo de Wasp) pidió a un agente: "monta un CRM simple con el framework Wasp y despliégalo en Railway".
El agente creó el repositorio, escribió el código, lo desplegó en producción y devolvió el enlace y capturas de pantalla en el canal, antes de que él llegara a mirar lo que estaba haciendo.
Funciona porque los agentes trabajan en worktrees de git paralelos, no sobre tu copia local. Puedes pedir tres versiones distintas de una landing a la vez sin que se pisen entre ellas.
2. El bucle de contexto (la parte que casi nadie ha entendido)
Este es el patrón más valioso, y el menos obvio. No consiste en que el agente construya una app. Consiste en que la app construida devuelva datos al agente.
Pides una app, por ejemplo un panel con las métricas de tus publicaciones. Pides que esa app exponga una API. Creas un workflow programado que cada día consulte esa API y publique los números en un canal. Ahora respondes en ese hilo: "¿qué tienen en común mis publicaciones con mejor rendimiento esta semana?", y el agente ya tiene los datos delante, sin exportar CSVs ni copiar y pegar en ChatGPT.
Es el bucle cerrado: contexto → agente → software → datos → contexto. Y es transferible: funciona igual con n8n, con un cron o con Buzz. Ese es "el trabajo aburrido que toda empresa tiene" y donde suele estar la ventaja competitiva real.
Compartir compute: un modelo local para todo el equipo
Otra pieza poco comentada. En los ajustes de Buzz puedes activar "compartir esta máquina", elegir un modelo local y permitir que otros miembros de tu comunidad lo usen desde sus propios portátiles.
El escenario evidente: tres estudiantes sin presupuesto para suscripciones premium se juntan, compran un equipo decente, y comparten un modelo local entre todos. La admisión está controlada por la membresía de la comunidad y por firmas criptográficas, así que no es un puerto abierto al mundo.
Es funcionalidad temprana, hoy vive tras una feature flag de compilación, pero la dirección es clara: elegir modelo no debería depender de quién te vende la suscripción.
Cómo empezar con Buzz: tres rutas
Ruta 1: alojado (5 minutos, sin infraestructura)
Entra en buzz.xyz, crea tu cuenta y tu comunidad con hosting de Block. Gratis en beta temprana. No hay precios ni límites publicados todavía, así que trátalo como un hecho de lanzamiento, no como una garantía permanente.
Ruta 2: app de escritorio contra un relay existente
Descarga el instalador desde las releases del repositorio: .dmg para macOS, .AppImage o .deb para Linux, .exe para Windows. Por defecto apunta a ws://localhost:3000; puedes cambiar el relay desde la propia app o con la variable BUZZ_RELAY_URL.
Ruta 3: autohospedado (control total)
Necesitas Docker y Hermit (o Rust 1.88+, Node 24+, pnpm 10+ y just):
git clone https://github.com/block/buzz.git && cd buzz. ./bin/activate-hermit && just setup && just buildY para el día a día:
just devPara producción en un VPS existe un bundle específico en deploy/compose/ (con PostgreSQL, Redis, MinIO y Caddy opcional con certificados automáticos). No uses el docker-compose.yml de la raíz: ese es solo para desarrollo local.
Antes de meterlo en tu flujo: tres avisos de seguridad
Esto no suele aparecer en los análisis, y es justo lo que separa un experimento de un incidente.
El agente tiene acceso a shell real. El servidor de herramientas de Buzz da al agente una terminal y un editor de ficheros, y corre al nivel de confianza del operador, como bash. No es un sandbox. Si le das acceso a la máquina donde guardas tus claves de producción, eso es exactamente lo que le has dado.
Revisa quién puede activar a tus agentes. Por defecto solo responde a su propietario (owner-only). Existe un modo abierto a cualquiera. No lo actives en un canal público: es una invitación a la inyección de prompts.
Tu clave privada es tu identidad. En Nostr no existe el "he olvidado mi contraseña". Si la pierdes, pierdes la identidad.
Entonces, ¿deberías cambiarte de Slack?
Hoy, no del todo. Y conviene ser claro con esto.
Lo que ya funciona: relay, canales, hilos, mensajes directos, canvas, archivos, búsqueda, registro de auditoría, app de escritorio, CLI para agentes, workflows en YAML, eventos de git y hosting de repositorios.
Lo que todavía no: clientes móviles (iOS y Android están en desarrollo), notificaciones push, y las puertas de aprobación de los workflows. Quien lo ha usado a fondo señala además dos cosas: las tareas recurrentes todavía no son fiables, y hay latencia notable frente a trabajar directamente en Claude Code o Codex.
Conclusión honesta: sin móvil y sin notificaciones push, Buzz no sustituye a tu Slack todavía. Pero sí puede ser tu segundo espacio de trabajo, el sitio donde vive el trabajo con agentes. Encaja especialmente bien en equipos pequeños y proyectos en iteración rápida; no tanto en ingeniería compleja o entornos con requisitos de compliance.
Y aunque acabes volviendo a Slack, habrás aprendido a configurarlo mejor. En esto no se pierde.
Lo que esto nos dice sobre el futuro del trabajo
Más allá de si Buzz triunfa o no, la tesis de fondo es la que importa: el contexto compartido es el cimiento, y los agentes se construyen desde ahí.
Lo que hace especial a esta herramienta no es "Slack con IA". Es que puso identidad, contexto, código y automatización dentro de un mismo registro firmado, y devolvió el control de la infraestructura a quien la usa. Ese diseño va a sobrevivir aunque el producto no lo haga.
La habilidad que se vuelve valiosa aquí no es dominar Buzz. Es entender qué hay debajo: cómo funciona un protocolo de eventos, cómo se levanta y asegura un servicio, cómo se diseña una API, y qué hace realmente un agente cuando ejecuta código en tu máquina. Eso no caduca con la siguiente herramienta que se ponga de moda.
Si quieres pasar de leer sobre agentes a construir con ellos, en 4Geeks Academy formamos desarrolladores que trabajan con este stack desde el primer día: proyectos reales, mentoría en vivo y acompañamiento hasta la contratación.
Publicado el 29 de julio de 2026. Fuentes: repositorio oficial de Buzz, anuncio de Block, TechCrunch y el episodio de Startup Ideas Pod con Greg Isenberg y Vinny (@hot_town).