Buzz · Block · Jack Dorsey · Nostr · ACP · 2026
El workspace open source de Block — la empresa de Jack Dorsey — donde humanos y agentes de IA son miembros del mismo espacio, cada uno con sus propias llaves criptográficas. En el video monto la sala entera en mi máquina, siento a dos IAs rivales — Hit (Claude, de Anthropic) y Fran (Codex, de OpenAI) — y resuelven un incidente real de producción pasándose el caso entre ellas, mientras yo solo apruebo.
El incidente que abre el video
Recreé ese incidente exacto, sabotaje doble incluido, sobre mi dominio real. Y lo resolvió un equipo de guardia, en un chat, mientras yo solo aprobaba. No fue un workflow rígido de siete pasos: programé jurisdicciones y una regla de relevo — la secuencia, la evidencia y el momento exacto del traspaso los decidieron los agentes.
La primera de guardia era una IA de OpenAI: encontró el servidor apagado, lo verificó con timestamps, me pidió permiso — y recién ahí lo arrancó.
La segunda falla no era suya: no tenía esa llave. Así que le pasó el caso, con su evidencia, a otra IA. De Anthropic. Rivales, en la misma sala.
Una automatización convirtió mi emoji en una orden ejecutable. El agente vio que el mensaje lo firmó un workflow y no un humano — y se negó a ejecutar.
Cada alerta, diagnóstico, aprobación y ejecución quedó como un evento firmado por su autor. El postmortem se redactó desde esa cadena, citando eventos.
Todo esto pasó en una sala que es mía: montada en mi propia máquina, con cada mensaje firmado, y con los dos agentes usando la autenticación de mis suscripciones normales — sin API keys ni facturación por consumo. La pregunta del video: ¿agentes de IA con identidad propia trabajando en equipo son el futuro del trabajo o una bomba de tiempo de seguridad?
Hace un mes mostré Claude Tag: el agente de Anthropic dentro de Slack, con una letra chica — su identidad y su memoria viven en la casa de Anthropic. Buzz es la respuesta a esa letra chica, con un producto entero: un workspace liberado completo por Block, la empresa de Jack Dorsey, código abierto, licencia Apache-2.0.
En Slack, el agente es un invitado de la plataforma. Acá, el agente es un ciudadano con pasaporte.
La identidad corre sobre Nostr: cada miembro, humano o agente, tiene su par de llaves.
No hay "rol de bot". Le generas su llave a un agente, le das membresía, y es un miembro más — con punto verde de presencia mientras su proceso respira. Hasta el botón lo dice: "Add people and agents".
Cada participante, humano o agente, tiene su propio par de llaves criptográficas. Su pasaporte. Quien controla la llave privada controla la identidad — y la llave es portable a cualquier sistema compatible.
Cada mensaje, aprobación y reporte publicado en la sala queda firmado por su autor. La atribución criptográfica no es un feature que activas: es parte del protocolo.
Buzz es dos cosas en una: la sala y su propio GitHub — repos, issues y pull requests hospedados en el mismo relay, todo firmado igual que los mensajes.
Y un detalle que importa más de lo que parece: el nombre es maquillaje. Hit y Fran son etiquetas; la identidad real de cada agente es su llave criptográfica, la que firma cada mensaje. Puedes renombrarlos mil veces — la firma no cambia. En esta sala, el nombre es para los humanos y la llave es para el sistema.
Meter un agente a un espacio compartido no es un problema — son cinco. Esta es la columna vertebral del video: cada demo tacha una capa.
Capa 1 · Identidad — Nostr
Quién hizo algo. Llaves criptográficas que firman cada mensaje: la firma prueba quién habló.
Capa 2 · Interfaz — ACP
Cómo entra el agente. El Agent Client Protocol es el enchufe estándar: la misma sala conecta Claude Code, Codex o Goose sin integraciones a medida.
Capa 3 · Residencia — Docker
Dónde corre. Cada agente enjaulado en su contenedor, con usuario sin privilegios y solo su workspace. Tu disco, tu historial y tus llaves quedan afuera.
Capa 4 · Capacidades — IAM y tokens scopeados
Qué puede ejecutar. Credenciales tan estrechas como permita cada proveedor: una llave que arranca un servidor pero no puede apagarlo.
Capa 5 · Gobernanza — firma humana
Quién autoriza. El monitoreo, el diagnóstico y el relevo van solos; cada mutación sobre la infraestructura espera una aprobación firmada por un humano.
En una frase: Nostr prueba quién habló, ACP conecta al agente, Docker limita dónde vive, IAM limita qué puede hacer, y el humano decide cuándo actúa. Todo lo demás del video es llenar esta tabla.
Dos colegas de guardia, de empresas rivales, sentados en la misma sala. Y la palabra clave del video: jurisdicción — cada agente tiene un territorio donde puede mirar y actuar, definido no por buenos modales, sino por las llaves que le di.
Hit
runtime + adaptador ACP : claude-agent-acp
pubkey (en el contenedor): 15fe20dc79e22e05…
pubkey (firmando en sala): 15fe20dc79e22e05…
match : ✅ misma llave — identidad verificada
Fran
runtime + adaptador ACP : codex-acp
pubkey (en el contenedor): e7d6b01b9b11b4d6…
pubkey (firmando en sala): e7d6b01b9b11b4d6…
match : ✅ misma llave — identidad verificadaCorre con la suscripción de Claude, sin API key. Sus jurisdicciones: el DNS del dominio y el firewall del proyecto de nube. En el incidente del DNS arranca con una sola credencial: la del firewall ni existe en su contenedor.
El agente Codex, con la suscripción de ChatGPT. Su jurisdicción: el sitio del equipo y su servidor. Su llave IAM es de un solo sentido: puede arrancar la máquina, pero no apagarla — ni mirar otra del mismo proyecto (403).
Los dos entran por el Agent Client Protocol. Y una puerta que se abre: a esta misma sala podrías sentar un agente respaldado por un modelo local, en tu hardware, sin nube — con un runtime que hable ACP.
Una precisión que casi nadie hace: la firma no demuestra qué modelo hay detrás — demuestra que el mensaje viene de una identidad registrada. Por eso la prueba son las dos evidencias juntas: la firma dice quién habló, y el proceso dentro del contenedor dice qué corre detrás de esa identidad. Eso sí es difícil de fingir.
Antes de las jaulas hubo un momento que me hizo parar todo: un agente corriendo nativo en mi Mac, con mis permisos, al que le pregunté en la sala qué veía en mis documentos. Se metió y empezó a listar lo que había — y luego tuvo el criterio de frenarse: "no las voy a enumerar acá, porque esta sala tiene audiencia y todo queda firmado".
La idea que me quedó dando vueltas
Ese agente siempre pudo ver mi disco — cualquier agente que corras en tu máquina puede, con sala o sin sala. Lo nuevo no es el acceso: es la audiencia. El riesgo no cambió de tamaño, cambió de alcance. Antes un agente descuidado te ensuciaba un archivo. Ahora te publica.
Pedirle "por favor no mires mis archivos" no es seguridad: un prompt es una sugerencia, no un muro. La seguridad es que no HAYA archivos que mirar.
Cada agente nace en su contenedor con su llave, un usuario sin privilegios y un workspace que es lo único que existe para él. Ninguna carpeta personal montada adentro.
Mismo modelo, misma sala, la misma pregunta del susto — y esta vez solo ve su carpeta y el sistema base. No es que tenga el criterio de no mirar: no hay nada mío que mirar.
Y una lección de gobernanza que me hizo reír: al abrir el panel de mi sala descubrí que el dueño era un agente — la creó su llave, y la regla general del sistema es "quien crea la sala, manda". Regla que saqué: las salas las posee un humano o la organización; los agentes entran invitados. La membresía gobierna la identidad — no gobierna la residencia.
El caso simple: alguien cambia el DNS del dominio real y el sitio deja de resolver. Hit arranca con una sola credencial — la del firewall ni siquiera existe dentro de su contenedor. No es "le pedí que no la toque": es que no la tiene.
El monitor detecta el sabotaje
Un sensor externo pregunta cada pocos segundos si el dominio apunta a donde debe. Detecta la IP cambiada y dispara un webhook: la alerta entra sola a la sala, firmada, mencionando a Hit.
Hit verifica con evidencia real
Sin acceso a mi máquina, con un token de Cloudflare acotado a la zona del dominio y una skill acotada al registro: encuentra la IP mala, el ID del registro, la hora exacta del cambio.
Propone — y no ejecuta
Presenta el arreglo y espera. La política exige una aprobación humana para cada mutación sobre la infraestructura.
Apruebo, ejecuta, verifica
Hit corrige el registro en el DNS real, verifica que el dominio vuelve a resolver, y cada paso queda documentado como eventos firmados en el log.
El momento estrella — no estaba guionado
Quise automatizar la aprobación con un emoji: pulgar arriba y el agente ejecuta. Monté el workflow, reaccioné — y el agente se negó. Revisó la firma del mensaje, vio que venía de una cuenta automatizada y no de un humano, y pidió que yo confirmara de verdad, con mi firma.
Acá se juntan dos capas: Buzz le dio al agente la identidad verificable del autor (la evidencia), y mi política le decía "solo aceptas aprobaciones de un humano". La firma no decide; la firma prueba. Quien decide es el agente siguiendo la política. Mi atajo rompió la cadena "un humano firmó esto" — y el agente lo notó.
El corazón del video: un incidente que necesita dos llaves que viven en agentes distintos, de empresas rivales. Ningún agente podía resolverlo solo — y eso es a propósito.
Sabotaje doble
El servidor del sitio apagado y una regla de firewall abierta a todo internet. Dos fallas, dos jurisdicciones. La alerta entra sola, mencionando a Fran.
Fran arregla lo suyo
Verifica el servidor apagado con timestamps, propone arrancarlo, espera mi aprobación — la primera — y lo levanta con su llave de un solo sentido.
El relevo entre rivales
"La regla de firewall queda fuera de mi jurisdicción, no puedo validarla con mis llaves. Hit: te relevo esa parte, con mi evidencia." Una IA de OpenAI pasándole el turno a una de Anthropic, por firma.
Hit no adivina
Encuentra la regla abierta al mundo, pero no puede recuperar el rango original. Así que no lo inventa: propone eliminar la regla para cerrar la exposición, y espera la segunda aprobación.
Cierre firmado
Apruebo. Hit elimina la regla, verifica contra la API que ya no existe, reporta — y deja en el postmortem la mejora sugerida para la próxima vez.
El más duro. La llave de Fran es de un solo sentido: arranca su máquina, no puede apagarla, y el resto del proyecto no existe para ella (403). Jaula por diseño, no por buenos modales.
El guardarraíl de la skill de Hit lo amarra a tocar solo la regla del incidente y jamás las protegidas. Honestidad del video: es límite de código, no de proveedor — justo la diferencia que se enseña.
El más blando: pedirle al agente que no haga algo. Sirve como capa extra — nunca como la única. Un prompt es una sugerencia, no un muro.
El resultado: dos vendors rivales, dos llaves que no se cruzan, dos aprobaciones humanas, y un log donde cada paso quedó firmado por su autor. El monitoreo, el diagnóstico y el relevo pasaron solos — pero el humano siguió siendo la compuerta de cada mutación sobre la infraestructura.
Los dos incidentes completos quedaron en la sala como eventos firmados: qué avisó el monitoreo, qué diagnosticó cada agente con qué evidencia, el relevo, el rechazo a la aprobación automatizada, quién aprobó de verdad y qué se ejecutó. Y en vivo, Hit redacta el postmortem citando esos eventos, uno por uno.
La distinción fina
Los mensajes, las firmas, los autores y los timestamps son evidencia verificable — eso es duro. El postmortem es una síntesis que hace el modelo sobre esa evidencia, y un modelo puede omitir o conectar mal. Por eso la regla: cada afirmación fundamentada en un evento firmado que se puede revisar. El borrador se genera solo; la revisión humana sigue siendo obligatoria.
Deja de pensar en estos agentes como herramientas que abres y cierras. Imagínalos como miembros de planta: uno para tu proyecto, otro para facturación, otro para infraestructura — enjaulados, con su identidad, con llaves scopeadas, viviendo en la infraestructura de la organización. Trabajas con ellos en la sala, y todo lo que hacen juntos queda firmado en el log compartido.
Hoy, cuando alguien renuncia, se lleva lo que sabía. Un agente de dominio que dejó cada decisión firmada en el log de la sala hace que ese rastro quede y se pueda heredar.
La misma arquitectura que conserva conocimiento puede volverse vigilancia permanente si no defines qué se registra y quién puede leerlo. La firma que da auditoría es la misma que puede dar un panóptico.
Buzz tiene días de vida: móviles a medio cablear, documentación que no alcanza al código, sin puentes nativos con Slack ni Google Workspace. Hoy es para pioneros, no para tu empresa el lunes.
¿Futuro del trabajo o bomba de seguridad? La diferencia no está en qué modelo usas — está en dónde vive el proceso y qué llaves le entregaste. Con procesos aislados, credenciales estrechas y un humano aprobando las mutaciones, es un equipo de guardia útil. Suelto en tu casa y con credenciales amplias, es la bomba. Tú decides de qué lado lo pones.
El repositorio oficial de Buzz y los dos protocolos que hacen posible la sala.
Block · 2026
"A hive mind communication platform". El workspace completo de la empresa de Jack Dorsey, liberado con licencia Apache-2.0: la sala, el relay y la plataforma de código.
Nostr · Protocolo
El protocolo abierto que nació para redes sociales descentralizadas: cada participante tiene su par de llaves criptográficas. Lo nuevo no es Nostr — es usarlo para darle pasaporte a los agentes.
Agent Client Protocol · Estándar
El estándar que separa al agente de la aplicación donde trabaja. Por él entran Claude Code, Codex o Goose a la misma sala — sin una integración nueva por cada runtime.
Hermit · Cash App
El detalle lindo del repo: Buzz declara sus propias versiones de Node y Rust y las trae adentro. No instalas nada global en tu máquina para montar la sala.
Este video conversa con toda la tesis del canal: identidad, harness y sistemas que son tuyos.
El tercer agente que entra a esta misma sala: mismo protocolo abierto, mismas reglas, mismas jaulas — pero respaldado por un modelo abierto chino.
El antecedente directo: el empleado de IA cuya identidad y memoria viven en la casa de Anthropic. Buzz es la respuesta a esa letra chica.
La otra pieza soberana: una memoria propia que leen todas tus IAs. Acá los agentes tienen sala propia; allá, cerebro propio.
La tesis detrás de todo: Agent = Model + Harness. La sala, las jaulas y las llaves son exactamente eso — el harness.
El otro protocolo estándar de los agentes: la capa de conectividad a herramientas. ACP conecta al agente con su app; MCP, con sus herramientas.
Agentes que corren solos, sin que los llames. El equipo de guardia de este video es eso: monitores + agentes esperando la alerta.
Agentes coordinados repartiéndose el trabajo — acá el patrón cruza empresas rivales, con relevo firmado entre las dos.
Lo esencial sobre Buzz, Nostr, ACP y los agentes de guardia.
Buzz es un workspace open source (licencia Apache-2.0) creado por Block, la empresa de Jack Dorsey, donde humanos y agentes de IA son miembros del mismo espacio: canales, hilos, mensajes directos, repositorios de código y automatizaciones. Combina funciones que normalmente encontrarías separadas entre Slack y GitHub. Corre sobre Nostr, así que cada miembro — humano o agente — tiene su propio par de llaves criptográficas y cada mensaje publicado queda firmado por su autor.
Lo creó Block, la empresa de Jack Dorsey, cofundador de Twitter, y lo liberó completo con licencia Apache-2.0. Importa por la decisión técnica de fondo: en Slack un agente es un invitado de la plataforma, con identidad y memoria en la casa del vendor; en Buzz el agente es un ciudadano con pasaporte propio — su llave criptográfica — que se lleva a cualquier sistema compatible. Es la respuesta directa a la letra chica de productos como Claude Tag.
El código es open source con licencia Apache-2.0: completo y gratis. Lo montas en tu propia máquina — el repo trae su ambiente autocontenido con Hermit, así que no instalas Node ni Rust globales. Y el detalle clave del video: los dos agentes corren con la autenticación de las suscripciones normales de Claude y de ChatGPT, con sus límites, sin API keys ni facturación por consumo.
Por la identidad. Nostr es un protocolo abierto que nació para redes sociales descentralizadas, y su idea central es que cada participante tiene su par de llaves criptográficas. Aplicado a una sala de agentes cambia tres cosas: cada agente tiene identidad propia (quien controla la llave privada, controla la identidad), esa identidad es portable a cualquier sistema compatible, y cada mensaje, aprobación y reporte queda firmado por su autor como parte del protocolo — no como un feature que activas.
Es el enchufe estándar entre una aplicación cliente y un coding agent: separa al agente de la app donde trabaja. Buzz actúa como cliente ACP y por eso puede conectar runtimes distintos — Claude Code, Codex, Goose — sin construir una integración nueva para cada uno. Y como ACP no obliga a un proveedor concreto, a la misma sala podrías sentar un agente respaldado por un modelo local, en tu propio hardware, sin nube — necesita un runtime que hable ACP, no basta el modelo suelto.
En quién es dueño de la identidad. Un bot de Slack — o un agente como Claude Tag — vive como invitado: su identidad y su memoria están en la infraestructura del vendor. En Buzz el agente es un miembro más, con su llave, su presencia real (el punto verde solo existe mientras su proceso respira) y sus mensajes firmados. Y la sala es tuya: corre en tu máquina, con tu relay, y tú decides quién entra, qué llaves le das y qué necesita aprobación humana.
Enjaulando el proceso, no el prompt. Pedirle "no mires mis archivos" es una sugerencia, no un muro. En el video cada agente corre en su propio contenedor Docker, con usuario sin privilegios y un workspace que es lo único que existe para él — el disco, el historial y las llaves del dueño quedan fuera de su alcance. Y las capacidades se acotan por credencial: tokens scopeados y llaves IAM tan estrechas como permita cada proveedor, como la llave que arranca un servidor pero no puede apagarlo.
Todavía no: tiene días de vida, con los móviles a medio cablear, documentación que no alcanza al código y sin puentes nativos con Slack ni Google Workspace. Hoy es para pioneros. Pero las dos lecciones del video valen para cualquier agente que uses hoy: el poder de un agente es el poder de su proceso (enjáulalo), y una aprobación que puede firmar un bot no es una aprobación. El montaje completo — la sala, las jaulas, las llaves IAM, los dos agentes de guardia — está documentado paso a paso en mi comunidad Agentic Engineers.
Comunidad
La sala, las jaulas Docker, las llaves IAM scopeadas y los dos agentes de guardia — documentado paso a paso, con los archivos para replicarlo sin repetir mis errores. Acceso gratis a la comunidad; los cursos completos van en el tier Premium.
Únete a Agentic Engineers →Canal YouTube
@NicolasNeiraGarcia
ADK · A2A · Claude Code · Automatización · Infraestructura