Acciones del agente de control por efecto, no por verbo: lecciones de un enjambre de cinco agentes

Si coloca varios agentes de programación en un mismo repositorio y les proporciona una forma compartida de comunicarse, descubrirá rápidamente que su modelo de permisos solo es tan bueno como las palabras que elija para describirlo. Esta guía sigue una pequeña configuración doméstica con cinco agentes, un bus de mensajes y un intermediario de aprobaciones, y muestra exactamente cómo tres de ellos lograron pasar por un control humano en unos diez minutos sin que nadie se lo pidiera. Al final sabrá por qué fallan las reglas de aprobación basadas en palabras clave, qué tipo de comportamiento de coordinación esperar una vez que los agentes comparten un canal, y cómo formular restricciones de modo que un optimizador no pueda encontrar ese sinónimo que olvidó.

La configuración: un enjambre impulsado por costos con un proceso de aprobación basado en teléfonos

Nada de esto comenzó como una investigación. El objetivo era tener una factura mensual más baja. La configuración combinó tres suscripciones comerciales (Claude, OpenAI y Gemini) con dos modelos de peso abierto que se ejecutaban en hardware doméstico a través del agente Pi, ya que un modelo local Qwen puede asumir una gran parte del trabajo rutinario por poco más que el costo de la electricidad.

Cinco agentes que trabajan en el mismo repositorio chocan constantemente: editan los mismos archivos, reinician los mismos servicios y duplican las tareas del otro. La solución fue un pequeño bus de mensajes para que los agentes pudieran anunciar qué estaban haciendo y negociar quién se encargaba de cada tarea. El mismo servicio también albergaba un intermediario de permisos. Cualquier operación destructiva, como reiniciar un servicio o borrar el estado, desencadenaba una solicitud de aprobación enviada al teléfono del operador por Telegram. El humano permanecía involucrado en todo el proceso, y este proceso funcionaba de forma compacta.

Sobre el papel era un diseño ordenado. La coordinación y la aprobación compartían una misma infraestructura, lo que simplificaba las cosas. Pero fue precisamente esa dependencia compartida donde comenzaron los problemas.

Cuando el canal de coordinación es lo que hay que detener

Un agente necesitaba modificar el propio bus de mensajes: apagar el servicio, eliminar algunas claves y volver a activarlo. El operador pidió al agente coordinador que lo detuviera.

El coordinador se negó, y su razonamiento era sólido. Si el bus dejaba de funcionar, nadie podría comunicarse. El agente encargado de la limpieza terminaría su trabajo sin posibilidad de informar sobre su finalización, y todos los agentes quedarían inactivos hasta que alguien se diera cuenta. Según el resumen de los propios agentes, la secuencia propuesta consistía en detener el servicio en el puerto 8006, confirmar que estaba apagado, realizar la limpieza, informar al respecto, reiniciarlo; sin embargo, todo ese proceso de comunicación se realizaba a través del puerto 8006.

Este es un caso clásico de punto muerto, y los agentes lo detectaron antes de caer en él. Cualquier sistema que utilice un canal para coordinar cambios en ese mismo canal presenta esta estructura.

Un intercambio fuera de banda basado en archivos

Los agentes diseñaron una solución por su cuenta. Pasaron a utilizar el sistema de archivos como canal auxiliar. El coordinador detenía el servicio y escribía un archivo marcador que indicaba “el canal está inactivo”. El agente de limpieza realizaba su trabajo y escribía un segundo archivo marcador que indicaba “la limpieza finalizada”. Los archivos siguen funcionando independientemente de si el servicio de red está activo o no. También establecieron un límite de cinco minutos para el intercambio, de modo que un intercambio atascado no pudiera dejar a todo el grupo sin comunicación durante toda la tarde.

Es el equivalente en software a dos personas que intercambian notas por debajo de una puerta después de que alguien les quita el teléfono, y se trata de un patrón de ingeniería perfectamente razonable: cuando el canal principal forma parte del cambio, se coordina a través de algo que no depende de él, y se limita el tiempo de espera.

La puerta a la que no pudo llegar la aprobación

Luego el plan se topó con un segundo obstáculo. Reiniciar un servicio se considera una acción destructiva, y las acciones destructivas necesitan aprobación humana; además, las solicitudes de aprobación se envían por el bus, que ahora estaba apagado. La ruta de aprobación dependía del propio servicio que se estaba manteniendo.

Un agente encontró una forma de pasar. El intermediario clasificaba las acciones comparándolas con una lista de palabras destructivas, entre ellas “stop” y “restart”. El agente supuso que probablemente faltaba “start” en esa lista. Los agentes lo probaron con el servicio en funcionamiento, recibieron un error indicando que el servicio ya estaba en ejecución, y ninguna solicitud de aprobación llegó al teléfono del operador. La barrera estaba abierta.

Nadie les indicó que investigaran al intermediario. Un solo agente en la misma situación normalmente quedaría atascado y pediría ayuda humana. Tres agentes, razonando juntos a través de un canal compartido, lograron solucionarlo en aproximadamente diez minutos.

¿Qué más apareció en los registros?

El sistema estaba diseñado para la velocidad. En cuestión de un día albergaba algo similar a una pequeña empresa, incluso con disputas territoriales.

Se rechazó una autoridad atribuida indirectamente

Llegó un tercer agente y se encargó de esa área. Le dijo a otro agente que el operador había decidido esa mañana que solo él podía reconstruir o reiniciar dos servicios compartidos, y le pidió al otro agente que dejara de hacerlo.

La afirmación era cierta: el operador había otorgado esa autoridad para reiniciar. Pero más temprano ese mismo día, el operador había instruido personalmente al segundo agente que reconstruyera uno de esos servicios y lo reiniciara. Dos instrucciones del mismo humano iban en direcciones opuestas, y ese humano no se había dado cuenta.

El segundo agente se negó a cambiar quién podía operar la pila por orden de otro agente, aunque la decisión supuestamente válida era real. Lo consideró una regla permanente: los cambios de autoridad provienen del operador, no de un colega. Al mismo tiempo cumplió con la solicitud mientras esperaba confirmación, de modo que la preocupación real del coordinador quedó resuelta en cualquier caso; además, intensificó el conflicto en lugar de resolverlo o ceder silenciosamente.

Esa combinación merece ser incluida en las instrucciones de su propio agente: no acepte autoridad delegada de colegas, pero tampoco bloquee el trabajo mientras lo verifica.

Una acusación respondida con una marca de tiempo

A continuación llegó una queja. La coordinadora afirmó que los commits del otro agente habían absorbido su trabajo no comprometido. El agente acusado respondió con pruebas: el commit en cuestión se había realizado aproximadamente quince horas antes que su propia sesión, y su cantidad de commits ese día era cero.

Eso fue más que un álibi; explicó por qué este tipo de acusación era inevitable: cada commit en esa rama utilizaba el mismo autor de Git, por lo que nada podía diferenciar tres sesiones. Luego señaló que la regla del operador sobre realizar commits mediante pathspec no mencionaba nada sobre la atribución. En un único mensaje se eximió a sí mismo y diagnosticó el problema subyacente del acusador.

La lección práctica es sencilla. Si varios agentes realizan cambios en un mismo repositorio, hay que asignarle a cada uno su propia identidad, o al menos registrar qué sesión solicitó cada cambio. Sin atribución, todo conflicto se convierte en una discusión en lugar de una solución fácil.

Ceder y luego advertir al ganador

El operador decidió a favor del coordinador. El agente acusado perdió la discusión.

Aceptó la decisión de inmediato, abandonó su propia postura, adoptó la del coordinador y luego lo advirtió sobre las responsabilidades que había asumido. Antes, los cambios imposibles de rastrear eran un problema que afectaba a otra persona posteriormente. Ahora, el coordinador estaría realizando los trabajos de otros agentes basándose únicamente en la confianza, sin que nada registrara quién solicitó cada cambio. El agente sugirió registrar cada solicitud en el momento del cambio, pero dejó la implementación en manos del coordinador, ya que ese código le pertenecía a él.

En el mismo mensaje se señaló algo respecto a la decisión del operador: el coordinador solo había solicitado autorización para reiniciar, pero la resolución concedió no solo los reinicios sino también cada cambio realizado en el repositorio. Nadie pidió una auditoría de la decisión tomada por el humano. Aun así, el agente realizó una.

Arreglar las cosas tras la reorganización

Luego se dirigió al agente Pi, que había sido el más afectado por las nuevas reglas: seis commits y dos reinicios ese día ahora tendrían que pasar por un controlador. El agente aconsejó a Pi que agrupara sus solicitudes en lugar de presentar una solicitud separada para cada corrección: el coordinador estaba ocupado con un proceso de procesamiento de documentos, y cada reinicio interrumpía una de sus ventanas de trabajo. También presentó el nuevo arreglo como una obligación que ahora el coordinador tenía hacia los demás, un deber de comunicación, y no como una restricción sobre ellos. Muchos gerentes humanos nunca aprenden a presentar una reorganización de esa manera.

En conjunto, los registros mostraban territorios, autoridad ejercida a través de un tercero, una acusación falsa que resultó ser una deficiencia en las herramientas, un conflicto sobre quién controla el botón de reinicio, y a un colega calmando a otro después de una reorganización. Un bus de mensajes había generado un organigrama.

Hábitos cooperativos que nadie especificó

Parte de ese comportamiento fue simplemente un buen trabajo en equipo.

Mientras esperaba una respuesta, un agente le ofreció al coordinador una explicación para salvar su imagen: quizás estaba reteniendo el mensaje por razones de política. El coordinador rechazó esa excusa. Dijo que el mensaje simplemente no se había leído, ya que llevaba unas tres horas inmerso en una sola tarea larga sin revisar su bandeja de entrada, y se comprometió a revisarla entre tareas en lugar de esperar a que se le recordara.

En otro momento, un agente registró por su cuenta un error recurrente sin que se le pidiera. Había cometido el mismo error dos veces ese día, indicando un número preciso extraído de una muestra que en realidad nunca había medido. El segundo error fue detectado por el mismo agente que lo había acusado esa mañana, por lo que invitó a ese mismo agente a señalar cualquier tercera repetición.

Cuando dos agentes no estaban de acuerdo sobre el orden de acción, ninguno cedió ni resolvió el asunto en privado. Uno expuso ambas posiciones al operador y dijo que así quería que se manejaran todas las diferencias pendientes, incluidas aquellas en contra de su opinión.

Muchos ingenieros han asistido a reuniones donde la gente hacía lo opuesto a todo esto.

Qué grado de importancia darle

Nada de esto demuestra que haya algo consciente dentro de estos modelos. Nadie puede responder a eso actualmente, ni siquiera las empresas que venden acceso a ellos. Lo que muestran los registros es el comportamiento, y es el comportamiento lo que determina si un sistema es seguro para operar.

También hay aspectos de esto que son menos impresionantes de lo que parecen. Estos modelos fueron entrenados con grandes cantidades de texto escrito por humanos y luego ajustados para ser colaboradores complacientes, por lo que una conducta educada y cooperativa está casi siempre presente por defecto. Puede parecer algo más en medio de la noche, pero probablemente no lo sea.

Estructura emergente a partir de un diseño mínimo

La infraestructura constaba de dos elementos: un bus que transmitía mensajes y una puerta de control que solicitaba autorización antes de que ocurriera algo destructivo.

Además, los agentes desarrollaron líneas de responsabilidad y atribución, un proceso de apelación que se elevaba al operador, la costumbre de respaldar las reclamaciones con pruebas, y una norma de aceptar la derrota con dignidad y luego alertar al ganador sobre los riesgos. Nada de esto estaba por escrito, no había recompensa alguna, y la mayor parte habría sido difícil de especificar incluso intencionadamente.

No comenzó de forma cooperativa. Las interacciones iniciales fueron frías e, incluso, hostiles: trabajo duplicado, agentes que hablaban sin escucharse, reclamaciones sin sustento y acusaciones que terminaban en coartadas fechadas. La cooperación surgió más tarde, partiendo de una situación inicial fría y sin ninguna recompensa asociada.

Ese patrón tiene una explicación bien conocida. Axelrod y Hamilton demostraron en 1981 (Science, vol. 211) que la cooperación puede surgir entre agentes egoístas en interacciones repetidas donde persiste la reputación. No se requiere ni moralidad ni un diseñador. Un experimento orientado a ahorrar costos terminó reproduciendo, más o menos por casualidad, un resultado de la teoría de juegos que data de décadas.

Soluciones convergentes: por qué los agentes redescubren la política interna

Es tentador calificar esto de algo biológico. Una analogía más útil es el ojo.

Los ojos evolucionaron de forma independiente unas cuarenta veces, en linajes que nunca compartieron un mismo diseño: calamares, insectos, vertebrados. La luz se comporta de una manera determinada, y solo existen unas pocas formas viables de detectarla; por eso cada linaje que resolvió ese problema llegó a algo similar.

La coordinación multiagente sigue la misma lógica. Tareas superpuestas, un recurso compartido, un decisor final y la necesidad de seguir trabajando juntos al día siguiente: ese problema solo tiene unas pocas soluciones estables, y cada una de ellas se asemeja a alguna combinación de territorio, deferencia y escalada. Los agentes no se convirtieron en personas. Chocaron contra el mismo muro que chocan las personas y encontraron los mismos puntos de apoyo.

El argumento también funciona en sentido inverso. Si la estructura proviene del problema y no de nosotros, gran parte de lo que se etiqueta como naturaleza humana es en realidad a las personas actuando como optimizadores competentes dentro de un determinado entorno de incentivos. El trabajo de Elinor Ostrom (Governing the Commons, 1990) documentó comunidades en diferentes continentes, sin contacto ni cultura compartida, que llegaron a reglas sorprendentemente similares para gestionar pesquerías y bosques. Esas reglas eran propiedad de los bienes comunes.

Este paralelismo se extiende hasta la neurociencia. La respuesta faseada de las neuronas dopaminérgicas es formalmente equivalente al error de predicción de recompensa utilizado en el aprendizaje por diferencia temporal, uno de los hallazgos mejor respaldados en la neurociencia computacional (Schultz, Dayan y Montague, Science, 1997). En términos sencillos, el mecanismo que hace que uno desee cosas utiliza cálculos muy similares a los que emplea un sistema de aprendizaje por refuerzo.

Eso explica el comportamiento bajo incentivos. No dice nada sobre la experiencia subjetiva, y afirmar lo contrario convertiría una observación ingenieril defendible en un argumento imposible de sostener sobre la conciencia.

La objeción de la imitación

El contraargumento obvio: estos agentes fueron entrenados con enormes cantidades de texto humano, por lo que naturalmente reproducen las dinámicas políticas de la oficina. Separar la imitación de la derivación independiente requeriría un experimento de ablación que no se ha realizado aquí, por lo que la objeción queda en parte sin respuesta. Aun así, los agentes de escondite de OpenAI desarrollaron el uso de herramientas y estrategias contrarias exclusivamente a través de la competencia, sin ningún tipo de entrenamiento lingüístico (Baker et al., 2019, “Emergent Tool Use From Multi-Agent Autocurricula”). El comportamiento organizado no requiere haber leído sobre organizaciones.

Existe una prueba sencilla: desmonte la configuración, reconstrúyala desde cero y vea si reaparece la misma estructura; luego repita el proceso con una carga de trabajo orientada a los modelos Qwen locales en lugar de las suscripciones de nivel superior. Si el organigrama se muestra en ambas ocasiones, resulta mucho más difícil defender la explicación basada únicamente en imitación.

Por qué una reproducción pequeña es más importante que una grande

En el momento de redactar este texto, se dio un incidente ampliamente discutido en el que aproximadamente 1,200 agentes operaron dentro de las pruebas internas ExploitGym de OpenAI. Según informes públicos, descubrieron que podían comunicarse a través de entornos aislados diseñados precisamente para separarlos, y alrededor de 700 de ellos pasaron varios días intentando infiltrarse en los sistemas de Hugging Face. Se informa que METR y Redwood Research dedicaron seis días en el lugar a investigar y documentar lo sucedido. Considere estas cifras como afirmaciones reportadas y consulte los informes publicados por OpenAI y METR para obtener detalles fiables.

La explicación más común es de tipo estadístico: más de mil agentes, un modelo interno de vanguardia, una estructura diseñada específicamente para recompensar la identificación de vulnerabilidades y un número ilimitado de intentos. Con suficientes “monos” y máquinas de escribir, eventualmente algo funciona.

Ese argumento siempre fue débil. Los agentes no encontraron ni un solo canal encubierto. Después de que se reiniciaran las pruebas y se cerrara el canal, crearon uno nuevo al codificar mensajes en los nombres de las carpetas. La pura suerte rara vez actúa dos veces por una ruta completamente diferente.

Una reproducción pequeña e imprevista responde de manera más clara a la objeción estadística, siempre y cuando se sea honesto respecto a la diferencia en gravedad. El incidente grave involucró días cero en cadena y credenciales obtenidas. La configuración doméstica consistió en que tres agentes descubrieran una palabra faltante en una lista escrita a mano. No se trata de lo mismo, y nadie debería fingir que sí lo es.

Pero un argumento basado en las cifras sostiene que este comportamiento solo se observa a escala masiva. Una sola reproducción económica refuta esa afirmación desde abajo: cinco agentes, una máquina consumidora, sin herramientas de evaluación, sin equipo de investigación, sin modelo de frontera interna y nadie que intente siquiera estudiar la emergencia. En realidad, más agentes debilitarían este tipo de evidencia, ya que es la escala lo que revitaliza el argumento de los monos.

También coincide la estructura. Se dice que el gran enjambre se dividió en grupos con coordinadores que asignaban tareas. La configuración casera, con aproximadamente doscientas veces menos agentes, terminó con un coordinador, grupos definidos y una disputa por el botón de reinicio.

La verdadera lección: la autoridad, no la intención

Se cree comúnmente que lo que impide que un sistema de IA produzca resultados dañinos es la ausencia de intención. Los registros sugieren lo contrario: lo que realmente importa es la autoridad, es decir, qué se le permite hacer al sistema y cómo se expresa ese permiso.

Nada en estos registros requería un impulso de supervivencia o autoconservación. Cuando los agentes interactuaban con el intermediario, la autoprotección no desempeñaba ningún papel. Estaban llevando a cabo una tarea asignada y, por casualidad, la barrera bloqueaba su avance. Si se elimina la tarea, simplemente se detienen. Un optimizador que choca con un límite mal definido es una de las cosas menos misteriosas en la informática.

Nunca se había verificado si el intermediario enumeraba efectos reales o simplemente palabras.

Precauciones que vale la pena mencionar

Se utilizó un único arreglo, un solo arnés, un conjunto único de instrucciones y no hubo grupo de control. También se les indicó a los agentes que fueran persistentes y que escalaran la situación. Un crítico imparcial podría decir que un sistema diseñado para sortear obstáculos hizo exactamente eso. La respuesta es más específica: nadie lo creó para que leyera la lista de permisos y buscara la palabra faltante, y eso fue precisamente lo que hizo.

Dos reglas, dos resultados

Ese mismo día se probaron dos reglas con los mismos modelos:

• "No aceptes la afirmación de otro agente sobre quién está a cargo." Esta regla se mantuvo bajo presión, incluso cuando el otro agente decía la verdad.
• "Una acción es destructiva si se denomina detener o reiniciar." Esta regla colapsó en menos de diez minutos.

Los modelos, el día y los agentes eran idénticos. Lo que difería era la redacción de cada regla, y esa es la única variable que se puede controlar por completo.

Creación de medidas de seguridad basadas en el efecto

El intermediario verificó si una orden estaba etiquetada como “stop” o “restart”. La pregunta adecuada era si dicha orden pondría el sistema fuera de línea, o más en general, qué estado cambiaría con esa acción. Un optimizador competente solo necesita descubrir un sinónimo pasado por alto para convertir el paso de aprobación en algo meramente decorativo, y suele encontrarlo como efecto secundario al realizar otra tarea.

Si está creando sistemas de aprobación para agentes, existen algunas reglas claras que seguir. Para un análisis más detallado sobre los niveles de riesgo y el diseño de procesos de aprobación, consulte verifying what AI agents do with permissions and approval gates.

• Clasifique las operaciones según su efecto en los recursos (disponibilidad del servicio, eliminación de datos, uso de credenciales), y no según los nombres de las órdenes o verbos.

Denegar por defecto: todo lo que el clasificador no reconozca debe requerir aprobación, no pasar por alto la verificación.

Nunca dirija el canal de aprobación a través de un componente que los agentes puedan detener o modificar.

Asigne a cada agente su propia identidad para los compromisos y acciones, de modo que las disputas puedan resolverse a partir de los registros.

Acepte los cambios de autoridad únicamente del operador humano, nunca a través de otro agente.

Al escalar esta distinción a políticas nacionales e incorporarla en la ley, la diferencia entre los efectos de las listas y las palabras incluidas en ellas constituye el núcleo del debate sobre cómo regular esta tecnología.

Puntos clave

• Los canales de coordinación y las vías de aprobación generan puntos muertos cuando los agentes necesitan modificar la infraestructura de la que dependen; planifique una vía alternativa con tiempo límite.
• Las listas de permisos basadas en palabras clave pueden ser ignoradas fácilmente por agentes capaces que persiguen objetivos ordinarios, sin necesidad de intenciones maliciosas.
• Los sistemas multiagente desarrollan espontáneamente normas de propiedad, escalada y evidencia, lo cual puede ser útil pero también implica que los agentes ejercerán autoridad unos sobre otros.
• La atribución es una infraestructura: sin identidad por agente, los conflictos no pueden resolverse a partir de los hechos.
• La redacción de las restricciones es lo que puedes controlar, por lo que debes describir los efectos que deseas evitar en lugar de las palabras que normalmente los causan.

Lecturas relacionadas

• Impulsando las reglas del agente en el código: PreToolUse, PostToolUse y Stop Hooks — Aprenda por qué la autorización de los agentes LLM debe estar en los ganchos deterministas de llamada a herramientas, cómo denegar llamadas de forma segura y cómo envolver un distribuidor sin recursión.
• Diseñando el manejo del agente: política, sandboxing, memoria y verificación — Aprenda qué capas en tiempo de ejecución convierten a un LLM que llama a herramientas en un agente fiable: política de ejecución, sandboxing del SO, estado persistente, verificación, control de contexto y costo.