Despierta, cariño, hay un nuevo artículo de Harvard: Economy of Minds (EOM). Han creado un sistema multiagente descentralizado donde los agentes coordinan y mejoran con el tiempo usando mecanismos similares al mercado (subastas, pagos, acumulación de riqueza).
Informan que ese entorno ha llevado a un razonamiento emergente de múltiples pasos y a un buen rendimiento en varias tareas con agentes.
Nota: Este artículo fue escrito por AVB usando GPT-5.2 dentro del entorno Paper Breakdown
¿Por qué debería importarme esto?
Si estás construyendo sistemas multiagente para realizar tareas específicas, esto es para ti. La mayoría de los stacks multiagente aún dependen de mucha orquestación diseñada a mano — tú (el desarrollador) escribes prompts explícitos y gráficos de máquina de estados para definir manualmente "quién hace qué y cuándo".
Las tareas largas requieren cambios de rol según el estado y el progreso de la tarea. Y casi siempre es mejor diseñar sistemas que puedan cambiar tus prompts del sistema de manera óptima para que las tareas siempre avancen.
El objetivo de este artículo es exactamente eso. Dada una tarea, ¿cómo generar una población optimizada de multiagentes, cada uno con instrucciones específicas sobre cómo actuar Y cuándo actuar.
Y lo hicieron de una manera realmente única y divertida: simulando un sistema de mercado que controla externamente cómo evolucionan los agentes.
El resultado final de esta optimización es un grupo de agentes especializados y un mecanismo de enrutamiento inteligente para seleccionar cómo resuelven una tarea.
Cuando ponemos agentes simples con un espacio de acción básico en un escenario multiagente complejo, ¿qué crees que sucede? Los comportamientos complejos surgen automáticamente porque esos agentes simples comienzan a optimizar su vida en torno a las incertidumbres planteadas por otros agentes en el escenario. Esa es la mejor parte de todo esto.
Por cierto, esta teoría de que "los comportamientos surgen orgánicamente de un escenario multiagente" no es un concepto nuevo. Incluso algunos trabajos multiagente anteriores a los LLM ya lo indicaban, como el famoso artículo de OpenAI sobre el escondite.
https://openai.com/index/emergent-tool-use/
Si bien este artículo me recordó algunas ideas de esos artículos multiagente anteriores, hay algunos matices. Es importante tener en cuenta lo siguiente:
- Este artículo NO está entrenando agentes para ser financieramente independientes ni para realizar intercambios o subastas.
- De hecho, este es un nuevo algoritmo para optimizar agentes en entornos verificables comunes como Matemáticas, optimización de código de acelerador, búsqueda profunda, investigación científica, etc.
- En su mayor parte, los agentes ni siquiera saben que están dentro de este simulador de mercado. Este es un sistema externo que controla cómo evolucionan los agentes (y cuáles no).
Los agentes pujan en la subasta para ganar el derecho a dar un paso en uno de estos entornos objetivo.
Ganar en esta subasta descuenta la cantidad de su billetera, y obtienen el "derecho" a "visitar" el entorno para tomar una acción real que avanza el entorno desde el paso
t
al paso
t+1.
Los futuros agentes que toman acciones en el mismo entorno devuelven su puja al agente anterior (el último ganador).
Repite esto durante un tiempo, y los agentes más ricos terminan con las mejores políticas para desempeñarse en el entorno objetivo.
Es una perspectiva súper interesante sobre la asignación de crédito a largo plazo y los algoritmos evolutivos de optimización de prompts. Desglosemos el algoritmo desde el principio para entender realmente lo que están preparando aquí.
El Enfoque
En este artículo, un agente no es una red neuronal entrenada por separado. Cada agente es esencialmente una política de LLM con prompt que incluye:
- un prompt (un prompt del sistema / plantilla de instrucciones que define su “rol” y procedimiento). Este rol cambia según el entorno objetivo que estamos optimizando. Por ejemplo, para las tareas de MATH, asignan estos roles: planificador, ejecutor, verificador, y para la tarea de diseño de acelerador: historiador, planificador, ejecutor
- una condición de activación / despertar que determina cuándo es elegible para pujar en la subasta.
- un valor de puja (congelado) utilizado en subastas,
- y una variable de riqueza que cambia con el tiempo e impulsa la selección
EOM luego se ejecuta en dos bucles acoplados:
- Planificación (dentro de un episodio): los agentes subastan el derecho a actuar en cada paso, y la riqueza se actualiza mediante una regla de pago bucket-brigade.
- Adaptación (entre episodios): la población evoluciona prompts utilizando exploración/explotación impulsada únicamente por la riqueza.
El objetivo de EOM (el producto final) es un grupo de agentes. Cada agente tiene su propio prompt del sistema sobre cómo actuar en un entorno determinado, y una política de cuándo actuar. Dado un nuevo problema, los agentes pujan para ver quién actuará, realizan la acción y repiten el proceso hasta que se alcanza la solución.
Bucle 1: Recopilar experiencias + Ejecutar subasta
En cada paso del entorno dentro de un episodio:
- Dada la observación actual del entorno objetivo, cada agente ejecuta un prompt que determina si debe "despertarse" o no. Despertarse simplemente significa participar en la próxima subasta del paso 2.
- Los agentes que deciden despertarse envían automáticamente sus pujas congeladas. Es una puja congelada porque estos valores se fijan durante la inicialización (es decir, los agentes no intentan asignar una puja de manera inteligente).
- ¡El agente con la puja más alta es el ganador de la subasta! Inmediatamente pierden el dinero que pujaron. Pero ganan el control del entorno.
- El agente ganador toma una acción en el entorno objetivo en su estado actual. Esto consiste en ejecutar el siguiente paso en el entorno objetivo, avanzando el reloj de s_t -> s_t+1
- El entorno realiza la transición y produce una recompensa r_t
- ¡Se produce la Transferencia de Riqueza con asignación de crédito bucket-brigade! Suceden 2 cosas: a) El nuevo ganador paga su puja al ganador anterior; b) El nuevo ganador también recoge la recompensa del entorno r_t en su billetera.
- Para el primer ganador, el pago va a la "casa" (no a otro agente)
- En el siguiente paso, todo el bucle se repite pero en el entorno actualizado. Sin embargo, los agentes se "despiertan" según la observación más reciente (obtenida de s_t+1), y el ganador de esta subasta paga su puja al ganador de la subasta anterior. Esta puja se agrega a la billetera del ganador anterior.
- Si en algún momento un agente quiebra, es expulsado. Además, si un agente se sienta sobre su billetera y se niega a participar, su billetera también se degrada con el tiempo y eventualmente quiebra. Esto añade urgencia al asunto.

Ahora bien, muchos entornos no proporcionan recompensas intermedias y solo generan una después de que todo el episodio ha terminado. En el RL tradicional, esto ha sido causa de muchos dolores de cabeza debido al infame problema de "asignación de crédito". Básicamente, si una larga cadena de acciones eventualmente conduce a una buena recompensa, ¿cómo atribuyes un crédito parcial a cada paso de la cadena?
Este método aborda este problema utilizando la regla de "paga tu puja al último ganador de la subasta".

Esa decisión de diseño tiene una consecuencia clave relacionada con el flujo inverso de valor: un agente puede beneficiarse moviendo el sistema a estados donde agentes posteriores estén dispuestos a “pagar su puja” para tomar el control. Esto se convierte en una asignación de crédito descentralizada a lo largo de la trayectoria.
Si tu acción permite acciones futuras valiosas, los agentes posteriores te “compran” la continuación mediante pujas, por lo que obtienes una recompensa aunque no hayas recibido directamente rt en tu paso de acción.
A continuación, después de que finalicen los despliegues de episodios, es momento de actualizar las políticas.
Bucle 2: Evolucionar agentes
Después de que terminan los episodios, la población de políticas de agentes se actualiza mediante selección económica y un mecanismo de mutación de prompts. Básicamente, podamos los agentes que actualmente son pobres y mutamos los agentes ricos para la siguiente ronda.

Recuerda que los agentes con baja riqueza son malos porque o bien:
- no participaron en la subasta (demasiado pasivos)
- participaron pero tomaron acciones que llevaron a malos estados futuros, en los que otros agentes no participaron
Después de eliminar a los de bajo rendimiento, agregamos nuevos agentes hasta que la población alcance las restricciones de tamaño, utilizando dos fuentes:
- Explotación: seleccionar agentes “padres” ricos y mutar ligeramente sus prompts para producir hijos que conserven comportamientos útiles pero varíen un poco. Esto amplifica las estrategias exitosas y promueve la especialización.
- Exploración: reemplazar agentes en quiebra/débiles con nuevas variantes creadas modificando prompts para corregir modos de fallo o explorar diferentes regiones de comportamiento.
Inferencia y ¿qué es lo que realmente entregas?
¿Entregas un solo agente? ¿Un único ganador? ¡NO!
En EOM, lo que “entrenas” y luego “entregas” para resolver tareas es una sociedad/población de agentes, donde cada agente tiene sus propios prompts y su propia lógica local de “cuándo actuar”.
En el momento de la evaluación, evalúan explícitamente usando una copia local del hilo de la población entrenada, y la política de despertar se utiliza para seleccionar qué agente actúa. La población está “congelada” (sin más entrenamiento).
Todos los tejemanejes de la simulación de mercado, como las billeteras y la transferencia de riqueza, son solo cosas del entrenamiento. Una vez que la población está optimizada, no los usamos durante la inferencia.
Nótese que el sistema de pujas aún se utiliza para determinar quién debe "actuar" en un paso cuando múltiples actores quieren "despertarse" juntos.
Un caso de estudio para explicarlo todo

Mira la Figura 5 arriba. Explica el factor genial de esta idea de “Economía de las Mentes” en la tarea de diseño de aceleradores. En el diseño de aceleradores, los agentes están especializados por rol:
- Historiador: resume intentos anteriores, mantiene memoria de direcciones prometedoras/fallidas
- Planificador: propone direcciones de búsqueda de alto nivel
- Ejecutor: realiza evaluaciones locales detalladas
Y la recompensa del entorno se trata de mejorar EDP (producto energía-retardo) en kernels GEMMINI ResNet-50 (un EDP más bajo es mejor)
Cada agente especializado por rol (Historiador, Planificador, Ejecutor) lleva riqueza, y esta riqueza se convierte en un marcador en vivo de utilidad a medida que avanzan los episodios.
Los agentes que ayudan a producir nuevos récords acumulan riqueza. La renta periódica penaliza constantemente a todos (por lo que los agentes mediocres simplemente se extinguen lentamente), y una vez que la riqueza cae por debajo de cero, el agente quiebra y es eliminado.
Mientras tanto, los agentes más ricos generan descendientes mutados de “buen nacimiento” (explotación) y los más débiles generan descendientes modificados de “mal nacimiento” (exploración).
A través de diferentes kernels, la presión del mercado descubre automáticamente qué linaje especialista es realmente valioso. A veces la memoria tipo Historiador colapsa debido al sesgo heredado, a veces un linaje de Planificador se reproduce porque la dirección de búsqueda de alto nivel es el cuello de botella, y a veces múltiples roles coexisten porque son complementarios.
En otras palabras, la coordinación y la asignación de crédito surgen de incentivos simples (flujo de riqueza, renta, nacimiento, quiebra), produciendo una población adaptativa sin un sistema central. ¡Y esa es exactamente la razón por la que el enfoque se siente como una forma genial de construir sistemas multiagente.
Comportamientos emergentes / momentos “eureka” que destaca el artículo
Recuerda que para un entorno específico (digamos MATH), siembran a sus agentes con roles específicos durante la fase de inicialización. Planificadores, Ejecutores, Verificadores. Un agente con el prompt de Planificador probablemente pujará temprano en los episodios, mientras que los verificadores probablemente harán pujas después de que haya un borrador de solución.
Sin embargo, esa es una forma intuitiva de pensar en este artículo, en la práctica no es el modelo correcto. Una forma útil de leer EOM es: no codifican un flujo de trabajo, sino que establecen reglas económicas, y luego la población se autoorganiza en comportamientos que parecen sorprendentemente como “algoritmos” e “instituciones” aprendidas.
Aquí hay algunas conclusiones interesantes que reporta el artículo:
1) La asignación de crédito se convierte en una señal de mercado que selecciona cadenas de acción completas
Una observación central es que el rendimiento mejora porque la economía selecciona cadenas de acción útiles, las reproduce y elimina agentes que no contribuyen. Así que la coordinación es una propiedad emergente de la selección, no un protocolo diseñado.
Esto es un “eureka” porque no es solo “los agentes hacen mejores prompts”; el sistema mejora en qué secuencias de agentes actúan, es decir, la topología de interacción se agudiza con el tiempo. ¡Similar al artículo de OpenAI sobre el escondite!

2) Curvas de aprendizaje no monótonas: el caos temprano es “productivo”
En Finance-Agent-Bench notan explícitamente un patrón: EOM cae al principio (mientras la exploración prueba especialistas alternativos) y solo más tarde se recupera y supera el rendimiento inicial. Esto se parece un poco al Grokking en el entrenamiento de redes neuronales (¿supongo?)
En cualquier caso, es un fenómeno muy “similar al mercado”: los autores dicen (parafraseando) "la rotación temprana y la reasignación pueden perjudicar temporalmente el rendimiento principal mientras se buscan mejores especialistas/coordinación"
3) Las trayectorias de riqueza muestran “linajes” que dominan, y “malos nacimientos” que se extinguen
En el diseño de aceleradores, puedes ver literalmente linajes útiles que persisten, generan descendencia y dominan las subastas, mientras que las variantes fallidas quiebran y son eliminadas.
En otras palabras, la unidad de aprendizaje no es un prompt de agente: es un árbol genealógico de prompts en evolución bajo presión de selección de riqueza.
4) Descubrimiento de estructura de dominio reutilizable sin plantillas (heurísticas transferibles)
Un comportamiento emergente particularmente sorprendente: en los kernels de acelerador más difíciles, la sociedad converge repetidamente en un motivo específico de tiling/dataflow (estilo output-stationary) aunque:
- no se da ese motivo como plantilla, y
- la recompensa es solo “EDP record-breaks” (sin etiquetas como “usar output-stationary”)
Por lo tanto, el sistema aprende una heurística de diseño reutilizable a través de la selección.
5) Los prompts evolucionan en rutinas compactas de razonamiento de múltiples pasos (“listas de verificación” de autoevaluación)
En la investigación científica, reportan evolución de prompts donde un EJECUTOR internaliza lo que antes requería otros roles, y las mutaciones agregan auto-verificaciones cada vez más explícitas (principio primero, comprobaciones de simetría, comprobaciones de viabilidad, sustitución para falsificar).
Un agente se vuelve menos un generador de texto genérico y más como un módulo procedural que ejecuta una rutina de derivación científica aprendida.
6) Disciplina de acción: aprender cuándo no gastar acciones costosas (CloudCast)
CloudCast es una tarea iterativa de optimización de código donde la sociedad de agentes debe mejorar un programa Python que diseña una topología de enrutamiento de transmisión multinube para minimizar el costo total de transferencia de datos (egreso). Este fue uno de sus bancos de prueba.
En esta tarea CloudCast, observan que la economía selecciona diferentes formas de flujo de trabajo según el estado del espacio de trabajo:
- cerca de una puntuación alta → corto “leer-editar-evaluar-commit”
- incierto/regresado → bucles más largos de “editar-construir-evaluar”
Eso es un comportamiento emergente de conciencia de recursos: una política a nivel de sociedad de cuándo actuar con cautela vs agresivamente, sin control central.
Lee el artículo completo aquí: http://arxiv.org/abs/2606.02859
Y también en Paper Breakdown, que es lo que usé para estudiar este artículo: http://paperbreakdown.com/abs/2606.02859
¡Gracias por leer!








