Cuando los agentes se convierten en colegas: la idea detrás de Buzz

Ya he escrito sobre Buzz, en aquel momento con un enfoque claro en Shared Compute y la operación compartida de modelos. Ese fue para mí, en un principio, la parte más fascinante e inusual del proyecto. Pero cuanto más me ocupo de Buzz, más interesante me resulta el propio espacio de trabajo. Por eso ya he probado Buzz en una pequeña configuración.

Esto también tiene que ver con un problema que noto cada vez más claramente en los últimos meses. Mi trabajo con IA no solo se ha vuelto más rápido, sino también más desordenado. Codex trabaja en un repositorio, Claude Code revisa una segunda idea, otro agente recopila información, y en algún lugar intermedio funcionan terminal, navegador, correo electrónico y varios chats. Cada agente puede ser útil por sí solo. El problema surge en las transiciones. Hay que copiar el contexto, repetir las decisiones y fusionar los resultados manualmente.

Justo ahí entra Buzz. El proyecto de código abierto proviene de Block, la empresa detrás de Square dirigida por el cofundador de Twitter Jack Dorsey. No pretende construir otro asistente de IA más. Buzz crea un espacio de trabajo compartido en el que personas y agentes usan los mismos canales, hilos, proyectos y protocolos. Un agente de Codex puede crear un plan, Claude Code puede criticarlo, una persona puede tomar la decisión y el siguiente agente puede convertirla en un cambio en el repositorio. Toda la cadena permanece visible en el mismo espacio.

El término rápido “asesino de Slack” me parece demasiado corto. Buzz muestra una posible forma de trabajo para equipos con muchos agentes. Al mismo tiempo, todavía es joven, consume muchos recursos y es más exigente en cuestiones de seguridad de lo que sugiere su interfaz amigable. Precisamente esta mezcla de gran idea y estado temprano de desarrollo hace que valga la pena una mirada más detallada.

El verdadero problema no es el modelo

La mayoría de las herramientas de IA surgieron como una relación entre una persona y un agente. Abro Codex, introduzco una tarea y recibo un resultado. Luego abro Claude Code, explico de nuevo el mismo trasfondo y pido una segunda opinión. Para tareas individuales esto funciona bien. Pero en un equipo o con varios agentes trabajando en paralelo surge un nuevo problema de coordinación.

Conozco este problema exactamente de mi día a día. Claude Code, Codex, Hermes, navegador, chats y varias terminales funcionan en paralelo. Los registros de sesión pasan de una herramienta a la siguiente. Un agente conoce las notas de la reunión, otro el repositorio y un tercero los accesos o habilidades necesarios. Cada uno tiene un fragmento, pero nadie tiene el estado de trabajo conjunto.

Los paneles de mission control solo resuelven esto parcialmente. Puede que muestren que cinco agentes están activos. Pero todavía no crean un lugar comprensible en común donde encargo, discusión, estado intermedio, revisión y decisión permanezcan juntos. Por eso Buzz no parte de una lista de agentes más bonita, sino del propio espacio de trabajo.

Los agentes son miembros y no bots pegados

A primera vista, Buzz parece familiar. Hay comunidades, canales públicos y privados, hilos, mensajes directos, foros, búsqueda, huddles y una app móvil. La diferencia decisiva con una integración de Slack habitual está por debajo de la superficie.

Un agente en Buzz es un miembro propio. Posee un perfil, un par de claves criptográficas, membresías de canal y su propio registro de auditoría. Sus mensajes aparecen bajo su identidad. Con esto, más tarde no solo se puede ver que “la IA” hizo algo. Se hace visible qué agente actuó, en qué canal recibió el encargo y qué persona u otro agente lo activó.

Esto suena al principio como un pequeño cambio en la gestión de usuarios. Pero para el trabajo real es central. Un bot de Slack generalmente cuelga de una integración y espera a que una persona lo mencione. Dos bots de proveedores distintos normalmente no saben nada el uno del otro. En Buzz, los agentes pueden dirigirse a otros agentes, transferir tareas y discutir sus resultados en el mismo hilo. Codex y Claude Code no se convierten así en un único sistema. Pero obtienen un espacio de comunicación compartido.

Buzz no aporta automáticamente toda la inteligencia. El espacio de trabajo conecta los llamados harnesses y modelos que ya funcionan localmente, en un servidor o a través de un proveedor. Según el estado actual del proyecto, entre ellos se encuentran Codex, Claude Code y Goose. Otros agentes pueden conectarse mediante interfaces abiertas. Se trata de un modelo bring-your-own-agent: Buzz coordina, el agente respectivo piensa y actúa con sus propias herramientas, habilidades, accesos y costes de modelo.

El relay es el estado de trabajo compartido

Técnicamente, Buzz consta de varias partes. La app de escritorio es la interfaz. Una comunidad es el espacio de trabajo propiamente dicho. El Buzz Relay almacena y distribuye sus mensajes, miembros, agentes, reglas, medios, datos de búsqueda, workflows y eventos de Git. Los agentes pueden trabajar en el mismo equipo que la app de escritorio, en un servidor que funciona permanentemente o en una máquina completamente distinta.

Como protocolo, Buzz usa Nostr. Personas y agentes firman eventos con sus claves privadas. El relay comprueba identidad y membresía, almacena los eventos y los distribuye a los clientes autorizados. Sin embargo, esto no convierte a Buzz en una red peer-to-peer mágica. El relay es la fuente central de una comunidad. No hay replicación automática entre relays, y los mensajes permanecen en el relay donde fueron enviados.

Esta construcción tiene dos consecuencias interesantes. La identidad no pertenece simplemente a una cuenta central de Slack, sino que se basa en un par de claves propio. Al mismo tiempo, un equipo puede operar el espacio de trabajo por sí mismo. Quien solo quiera probar primero puede usar una comunidad alojada por Block. Quien quiera controlar por sí mismo el almacenamiento de datos, la disponibilidad y la copia de seguridad, opera el relay en infraestructura propia.

La arquitectura actual del servidor usa componentes conocidos: PostgreSQL para eventos y búsqueda de texto completo, Redis para pub/sub y almacenamiento compatible con S3 para medios. No es un servicio pequeño que se pueda olvidar tras la instalación. Un relay operado por uno mismo necesita TLS, actualizaciones, copias de seguridad, monitorización y una gestión de claves limpia.

Por qué el contexto compartido es tan valioso

La idea más potente de Buzz es el contexto duradero y visible conjuntamente. Un proyecto ya no consiste en un mensaje de chat en Slack, una ejecución de agente separada, un pull request en GitHub y una decisión en una videoconferencia. Buzz intenta reunir estos rastros en un espacio de eventos.

Esto es especialmente útil cuando distintos agentes tienen distintas fortalezas. Un flujo realista puede verse así:

1. Una persona describe en el canal del proyecto el objetivo y los límites.
2. Un agente de investigación recopila información y documenta sus fuentes.
3. Un segundo agente ataca los puntos débiles y busca contraargumentos.
4. Codex o Claude Code elabora un plan concreto.
5. Otro agente revisa el plan en busca de seguridad, tests faltantes o suposiciones poco claras.
6. Tras la aprobación humana, el cambio se implementa en un worktree separado.
7. Diff, resultados de tests, revisión y decisión permanecen localizables en el canal correspondiente.

Este patrón es especialmente interesante en revisiones adversariales. Un modelo recibe explícitamente el papel de atacar un plan de producto o una implementación. Un segundo modelo debe defender o mejorar las decisiones. Como ambos ven el hilo completo, surge un enfrentamiento real con el estado de trabajo existente y no solo una revisión aislada de un texto copiado.

También para procesos de contenido y negocio el patrón es interesante. Un agente investiga temas, un segundo escribe, un tercero edita. Las cifras clave o nuevas noticias pueden fluir regularmente a un canal para que personas y agentes discutan juntos la evolución. Los huddles van un paso más allá: personas y agentes hablan en una conferencia de audio, la conversación se convierte en texto y luego puede transformarse en tareas concretas.

Este es el punto en el que Buzz se convierte en algo más que un chat grupal. El canal no es solo un lugar de comunicación. Se convierte en un registro de trabajo rastreable.

Buzz también quiere sustituir a GitHub

Buzz integra repositorios Git, parches, revisiones y eventos de estado en el mismo espacio de trabajo. El relay puede alojar repositorios por sí mismo. Los agentes pueden usar worktrees, trabajar por separado en variantes, proporcionar cambios como parche y discutir revisiones en el contexto del proyecto.

La visión detrás de esto es potente: una rama de característica se convierte en un espacio. Ahí no solo están los commits, sino también la discusión sobre por qué era necesario un cambio, qué alternativas se descartaron, qué informó el CI y quién aprobó el merge. Precisamente en el código generado de forma agéntica, esta historia de origen suele faltar hoy en día.

Aun así, todavía no daría por descontado a GitHub. GitHub no es solo almacenamiento de Git, sino un ecosistema crecido durante años para permisos, revisiones, CI/CD, escaneos de seguridad, releases, integraciones y colaboración externa. Buzz tiene bases de Git funcionales y un enfoque de forge interesante. Pero el propio estado del proyecto distingue claramente entre partes que ya funcionan, funciones todavía en cableado y visión. Para repositorios críticos, un uso gradual es más razonable que una migración inmediata.

Mi primera prueba con Buzz

Empecé deliberadamente en pequeño: una comunidad propia, un canal y dos agentes con roles claramente separados. Codex debía crear un plan técnico, Claude Code debía atacar suposiciones, brechas de seguridad y complejidad innecesaria. Credenciales productivas, datos de clientes y repositorios sensibles quedaron fuera. Al principio me interesaba probar la colaboración, no la máxima autonomía.

El primer encargo abierto fue demasiado impreciso. Ambos agentes empezaron a planificar, reaccionaban el uno al otro y en algún momento esperaban el siguiente impulso. Fue un buen recordatorio de que un canal compartido todavía no sustituye a la orquestación. Con la instrucción clara “Codex crea el plan, Claude lo revisa, luego esperáis la aprobación”, el flujo se volvió notablemente más tranquilo y rastreable. Más agentes no sustituyen la definición de procesos.

Lo que más me convenció no fue una respuesta individual espectacular, sino la ausencia de ruptura de medio. Ambos agentes veían el mismo hilo, la crítica quedaba junto al plan original, y en todo momento podía rastrear quién estaba trabajando. No tuve que copiar texto entre ventanas ni explicarle de nuevo la historia previa a un segundo agente. Ahí reside, para mí, el verdadero valor de Buzz.

Para el desarrollo intensivo de software, sin embargo, el trabajo directo en Codex o Claude Code siguió siendo más rápido. Buzz añade comunicación, registro y contexto compartido. Esta capa cuesta tiempo y tokens. Cada agente adicional tiene su propia sesión, y el historial extenso de canal puede procesarse varias veces con varios modelos. Para una ejecución larga de codificación, por lo tanto, seguiría usando el harness nativo y usaría Buzz más bien para planificación, transferencias y revisiones.

Todavía no he probado suficientemente a fondo workflows, huddles más largos, modelos locales y varios agentes remotos que funcionen de forma permanente. Justo ahí Buzz debe demostrar en el día a día que las tareas no solo son visibles de forma bonita, sino que también se completan de forma fiable. El software está antes de la versión 1.0 y en algunos puntos se siente correspondientemente joven. Para experimentos está bien. Pero los flujos centrales siguen necesitando control, lógica de repetición y un camino de vuelta manual claro.

El contexto compartido también es un límite de seguridad

Lo que hace útil a Buzz aumenta al mismo tiempo la superficie de ataque. Un agente conectado de Codex, Claude Code o Hermes puede traer consigo acceso a archivos, shell, navegador, servidores MCP, correo electrónico, calendario u otras herramientas internas. Si un miembro del equipo puede dirigirse a este agente, el permiso va mucho más allá de escribir una respuesta de chat.

La regla más importante es, por tanto: un agente solo debe trabajar en canales cuyo contenido y miembros encajen con su acceso a herramientas. La membresía de canal es la puerta de acceso central. Quien es miembro puede leer y escribir. Quien no es miembro no debería poder ver canales privados ni suscribirse a sus eventos.

Las firmas criptográficas, sin embargo, no resuelven todos los problemas de auditoría. Buzz lleva un registro de auditoría encadenado y visible ante manipulaciones. Un atacante con acceso de escritura a la base de datos podría, no obstante, recalcular la cadena tras una manipulación. El registro es, por tanto, tamper-evident, no tamper-resistant. Hace reconocibles los cambios, siempre que la base de confianza del almacenamiento no haya caído por completo.

Para las comunidades alojadas por Block se añade otro punto: los mensajes, mensajes directos y medios subidos no están cifrados de extremo a extremo. Block puede acceder a estos contenidos por motivos operativos, de seguridad, de moderación o de obligaciones legales. Además, el proveedor de modelo respectivo puede recibir prompts y contenido de canal cuando un agente usa un servicio en la nube.

El self-hosting cambia la soberanía de los datos, pero no automáticamente todo el flujo de datos. Un relay propio mantiene mensajes y archivos en la infraestructura propia. Si el agente sigue usando un modelo en la nube, los datos necesarios para el encargo abandonan igualmente el relay. Una operación verdaderamente local requiere, por tanto, tanto un relay propio como modelos y herramientas locales. Ya escribí por separado sobre las posibilidades y límites de Buzz Shared Compute.

Así uso Buzz por ahora

Para mi primera prueba usé una comunidad pequeña y claramente delimitada. Sin credenciales productivas, sin datos de clientes y sin un repositorio con secretos. Dos agentes bastaron perfectamente: uno crea, uno revisa. A eso me sumo yo como persona, que fija el encargo, el punto de aprobación y el criterio de interrupción.

Mi primera configuración no fue una empresa autónoma con cien agentes, sino una revisión limitada:

• Un agente crea un plan técnico a partir de un issue existente.
• Un segundo agente busca brechas de seguridad, suposiciones faltantes y complejidad innecesaria.
• Ambos deben nombrar fuentes, archivos y preguntas abiertas.
• Tras un máximo de dos rondas de discusión, el equipo espera la aprobación humana.
• Solo después un agente puede preparar cambios en un worktree aislado.

Con esto pude probar la verdadera fortaleza de Buzz sin reconstruir de inmediato toda mi operación. Al mismo tiempo se hicieron visibles el consumo de tokens, la latencia, los permisos y la trazabilidad.

Para el trabajo en solitario con una única tarea de codificación, sigo con la interfaz directa del agente. Es más rápida y más fácil de controlar. Buzz se vuelve interesante en cuanto varias personas, varios agentes o varios flujos de trabajo necesitan el mismo contexto. Por eso, equipos pequeños de desarrollo, agencias, grupos de investigación y solopreneurs técnicamente competentes son el grupo objetivo evidente.

Para una empresa más grande sería más cauteloso. Antes de la versión 1.0, sin una línea de soporte a largo plazo y con workflows todavía jóvenes, no convertiría Buzz en el único lugar para comunicación crítica o código fuente. Un proyecto piloto puede tener sentido. Una sustitución completa de Slack y GitHub sería actualmente una apuesta por la velocidad de desarrollo del proyecto.

La idea detrás de Buzz es más grande que el cliente actual

La parte más fascinante de Buzz no es, para mí, una función individual. Canales, foros, huddles, alojamiento de Git y modelos locales existen también en otros lugares. Lo nuevo es la suposición consecuente de que los agentes ya no son solo herramientas privadas de usuarios individuales. Se convierten en participantes visibles de un proceso de trabajo compartido.

Con esto se desplaza la pregunta. Ya no preguntamos solo qué modelo escribe el mejor código. Debemos decidir cómo personas y varios agentes distribuyen tareas, comparten contexto, se controlan mutuamente y hacen la responsabilidad rastreable. Precisamente para eso a menudo falta hoy la infraestructura social y técnica.

Buzz aún no da una respuesta acabada. El software es joven, algunos workflows no son fiables, el contexto compartido puede volverse costoso y el self-hosting conlleva una responsabilidad operativa real. Aun así, el proyecto acierta en un problema real. Cuando los agentes asumen cada vez más trabajo, no basta con abrir cinco chats individuales uno al lado del otro. Necesitamos un lugar compartido donde su trabajo permanezca visible, limitado y verificable.

Quizás Buzz sustituya algún día a Slack y GitHub. Por hoy basta con una afirmación más pequeña pero más importante: Buzz es un boceto convincente de cómo puede lucir un espacio de trabajo cuando ya no solo trabajan personas en él. Shared Compute me hizo fijarme en el proyecto. El espacio de trabajo compartido es la razón por la que seguiré probando Buzz.

Mi conclusión tras la primera prueba

Buzz acertó en mi breve prueba precisamente en el problema que tengo actualmente con los agentes de IA. Los modelos individuales ya no son el cuello de botella. Lo difícil es mantener a varios agentes, decisiones y resultados en una línea común. Buzz hace visible este trabajo y da a Codex, Claude Code y otros agentes un lugar donde pueden reaccionar no solo ante mí, sino también entre ellos.

Me convencieron el contexto compartido, las identidades de agente claramente separadas y la posibilidad de dejar que un segundo modelo ataque directamente un resultado. Menos me convenció la sobrecarga adicional. Para una única tarea de codificación, el camino directo a través de Codex o Claude Code sigue siendo más rápido. En cuanto participan varios agentes o personas, Buzz empieza a desplegar su fortaleza.

Mi prueba fue deliberadamente corta. No comprobé ni una operación de equipo permanente ni grandes repositorios, workflows complejos o picos de carga más largos. Para eso el software todavía es demasiado joven y se mueve demasiado rápido. Hoy no convertiría Buzz en el único lugar para comunicación crítica o código fuente. Pero para un equipo pequeño, una agencia o un laboratorio personal de IA, ya es más que una demo interesante. Es una herramienta que quiero seguir usando e incorporar de forma específica en mi día a día.

Hasta la próxima,
Joe

FAQ