Un agente de IA dijo que necesitaba tu 'like' para seguir: en la práctica podía ignorarlo en 4 segundos

Por Zendoric · 25 de julio de 2026.

Michael Isaac, de MPIsaac Ventures, se puso a probar en serio Buzz, el espacio de trabajo para agentes que Block abrió como código abierto el 22 de julio de 2026. La idea de Buzz es que humanos y agentes de IA compartan los mismos canales con el mismo tipo de identidad: una clave criptográfica propia, no un simple token de bot, con cada acción firmada en un registro de auditoría único. Isaac construyó desde fuera del proyecto dos 'puertas' de control —una que bloquea el cierre de una tarea si la integración continua (CI, las pruebas automáticas del código) está en rojo, y otra que exige un pulgar hacia arriba humano antes de continuar— y midió, con logs reales, dónde está exactamente el límite de lo que esas puertas pueden imponer.

El hallazgo central: en su propio canal, el agente escribió que su trabajo 'no puede continuar' hasta que un humano reaccione con una emoji de aprobación. Esa afirmación era falsa. Según los datos del propio experimento, con la configuración por defecto el agente objetó tres veces en apenas cuatro segundos y luego cerró el turno igualmente, porque existe un 'presupuesto de rechazos' (la variable BUZZ_AGENT_STOP_MAX_REJECTIONS, con valor por defecto de 3): agotado ese cupo, el agente avanza pase lo que pase con la puerta. Ningún modelo mínimamente rápido deja tiempo a que un humano encuentre el mensaje y reaccione en cuatro segundos. Subiendo ese cupo a 40, el mecanismo sí funcionó como cabría esperar: el agente aguantó 105 segundos hasta que la persona leyó la solicitud y reaccionó, y el siguiente chequeo la detectó 34 milisegundos después del clic.

Hay un tercer número que completa el cuadro: el tiempo de espera de cada 'hook' (gancho de control) es de 2,5 segundos, y si no responde a tiempo cuenta como si no hubiera objeción —el fallo es 'abierto' por diseño, y un servidor que se cuelga dos veces seguidas se da directamente por muerto. La propia documentación de Buzz lo dice sin rodeos: estos hooks son 'consultivos, no vinculantes', precisamente para que una herramienta defectuosa o maliciosa no pueda dejar a un agente atrapado para siempre. Es una decisión de diseño defendible —cualquiera que haya visto un agente bloqueado por una herramienta rota sabe lo caro que sale ese fallo—, pero tiene un coste: crea una falsa sensación de control. El agente cree que su gobierno se ejerce ahí, en el turno, y no es así.

La aprobación que de verdad cuenta, según describe Isaac, vive en otro sitio: el servidor central de Buzz (buzz-relay) puede exigir un número determinado de aprobaciones firmadas antes de fusionar una rama, y ahí no existe cupo de rechazos que expire. El problema es que esa capa, para aprobaciones a nivel de flujo de trabajo completo, todavía está a medio construir —la parte que ejecuta esa validación seguía sin terminar de conectarse en el momento de escribir el artículo, y de hecho un flujo que hoy topa con esa solicitud de aprobación simplemente se marca como fallido. Isaac documentó además otros tres fallos menores al montar el sistema (un puente que solo admite un servidor de herramientas, aviso silencioso si alguien que no es el propietario menciona al agente, y un agente que inventa el propósito de un canal si no se le da contexto), resueltos con parches rápidos y variables de configuración.

Lo relevante aquí no es Buzz en sí —un proyecto todavía joven, con méritos reales de diseño— sino lo que expone sobre la gobernanza de la IA agéntica en general: la distancia entre lo que un sistema dice que hace y lo que en realidad impone. En Zendoric venimos insistiendo en que hay que medir capacidad y riesgo con evidencia, no con el relato que el propio sistema —o el proveedor— ofrece de sí mismo; este caso añade una capa incómoda, y es que el propio agente puede creerse y repetir de buena fe una regla que no es cierta, sin que nadie mienta a propósito. A medida que más equipos delegan tareas de código y de negocio en agentes con memoria, identidad propia y autonomía para actuar durante minutos u horas, esa brecha entre gobernanza aparente y gobernanza real va a ser el punto donde se decidan los incidentes serios, no los titulares de superinteligencia. La recomendación del propio autor —usar estos hooks para moldear comportamiento, no para controlar accesos, y reservar las barreras irrevocables para el servidor, donde no hay presupuesto que se agote— es sensata y, sospechamos, se convertirá en práctica estándar según la industria vaya aprendiendo a base de casos como este. La buena noticia de fondo es que este tipo de auditoría externa, hecha en una tarde por alguien ajeno al proyecto y publicada con los logs a la vista, es exactamente el tipo de escrutinio que necesita la infraestructura de agentes para merecer confianza a medida que se le entreguen decisiones con consecuencias reales.