Un simulador de hormigas cuestiona cómo se orquestan los agentes de IA

Un desarrollador ha reescrito su simulador de colonias de hormigas, le ha metido instrumentación y ha sometido a prueba las reglas que él mismo había programado. El resultado contradice parte de su propio diseño: el tablón público de tareas sostiene casi todo el reparto de trabajo, mientras que el mecanismo que consideraba imprescindible para amortiguar el comportamiento de la colonia lo empeora. El código está en el repositorio y las cifras se reproducen con pnpm sim:ablation sobre el commit d430093.

Cómo reparte el trabajo la colonia

No hay ninguna hormiga que asigne tareas a otra. Cada una lee un tablón público de necesidades, donde se anota cuánto trabajo se ha pedido y cuánto se ha entregado últimamente, lo combina con su propia estimación de lo concurrida que está cada tarea y compara su ocupación actual con la alternativa más urgente. Según su umbral individual, cambia o se queda. Lo que llamamos comportamiento de la colonia sale de esas decisiones sueltas y de los acoplamientos entre tareas.

El autor marca los límites: la biología de las hormigas recolectoras que estudia Deborah Gordon motiva partes del diseño, pero no valida cada mecanismo escrito en el código. Y lo que se deduce para agentes de IA son propuestas, no resultados de un benchmark de agentes.

Para ver qué pieza hace qué, ejecutó ablaciones sobre los mismos ocho mundos generados. En cada ejecución muere la mitad de las recolectoras en el minuto 50. Mide desviación respecto al equilibrio, tiempo con la recolección desatendida, cambios de tarea por hormiga y minuto, y qué ocurre después del golpe.

Sin tablón, la recolección queda desatendida el 100% del tiempo y tres de los ocho mundos se quedan sin comida. El error de seguimiento pasa de 0,74 a 1,81.

El tablón aguanta, la estimación estorba

La estimación de aglomeración va en contra de lo que él esperaba. Quitarla baja el tiempo desatendido del 76% al 22%, mejora el error de seguimiento y permite que siete de ocho colonias se recuperen tras el golpe, en 6,1 minutos de media. Su único mérito es que menos hormigas se lanzan a la vez a por comida: el mayor pico de forrajeo sube de 16 a 28 individuos sin ella.

La compuerta de muestreo produce un efecto que su autor no buscaba cuando la añadió. La hormiga espera a haberse cruzado con trabajadoras de al menos seis de las ocho tareas antes de volver a decidir, lo que recorta los cambios de tarea en torno a un tercio. Si se eliminan a la vez la compuerta y la estimación, 73 hormigas se mueven hacia el forrajeo tras el golpe, unas cuatro veces más que con la regla completa, y la recuperación resulta la más rápida de todas. Una estampida sirve cuando da la casualidad de que va en la dirección correcta.

Los umbrales distintos por hormiga apenas mueven las métricas. Él tenía una historia sobre cómo su variación amortiguaría la oscilación; las ejecuciones no la respaldan.

Uno de los hallazgos más útiles salió de un bug. El tablón guardaba cada unidad de trabajo pedida y entregada desde el inicio, así que la necesidad dividida entre el trabajo real se iba convirtiendo poco a poco en un promedio de vida entera y dejaba de describir lo reciente. El arreglo apunta a una condición general: la señal tiene que hablar del trabajo reciente, no de la historia acumulada.

El autor no ha comparado este sistema con un despachador central, ni ha medido plazos, ni ha puesto precio al coste de cambiar de agente. Son cosas que el simulador deja a tiro de prueba, no que resuelva. Para quien esté montando un pool de agentes, la hipótesis que queda en pie es que un tablón con la demanda actual quizá haga casi todo el trabajo de asignación, que contar cuántos compañeros andan en cada tarea solo amortigua si se muestrea bien, y que retrasar las decisiones tomadas con poca información reduce a la vez las estampidas y el vaivén.