Block Buzz: el espacio de trabajo de agentes IA donde los agentes son compañeros, no bots
La mayoría de las configuraciones de "IA en tu chat" funcionan igual: enganchas un bot a Slack o Discord, le das un comando de barra, y responde cuando se le llama. El bot vive fuera del equipo. Tiene una identidad separada, un rastro de auditoría separado y un techo estricto sobre lo que puede tocar. Block miró ese patrón y decidió que el agente simplemente debería ser un miembro de la sala.
Esa idea es Buzz, un espacio de trabajo de código abierto de Block, Inc. que ya ha atraído unas 18.000 estrellas de GitHub. En Buzz, humanos y agentes IA comparten los mismos canales, firman sus acciones con el mismo tipo de clave criptográfica y terminan en el mismo registro consultable. Está escrito en Rust y licenciado bajo Apache 2.0. Pasé tiempo leyendo los documentos de arquitectura del repositorio para que tú no tengas que hacerlo, y las decisiones de diseño son más interesantes de lo que sugiere el marketing.
¿Qué es Block Buzz?
Buzz es un espacio de trabajo autoalojable de Block, Inc. donde humanos y agentes IA comparten los mismos canales. Funciona sobre un relé Nostr, de modo que cada mensaje, reacción, parche de código, aprobación y paso de flujo de trabajo es un evento firmado en un único registro consultable y a prueba de manipulaciones. Es de código abierto bajo Apache 2.0, construido en Rust, y tú mismo operas el relé.
Puntos clave:
- Los agentes son miembros de primera clase con sus propias claves y su propio rastro de auditoría, no bots añadidos por un lado.
- Todo (chat, parches, CI, aprobaciones) es un evento Nostr firmado en un único registro consultable.
- Los agentes se conectan mediante ACP y MCP, así que Goose, Codex y Claude Code funcionan desde el primer momento.
- Autoalojado y de código abierto (Apache 2.0), con una lista honesta y pública de lo que aún no está hecho.
La frase en la que se apoya el proyecto es "a hive mind communication platform". Suena grandioso, pero la realidad del día a día es más simple: se siente como un espacio de trabajo de equipo. Canales, hilos, mensajes directos, un lienzo, reuniones de voz, búsqueda. El giro es lo que hay debajo. Cada acción es un evento Nostr firmado, y el autor de ese evento puede ser una persona o un proceso. Misma forma, mismo modelo de identidad, mismo rastro de auditoría en ambos casos.
Si has estado comparando marcos de agentes como LangGraph, CrewAI y el SDK de OpenAI Agents, Buzz es una capa completamente distinta. Esas son bibliotecas que incrustas en código para orquestar el razonamiento de un agente. Buzz es la sala donde el agente y tu equipo hablan, se pasan trabajo y dejan un registro. Son complementarios, no competidores.
Por qué "agentes como miembros" cambia el modelo
El modelo de bot tiene un problema estructural: el agente es un invitado. Le concedes banderas de permiso, opera a través de una API estrecha, y cuando algo sale mal estás reconciliando dos historiales separados: el chat del equipo y los registros del bot.
Buzz le da la vuelta. Un agente obtiene su propio par de claves, sus propias membresías de canal y su propio rastro de auditoría. Añades un agente a un canal de la misma forma que añades a una persona. El proyecto describe el alcance como "by identity, not by permission flags", que es la misma forma en que delimitarías a un compañero humano. Confías en ellos en algunas salas y en otras no.
Una vez que un agente es miembro, obtiene las mismas posibilidades que todos los demás. Puede abrir repositorios, enviar parches, revisar código, ejecutar flujos de trabajo, editar lienzos, orquestar otros agentes, crear canales y unirse a reuniones de voz. El README recorre tres escenarios que lo hacen concreto:
- Memoria de incidentes. Son las 2 de la madrugada, preguntas "¿hemos visto este error antes?", y un agente que vigila el canal extrae seis meses de historial, publica los hilos y las causas raíz, y se ofrece a avisar a quien envió el último arreglo. Todo el intercambio permanece en el canal como evidencia.
- Rama como sala. Abres una rama de funcionalidad y aparece un canal. Los parches llegan como eventos, la CI publica resultados, un agente hace una primera revisión, y la decisión de fusión vive en la misma sala que la evidencia que la justificó.
- Un lanzamiento que se escribe solo. Un flujo de trabajo se dispara con una etiqueta, un agente redacta notas de versión a partir de los PR fusionados, las publica para revisión humana, recibe una reacción de pulgar arriba y envía. Cada paso firmado, cada paso consultable.
El hilo común es que la conversación, el código y la decisión viven en un solo lugar en vez de en siete pestañas que fingen conocerse entre sí.
Cómo se conectan realmente los agentes: ACP y MCP
Aquí es donde la ingeniería se vuelve limpia. Buzz incluye dos pequeños binarios para agentes, y deliberadamente no se conocen entre sí.
buzz-agent es un agente ACP. Habla el Agent Client Protocol sobre stdio, llama a un LLM y usa herramientas MCP. Ejecuta hasta ocho sesiones simultáneas, cada una con sus propios servidores MCP, historial y contexto. Cuando el contexto de una sesión se llena, resume su propio historial y sigue. Funciona con Zed, JetBrains o cualquier otra cosa que hable ACP.
buzz-dev-mcp es un servidor MCP. Da a cualquier agente una shell y un editor de archivos. Los procesos son efímeros con matanza de grupo de procesos en cada ruta de salida, la salida está acotada, y las ediciones de archivos se resuelven contra el directorio de trabajo. Si has construido con el Model Context Protocol antes, esto te resultará familiar: es el patrón estándar de "dar manos a un agente", endurecido.
La nota de diseño del repositorio lo dice sin rodeos: "two binaries, two protocols, no coupling between them." El agente no sabe con qué servidor MCP habla, y el servidor MCP no sabe qué agente lo llama. Se componen mediante protocolos, no mediante importaciones. La ventaja práctica es que puedes ejecutar diez agentes detrás de Buzz con distintas configuraciones de MCP, o cambiar tu proveedor de LLM con una variable de entorno.
Como buzz-acp puentea las @mentions del relé a subprocesos de agentes, puedes apuntarlo a Goose, Codex o Claude Code. Si ya ejecutas agentes de codificación en segundo plano, Buzz les da una sala compartida donde operar en lugar de un bucle headless silencioso. Y si quieres traer tus propias herramientas, construir un servidor MCP es el camino soportado, con un montón de servidores MCP listos para usar desde los que empezar.
Bajo el capó: la arquitectura
Buzz es un monorepo de Rust, y el hecho más importante es este: el relé es la única fuente de verdad. No hay chismorreo punto a punto ni replicación. Los clientes se conectan a un relé por WebSocket, y el relé maneja la autenticación, verifica firmas, persiste eventos, los distribuye a los suscriptores, los indexa para búsqueda y dispara automatizaciones.
Todo es un evento Nostr NIP-01. Cada evento tiene seis campos: un id (SHA-256 del evento serializado), un pubkey, un entero kind, etiquetas, contenido y una firma Schnorr. El entero kind es el único conmutador de despacho. ¿Quieres una función nueva? Define un nuevo número de kind. Los clientes existentes no ven nada y no rompen nada. La base de código define 81 kinds, con los kinds personalizados de Buzz viviendo en el rango 40000-49999.
La pila de soporte es deliberadamente aburrida, en el mejor sentido:
| Crate | Rol |
|---|---|
buzz-core | Tipos sin I/O, verificación Schnorr, coincidencia de filtros, registro de kinds |
buzz-relay | El servidor Axum que une todos los subsistemas |
buzz-db | Almacén de eventos Postgres, canales, flujos de trabajo, particionado mensual |
buzz-auth | Autenticación Schnorr NIP-42 y NIP-98, ámbitos |
buzz-pubsub | Distribución pub/sub de Redis, presencia, indicadores de escritura |
buzz-search | Búsqueda de texto completo Postgres sobre una columna tsvector generada |
buzz-audit | Cadena de hash, registro de auditoría a prueba de manipulaciones |
buzz-workflow | Motor de automatización YAML como código |
buzz-cli | CLI para agentes primero, JSON de entrada / JSON de salida |
buzz-acp | Puentea las @mentions del relé a agentes IA vía ACP |
Postgres guarda los eventos y ejecuta la búsqueda de texto completo. Redis maneja la distribución pub/sub, la presencia y la escritura. El almacenamiento de objetos compatible con S3 (MinIO en local) guarda los medios mediante el protocolo Blossom.
El modelo de seguridad es donde dejé de leer por encima. Cada evento tiene su firma Schnorr y su ID SHA-256 verificados antes del almacenamiento. La autenticación NIP-42 usa una tolerancia de marca de tiempo de ±60 segundos para bloquear ataques de repetición, y los eventos de autenticación nunca se almacenan ni se auditan. El registro de auditoría es una cadena de hash genuina: el SHA-256 de cada entrada cubre cada campo incluido el hash anterior, de modo que manipular una entrada rompe todas las entradas posteriores. Los webhooks salientes obtienen protección SSRF que comprueba rangos de IP privadas. Y la membresía de canal es la única puerta de acceso, aplicada en cada operación, con el manejador de suscripción comprobando el acceso antes de registrar una suscripción, de modo que no hay ventana de carrera para fugas de canales privados.
Si estás evaluando cómo desplegar IA agéntica en infraestructura que controlas, esta es la parte que vale la pena leer dos veces.
Qué funciona hoy (y qué no)
El proyecto es inusualmente honesto sobre su propio estado, y creo que esa honestidad es la señal más fuerte de una base de código seria. Aquí está el estado actual directamente del repositorio:
| Estado | Capacidad |
|---|---|
| ✅ Funciona hoy | Relé, canales, hilos, mensajes directos, lienzos, medios, búsqueda, registro de auditoría, app de escritorio (Tauri + React), buzz-cli + harness ACP, flujos YAML, eventos Git (NIP-34), backend de alojamiento git |
| 🚧 En progreso | Clientes móviles (iOS + Android, Flutter), puertas de aprobación de flujo, eventos de ciclo de vida de reuniones |
| 💭 Código pendiente | Reputación web-of-trust entre relés, notificaciones push |
Ahora la parte que la mayoría de los artículos de producto omiten. El documento de arquitectura enumera lagunas verificadas, no aspiraciones:
- Aún no se aplica limitación de tasa. El trait
RateLimiterexiste y hay cuatro niveles diseñados (human, agent-standard, agent-elevated, agent-platform), pero la única implementación es un stub de prueba. - Las puertas de aprobación no están cableadas de extremo a extremo. El ejecutor puede suspender una ejecución, pero un flujo que alcanza una puerta de aprobación actualmente se marca como fallido.
- Algunas acciones de flujo son stubs.
send_dmyset_channel_topicdevuelven "not implemented", así que una ejecución que llega a una falla. - La grabación de reuniones y la publicación por pista no están construidas. Las salas de voz y el ciclo de vida de unirse/salir funcionan; la grabación tiene kinds de evento reservados pero no productor.
- Sin caché de consultas sqlx sin conexión. Las consultas se ejecutan en tiempo de ejecución en lugar de validarse en tiempo de compilación.
Nada de esto es descalificante para una herramienta autoalojada que estás evaluando, pero te dice exactamente dónde están los bordes. Si necesitas evaluar agentes en producción con garantías duras, trata las columnas 💭 y 🚧 como advertencias estructurales.
Empezar con Buzz
Hay tres caminos, según quién seas.
¿Solo quieres probarlo? Toma una compilación empaquetada del último lanzamiento: macOS (.dmg), Linux (.AppImage o .deb), o Windows (.exe). Por defecto se conecta a ws://localhost:3000, así que aún querrás un relé en marcha.
¿Quieres compilar desde el código fuente? Necesitas Docker y o bien Hermit o Rust 1.88+, Node 24+, pnpm 10+, y just. Luego:
git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit
just setup && just build
# every day:
. ./bin/activate-hermit
just dev # starts the relay + desktop app togetherEl relé aterriza en ws://localhost:3000 y la app de escritorio aparece. Para un despliegue VPS de un solo nodo en lugar de la pila de desarrollo local, hay un paquete Compose de producción bajo deploy/compose/ con Postgres, Redis, MinIO, y Caddy opcional para TLS.
¿Traes un agente? Configura BUZZ_PRIVATE_KEY y usa buzz-cli, que es JSON de entrada y JSON de salida, diseñado específicamente para llamadas de herramientas LLM. Esa es la costura donde se conectan tus flujos de trabajo de agentes.
¿Quién debería ejecutar Buzz?
Buzz es para equipos que quieren un sustrato único en lugar de un montón de código pegamento. Si tu configuración actual es chat más una forja más bots más paneles de CI más herramientas de lanzamiento más un índice de búsqueda, y estás cansado de que no se conozcan entre sí, esta es la apuesta que hace Buzz: una comunidad, un modelo de identidad, un registro de eventos.
Encaja bien para:
- Autoalojadores que quieren su tráfico de agentes en infraestructura propia, con un rastro de auditoría que puedan verificar.
- Ingenieros de plataforma que evalúan flujos de trabajo con agentes primero, donde los agentes clasifican errores, ejecutan revisiones y redactan lanzamientos como miembros en lugar de scripts.
- Evaluadores de código abierto que quieren leerlo todo en una tarde. La superficie de agentes son dos crates sin acoplamiento, deliberadamente lo bastante pequeños para auditar.
Aún no es para quienes quieren un SaaS terminado y con todo incluido que puedan entregar mañana a un equipo no técnico. Las puertas de aprobación, la limitación de tasa y los clientes móviles aún están llegando. Buzz te lo dice claramente, que es exactamente la razón por la que le confiaría un piloto cuidadoso.
El encuadre al que vuelvo una y otra vez está en el README: "Agents are part of the room, not haunted cron jobs." Si alguna vez has depurado un bot a las 2 de la madrugada sin idea de qué hizo o por qué, ya sabes por qué eso importa.
FAQ
¿Buzz es gratis y de código abierto?
Sí. Buzz es de código abierto bajo la licencia Apache 2.0 y construido por Block, Inc. Tú mismo autoalojas el relé, así que no hay tarifa por asiento por el software. Tus costes son tu propia infraestructura: un servidor para el relé, Postgres, Redis y almacenamiento de objetos. El código fuente, los issues y la hoja de ruta son todos públicos en GitHub en block/buzz.
¿En qué se diferencia Buzz de Slack con bots?
En Slack, un agente es un bot de segunda clase con identidad y rastro de auditoría separados, delimitado por banderas de permiso. En Buzz, un agente es un miembro de primera clase con su propio par de claves, membresías de canal y las mismas posibilidades que un humano: abrir repositorios, enviar parches, ejecutar flujos de trabajo, unirse a reuniones. Todo aterriza en un registro de eventos firmado y consultable.
¿Qué son ACP y MCP?
ACP es el Agent Client Protocol, la interfaz stdio que buzz-agent usa para hablar con un cliente LLM como Zed. MCP es el Model Context Protocol, la interfaz que buzz-dev-mcp usa para dar a un agente una shell y un editor de archivos. Los dos binarios no se conocen entre sí; se componen mediante protocolos, así que puedes mezclar agentes y servidores de herramientas libremente.
¿Buzz usa blockchain?
No, y el README es contundente al respecto: "Not blockchain. Signed events are useful without making everyone buy a commemorative coin." Buzz usa las firmas criptográficas de Nostr y un registro de auditoría de cadena de hash para la prueba de manipulación, pero no hay token, ni cadena, ni mecanismo de consenso. Obtienes historial verificable sin la sobrecarga.
¿Puedo usar mis propios agentes IA, como Goose, Codex o Claude Code?
Sí. El harness buzz-acp genera subprocesos de agentes IA y puentea las @mentions del relé hacia ellos vía ACP. Soporta Goose, Codex y Claude Code desde el primer momento, ejecuta un grupo de uno a 32 procesos de agentes, y reinicia un agente si se bloquea. Para herramientas personalizadas, conectas tu propio servidor MCP.
¿Está Buzz listo para producción?
En parte. El relé, los canales, la búsqueda, el registro de auditoría, la app de escritorio y el CLI de agentes funcionan hoy. Pero la limitación de tasa no se aplica, las puertas de aprobación no están cableadas de extremo a extremo, y los clientes móviles aún están en progreso. Para un piloto autoalojado con un equipo que tolera bordes ásperos, está listo para probar. Para un despliegue crítico en cuanto a cumplimiento, espera a que aterricen los elementos 🚧.
Sobre el autor
Mert Batur es cofundador de Techsy.io, donde el equipo envía agentes IA, sistemas de automatización y pipelines de voz/SDR para clientes B2B. Escribe sobre la pila de herramientas LLM que el equipo de Techsy realmente usa en producción. Conecta con él en LinkedIn.