Teoría de juegos para arquitectura agéntica: tres conceptos que cambian el diseño

La mayoría del contenido sobre agentes de IA arranca por la herramienta: cómo configurar tool-calling, qué framework usar, cómo prompteás al orquestador. Está bien, pero se saltea una capa anterior: el diseño del juego que están jugando los agentes entre sí.

Y ahí la teoría de juegos tiene más para decir que cualquier tutorial de LangGraph.

Vengo de comercio exterior y contabilidad — dos disciplinas donde pensar en incentivos, información asimétrica y equilibrios es parte del trabajo diario. Cuando empecé a diseñar arquitecturas multi-agente para clasificación arancelaria y cálculo de costos de importación, me di cuenta de que los problemas que aparecían no eran técnicos. Eran problemas de diseño de mecanismo.

Tres conceptos clásicos, mapeados uno a uno con problemas reales que vas a encontrar el día que tu loop agentico deje de ser un demo y empiece a tomar decisiones que importan.

1. Información Asimétrica → Context Engineering

En el dilema del prisionero, lo que cada jugador sabe del otro define el resultado. No la capacidad: la información. Dos jugadores idénticos con información distinta producen equilibrios distintos.

En un sistema multi-agente pasa exactamente lo mismo. Lo que cada sub-agente "sabe" — su contexto, las herramientas disponibles, los resultados parciales que ve — determina si colabora o se sabotea.

El caso concreto

Imaginá un pipeline (una cadena de pasos donde la salida de uno alimenta al siguiente) de clasificación NCM con tres sub-agentes:

• Agente A: identifica la posición arancelaria a partir de la descripción del producto.
• Agente B: valida la posición contra la nomenclatura vigente del Mercosur.
• Agente C: consulta tratamientos especiales (TLC, regímenes preferenciales).

Si el Agente C no recibe en su contexto que el Agente B ya validó la posición, va a re-consultar la nomenclatura, va a contradecir, o peor: va a proponer una posición distinta basándose en su propia interpretación. El resultado del sistema deja de ser determinístico.

El problema no es de capacidad del modelo. Es de información compartida.

Es exactamente como un despachante que no leyó el DUA que armó el asistente y declara una posición arancelaria distinta frente al cliente. Los dos son competentes. El sistema falla porque la información no fluye.

Qué hacer

Diseñar el contexto como un activo de primera clase, no como un afterthought:

• Estado compartido explícito (un "blackboard" que cada agente lee y escribe).
• Contratos claros sobre qué entra y qué sale de cada agente.
• Resúmenes estructurados, no transcripciones completas — porque más contexto no es mejor contexto.

Context engineering no es prompt engineering con más palabras. Es decidir qué información tiene cada jugador en cada turno.

2. Juegos Secuenciales vs Simultáneos → Orquestación Serie vs Paralelo

Stackelberg: un jugador mueve primero, los demás observan y reaccionan. Cournot: todos eligen al mismo tiempo, sin ver al otro. Son dos modelos clásicos y producen equilibrios distintos.

Esta distinción mapea directamente a las dos arquitecturas dominantes en sistemas agénticos.

Stackelberg = patrón orchestrator-worker

Un modelo grande (Sonnet, GPT-5, lo que toque) mueve primero: define el plan, descompone el problema, asigna sub-tareas. Los workers (Haiku, modelos chicos especializados) reaccionan ejecutando piezas del plan.

Es lento pero coherente. El líder internaliza el equilibrio del sistema antes de que los seguidores actúen.

Cournot = sub-agentes en paralelo

Tres clasificadores NCM corriendo simultáneamente sobre la misma descripción de mercadería, sin verse entre ellos. Más rápido, más barato si los sub-agentes son chicos. Pero podés terminar con tres posiciones arancelarias distintas y nadie que resuelva el empate.

El equilibrio de Cournot existe solo si hay un agregador que toma los outputs simultáneos y los reconcilia. Sin agregador, no tenés un sistema: tenés tres opiniones.

La pregunta de diseño

No es "¿serie o paralelo?". Es: ¿el problema tolera inconsistencias parciales que después alguien resuelve, o necesita coherencia desde el primer movimiento?

• Clasificación NCM con validación cruzada: paralelo + agregador (Cournot).
• Armado de un DUA completo con dependencias entre campos: serie (Stackelberg).
• Búsqueda de jurisprudencia + cálculo de costos + redacción de informe: híbrido — secuencial entre fases, paralelo dentro de cada fase.

3. Mecanismos de Verdad → Guardrails y Validación Cruzada

En una subasta Vickrey (segundo precio, sobre cerrado), la regla del juego está diseñada para que decir la verdad — pujar exactamente lo que valorás el bien — sea la estrategia dominante. Mentir es sub-óptimo por construcción del mecanismo, no por moralidad del jugador.

Trasladado a agentes: ¿cómo diseñás el prompt y la estructura de tool-calling para que un agente no pueda "alucinar con confianza" sin que otro lo detecte?

El caso del agente de costos

Un agente calcula el costo total de importación de una mercadería. Tiene que devolver: valor CIF, arancel, IVA, IMESI, tasa consular, otros. Si lo dejás solo, puede inventar números que parezcan razonables — un 22% de IVA sobre un CIF inflado, un arancel sacado de una NCM que no validó nadie.

El mecanismo correcto:

1. El agente de costos no calcula el total. Devuelve los componentes con sus fuentes.
2. Un validador determinístico (no un LLM — una función) recibe los componentes y aplica la fórmula: Total = CIF + Arancel + IVA + IMESI + Tasas.
3. Un segundo agente cruza el arancel declarado contra la NCM validada en el paso anterior del pipeline.
4. Si hay inconsistencia, el sistema no entrega la respuesta — vuelve al agente de costos con el error específico.

En este diseño, el agente no puede inventar números útiles. Cualquier alucinación rebota contra el validador. La verdad es la estrategia que minimiza el costo del agente (menos reintentos, menos tokens, menos latencia).

El principio general

Diseñar guardrails no es poner un "verifica tu respuesta" al final del prompt. Es construir el juego para que la salida correcta sea el equilibrio dominante:

• Separar generación de validación. El que produce no valida.
• Validadores determinísticos cuando se puede. Una fórmula CIF + Arancel + IVA es más confiable que un LLM revisándose a sí mismo.
• Cross-checks entre agentes con visiones distintas del mismo problema. Si dos agentes con prompts independientes llegan al mismo número, la confianza sube; si no, el sistema lo sabe.

El Gancho Práctico: Cuatro Preguntas Antes de Escribir Código

Cuando estés diseñando tu próximo loop agentico — antes de elegir framework, antes de escribir el primer prompt — preguntate cuatro cosas que vienen directo de teoría de juegos:

1. ¿Quién mueve primero? ¿Hay un líder que define el plan y seguidores que reaccionan, o todos eligen en simultáneo?
2. ¿Qué ve cada uno? ¿Qué información tiene cada agente en su contexto, y qué información — crítica — no le estoy pasando?
3. ¿Qué pasa si un agente se desvía? ¿Hay un mecanismo que detecte el error, o el sistema lo propaga sin saberlo?
4. ¿El equilibrio del sistema es el resultado que quiero? Si cada agente juega óptimamente según sus incentivos, ¿el output agregado es correcto?

Si no podés responder estas cuatro, no tenés una arquitectura — tenés un pipeline con suerte. Y la suerte se acaba el día que el sistema entra en producción y empieza a procesar casos que nunca viste en los tests.

Por Qué Importa el Frame Analítico

El 90% del contenido sobre agentes te dice cómo: cómo usar tool-calling, cómo armar un grafo de LangGraph, cómo orquestar con un router. Lo que falta es el por qué: por qué este patrón y no otro, por qué este flujo de información, por qué este nivel de redundancia.

Teoría de juegos no es una metáfora académica. Es el lenguaje correcto para pensar sistemas donde múltiples agentes — humanos, modelos, funciones — toman decisiones bajo información parcial e incentivos no alineados. Que es, exactamente, lo que es un sistema multi-agente.

El despachante que coordina con el cliente, el agente de aduanas y el transportista resuelve estos problemas todos los días: información asimétrica, secuencias de decisión, mecanismos para evitar errores costosos. La arquitectura agéntica es el mismo problema con jugadores distintos.

Diseñá el juego primero. El código viene después.