Paralelismo determinista, verificación adversarial y los límites empíricos de la coordinación entre agentes de lenguaje
Resumen. Los sistemas basados en un único agente conversacional degradan su fiabilidad a medida que crece la tarea, por una combinación de saturación de contexto y sesgo posicional bien documentada en la literatura. Este artículo describe Graph Engineering, un patrón arquitectónico que estructura el trabajo de agentes de lenguaje como un Grafo Acíclico Dirigido (DAG), y examina con el mayor rigor posible la evidencia empírica detrás de sus componentes: el límite matemático que impone la Ley de Amdahl al paralelismo, el umbral de rentabilidad de la coordinación multi-agente hallado por Google DeepMind, la magnitud medida del sesgo de autopreferencia en la verificación, y tres patrones de producción —aislamiento de entorno, generación de salidas estructuradas y revisión de seguridad en paralelo— contrastados contra sus fuentes primarias.
1. Introducción: por qué el chat lineal tiene un techo
La arquitectura tradicional de agentes basada en secuencias lineales —una conversación de ida y vuelta, o un pipeline rígido de pasos fijos— sufre de un problema estructural conocido como lost in the middle: la información ubicada en el centro de un contexto largo pierde peso relativo frente a la que está al principio o al final. El fenómeno fue documentado por Liu et al. en un estudio controlado sobre respuesta a preguntas multi-documento y recuperación de pares clave-valor, donde el desempeño de los modelos formaba una curva característica en U —alto en los extremos del contexto, bajo en el medio— y esa degradación persistía incluso en modelos diseñados específicamente para contextos largos (Liu et al., 2023, publicado en Transactions of the Association for Computational Linguistics, 2024). El hallazgo no depende de un modelo particular: es una propiedad emergente de cómo los transformers atienden a secuencias largas, y trabajos posteriores confirmaron el mismo patrón en tareas de razonamiento multi-hop y en ventanas de hasta 128.000 tokens.
La consecuencia práctica es que, cuanto más crece el historial de una conversación —más herramientas invocadas, más resultados intermedios acumulados, más correcciones sobre la marcha—, más aumenta la probabilidad de que el modelo pierda una directiva temprana o confunda el estado de dos subtareas que en realidad eran independientes. Graph Engineering responde a este problema no optimizando el prompt, sino cambiando la unidad de ejecución: en lugar de una ventana de contexto que acumula todo el historial de un proyecto, estructura el trabajo como un Grafo Acíclico Dirigido (DAG), donde cada nodo es una unidad de cómputo aislada —ejecutada por un agente o por una función determinista— y cada arista gestiona un flujo de estado, control o transición condicional entre nodos.
2. Componentes arquitectónicos
Un grafo de agentes en producción se compone de cuatro elementos. Los nodos son unidades atómicas de trabajo, con prompts especializados, un conjunto acotado de herramientas y una única responsabilidad bien definida —cuanto más se resiste la tentación de darle a un nodo dos responsabilidades a la vez, más predecible se vuelve el sistema completo—. Las aristas son mecanismos de enrutamiento determinista que conectan la salida de un nodo con la entrada del siguiente, evaluando condiciones de parada o desvío; no son un simple "después de esto, lo otro", sino la codificación explícita de una dependencia real de datos. El patrón fan-out/fan-in describe la distribución de subtareas independientes a múltiples nodos paralelos, seguida por un nodo sintetizador que consolida los resultados una vez que todos terminan. Y el aislamiento de entorno resuelve un problema que se vuelve crítico apenas dos agentes tocan el mismo código o el mismo estado a la vez: cómo evitar que se pisen entre sí.
3. Aislamiento de entorno con git worktrees
Cuando varios agentes modifican una base de código en paralelo, compartir un único directorio de trabajo produce colisiones: dos agentes editando el mismo archivo se sobrescriben, y un git stash de uno interrumpe la sesión del otro. La técnica de aislamiento que resuelve esto no es una invención ad hoc del ecosistema de agentes, sino una funcionalidad nativa de Git —el worktree— que permite tener varias ramas de un mismo repositorio, cada una en su propio directorio físico en disco, compartiendo solo el historial de Git. Anthropic documenta soporte nativo para esto en Claude Code: cada sesión —o cada subagente lanzado con aislamiento explícito— puede recibir su propio worktree, de forma que dos agentes trabajen en paralelo sobre ramas distintas sin interferir en los archivos vivos del otro (Claude Code Docs — Run parallel sessions with worktrees). Vale la pena remarcar el límite de esta técnica: el aislamiento de archivos en disco no elimina los conflictos lógicos. Si dos agentes parten de supuestos incompatibles sobre cómo debe comportarse el sistema, el resultado fusionado puede seguir fallando aunque ningún archivo se haya sobrescrito; el worktree resuelve la colisión mecánica, no el desacuerdo semántico entre agentes.
4. Límites matemáticos: la Ley de Amdahl aplicada a equipos de agentes
El rendimiento de un sistema multi-agente paralelizado está estrictamente acotado por la Ley de Amdahl, formulada originalmente para el paralelismo en hardware y trasladable casi sin fricción al paralelismo entre agentes, porque el cuello de botella es estructuralmente el mismo:
$$S = \frac{1}{(1-p) + \dfrac{p}{N}}$$
Donde S es la aceleración obtenida, p la proporción de trabajo paralelizable y N el número de agentes desplegados. Con p = 0,95 —un escenario optimista, con el 95% del trabajo verdaderamente independiente— desplegar 16 agentes no multiplica la velocidad por 16, sino por 9,14. El sistema completo nunca puede ir más rápido que su camino crítico: la cadena más larga de pasos que dependen secuencialmente unos de otros, que ningún agente adicional puede acortar. Agregar agentes paralelos genera retornos decrecientes, e incluso negativos, cuando el costo de comunicación y sintetización entre ellos supera la aceleración teórica que el paralelismo debería aportar.
5. El umbral empírico de rentabilidad: la regla del 45%
La pregunta de cuándo vale la pena coordinar un equipo de agentes en lugar de usar uno solo dejó de ser una cuestión de intuición de ingeniería con el estudio de Google DeepMind "Towards a Science of Scaling Agent Systems" (Kim et al., 2025), que evaluó 180 configuraciones de coordinación cruzando cuatro benchmarks de naturaleza muy distinta —razonamiento financiero, navegación web, planificación en Minecraft y selección de herramientas para tareas de negocio—. El hallazgo central, y el más robusto entre las variables estudiadas, es que el desempeño de un equipo depende menos de la topología elegida que de un solo número: qué tan bien resuelve la tarea un agente único, sin ayuda, antes de sumarle compañía.
Cuando ese agente único ya resuelve más del 45% del problema con un prompt directo, coordinar un equipo produce retornos negativos: el costo en tokens sube sin que el resultado mejore, y en algunos casos empeora. Por debajo de ese umbral —el caso típico de auditorías de código extensas o investigaciones que requieren cubrir mucho terreno— la arquitectura multi-agente puede superar al agente único por márgenes considerables: en las tareas de razonamiento financiero del estudio, una topología centralizada llegó a superarlo en un 80,8%. Pero el mismo estudio es explícito en que ese beneficio no es parejo: en tareas de planificación estrictamente secuencial, donde cada paso depende del anterior sin margen real para paralelizar, ningún esquema multi-agente logró superar al agente único —todos degradaron el resultado, porque el costo de coordinación consumió presupuesto sin comprar ningún paralelismo real—. Esta es, en rigor, la aplicación empírica de la Ley de Amdahl de la sección anterior: cuando p es bajo porque la tarea es intrínsecamente secuencial, ningún N la salva.
6. Verificación adversarial y el sesgo de autopreferencia
Un principio no negociable del diseño de grafos de agentes es que ningún nodo verifique su propia salida. La razón tiene nombre y medición en la literatura: el sesgo de autopreferencia (self-preference bias, también llamado self-enhancement bias), documentado por primera vez de forma sistemática por Zheng et al. en el paper que introdujo el paradigma de "LLM como juez" (Zheng et al., 2023, NeurIPS 2023). En su experimento, comparando el win rate que cada modelo le asignaba a sus propias respuestas frente al de jueces humanos, GPT-4 favoreció sus propias respuestas con una tasa de victoria un 10% más alta que la de los humanos, y Claude-v1 lo hizo con una diferencia del 25%. Trabajo posterior de Panickssery, Bowman y Feng estableció además que esta preferencia está correlacionada con la capacidad del modelo de reconocer su propio texto: cuanto mejor distingue un modelo su propia generación de la de otros, más fuerte es el sesgo hacia ella (Panickssery et al., 2024, NeurIPS 2024). Estudios más recientes matizan el cuadro —parte de esa autopreferencia refleja calidad genuinamente superior, no solo sesgo—, pero incluso aislando los casos donde el modelo evaluador se equivoca como generador, el sesgo hacia la propia salida persiste y es más pronunciado en los modelos más capaces (Do LLM Evaluators Prefer Themselves for a Reason?, 2025).
La arquitectura de un nodo de verificación adversarial —un agente distinto, con criterios de evaluación opuestos a los del generador, sin memoria del proceso que produjo la salida que está evaluando— es la respuesta directa a este hallazgo: rompe la correlación entre generación y evaluación que produce el sesgo. Cuando ese nodo detecta que un entregable no cumple con pruebas unitarias o especificaciones de formato, la arista de verificación redirige el flujo de vuelta al nodo generador junto con el feedback del error, en lugar de dejar pasar una salida que el propio generador, dejado a su criterio, hubiese aprobado.
7. Consistencia de formato: decodificación restringida y su costo oculto
La afirmación de que un esquema estructurado —JSON Schema, o su encapsulamiento en modelos Pydantic— produce salidas más consistentes que una respuesta libre tiene respaldo técnico concreto, y también una salvedad que rara vez se menciona. La técnica que garantiza esa consistencia es la decodificación restringida por gramática (grammar-constrained decoding): en cada paso de generación, un motor de restricciones —Outlines, XGrammar, o el soporte nativo de las APIs comerciales— compila el esquema en un autómata finito que enmascara los tokens inválidos, forzando a que la salida cumpla la estructura por construcción y no por validación posterior. Benchmarks de proveedores comerciales muestran diferencias grandes: OpenAI reporta que sus modelos alcanzan cerca del 100% de cumplimiento en esquemas JSON complejos con Structured Outputs activado, frente a menos del 40% del mismo modelo guiado solo por instrucciones en el prompt. El benchmark académico JSONSchemaBench, que evalúa distintos motores de restricción sobre miles de esquemas reales, confirma que la decodificación restringida sigue siendo un área activa de investigación con brechas de cobertura entre frameworks (Geng et al., 2025).
La salvedad es la siguiente: forzar una gramática puede degradar la calidad del razonamiento que precede a la respuesta. Un estudio presentado en EMNLP 2024 encontró que las restricciones de formato estricto pueden reducir la precisión en benchmarks matemáticos hasta en 27 puntos porcentuales, porque el formato JSON a veces obliga al modelo a emitir el campo de respuesta antes de completar su cadena de razonamiento, cortando el pensamiento intermedio que necesitaba para llegar bien al resultado. La lección de diseño es que la decodificación restringida conviene aplicarse después de que el nodo generador haya razonado libremente, no como una camisa de fuerza desde el primer token —un patrón que algunos frameworks híbridos ya implementan explícitamente, dejando razonar sin restricción y activando la gramática solo en la fase final de formateo—.
8. Patrones de producción verificados
8.1 Security Sweep: revisión de seguridad en paralelo
El patrón de lanzar evaluadores de vulnerabilidades en paralelo antes de fusionar código no es solo plausible en teoría: hay evidencia cuantitativa reciente de su efectividad cuando se combina con herramientas de análisis estático tradicionales (SAST). El sistema QASecClaw combina un motor SAST convencional (Semgrep) con agentes LLM especializados —un agente de validación de seguridad, un agente de correlación de evidencia y un agente filtro que revisa cada hallazgo con el contexto del código fuente para distinguir verdaderos positivos de falsos positivos—, todo coordinado por un orquestador central. Evaluado sobre el benchmark completo OWASP Benchmark v1.2 (2.740 casos de prueba en Java, 11 categorías CWE), el sistema alcanzó un F1-score de 90,93%, frente al 78,39% de Semgrep solo, impulsado principalmente por una reducción del 88,6% en falsos positivos —de 560 a 64— con una caída de apenas 3,1% en el recall (Ameen et al., 2026). El hallazgo relevante para el diseño de un grafo no es solo que el patrón funciona, sino por qué: el cuello de botella de las herramientas SAST tradicionales no es la detección —eso ya lo resuelven bien— sino el ruido de falsos positivos que erosiona la confianza del equipo humano; un nodo de agente que aporta contexto semántico al hallazgo mecánico es lo que mueve la aguja.
8.2 Cited Research: verificación de citas antes de la síntesis
El riesgo que motiva este patrón está bien cuantificado: una auditoría cruzada de fabricación de referencias en diez modelos comerciales, sobre casi 70.000 instancias de citas verificadas contra fuentes primarias, encontró que la alucinación de citas es un fenómeno inducido por el pedido explícito de citar —ningún modelo generó citas fabricadas de forma espontánea sin que se le pidiera— pero que, una vez pedida, la tasa de fabricación es sustancial y varía fuertemente según el dominio académico y el modelo (How LLMs Cite and Why It Matters, 2026). La respuesta arquitectónica que propone la literatura reciente no es pedirle al mismo agente que revise sus propias citas —eso reproduce el sesgo de autopreferencia de la sección 6—, sino separar los roles: un framework como MARCH divide el trabajo entre un agente que resuelve la tarea con recuperación aumentada, un segundo agente que descompone esa respuesta en afirmaciones atómicas verificables, y un tercer agente que responde esas preguntas de verificación sin acceso a la respuesta original, evitando así el atajo cognitivo de "confirmar lo que ya se escribió" en lugar de contrastarlo genuinamente contra la evidencia (MARCH, 2026). Trasladado a un grafo de producción, esto es exactamente un patrón fan-out con verificación ciega: un nodo investigador en abanico, y un nodo verificador de citas que nunca ve el razonamiento que las generó, solo la afirmación y la fuente.
8.3 Module Porting: migración de código en ramas aisladas
Este patrón combina directamente los dos anteriores —descomposición en DAG y aislamiento con worktrees— aplicados a la migración de una base de código entre frameworks o lenguajes. La evidencia de que esto funciona a escala real, y no solo en el papel, viene de un caso documentado por la industria: el equipo de Cursor describió públicamente haber coordinado grandes cantidades de agentes en tareas de semanas de duración, incluyendo la migración completa de una base de código de un framework a otro y la generación desde cero de un navegador web (Cursor, 2026). Su conclusión práctica coincide con la teoría de este artículo: un esquema jerárquico de planificador y ejecutores rindió mejor que un enjambre plano de agentes sin coordinación central, porque el planificador permite delegación controlada y trazabilidad de quién hizo qué —la misma lógica que llevó a Fred Brooks a escribir en 1975 que agregar gente a un proyecto atrasado sin estructura organizativa no lo acelera, solo agrega reuniones—.
9. El costo real de coordinar un equipo
Un aspecto que casi nunca se discute con el mismo rigor que el rendimiento es el costo en tokens de la coordinación misma. El costo total de un sistema multi-agente no crece solo con la cantidad de agentes desplegados, sino con la cantidad de rondas de coordinación —reasignaciones del orquestador, rondas de debate, mensajes cruzados entre pares— multiplicada por el volumen de esos mensajes. En esquemas descentralizados o híbridos, donde los agentes conversan libremente entre sí, ese costo de coordinación puede empezar a comportarse de forma cercana a cuadrática respecto de la cantidad de agentes, porque cada uno tiene que leer lo que dijeron todos los demás antes de poder actuar. La conclusión de diseño, consistente con la sección 5, es que escalar agentes solo vale la pena cuando la tarea gana más en paralelismo real de lo que pierde en overhead de coordinación.
10. Discusión y límites de este marco
Vale la pena ser explícito sobre lo que este artículo no afirma. La regla del 45% y los factores de amplificación de errores provienen de un único estudio, exhaustivo pero no el único en su campo, y sus autores mismos señalan que los resultados son sensibles al benchmark: lo que vale para razonamiento financiero decomponible no vale igual para planificación secuencial estricta. La técnica de worktrees resuelve colisiones de archivos, no desacuerdos semánticos entre agentes. Y la decodificación restringida, aunque mejora la consistencia de formato de forma medible, tiene un costo de razonamiento que la convierte en una herramienta para aplicar con criterio, no un default universal. El hilo común de las nueve secciones anteriores no es que "más estructura siempre gana", sino que cada pieza del patrón —el aislamiento, la verificación separada del generador, la restricción de formato aplicada en el momento correcto— responde a un modo de fallo específico y medido, no a una intuición de diseño sin respaldo.
11. Conclusión
El paso clave para escalar el uso de modelos de lenguaje no radica en afinar prompts más largos, sino en diseñar la red adecuada de dependencias: dividir el trabajo que es genuinamente independiente, aislar las ejecuciones que podrían colisionar, y validar cada entrega con un verificador que no comparte el sesgo del agente que la produjo. La pregunta que separa a un sistema que rinde de uno que solo quema presupuesto no es cuántos agentes se despliegan, sino si la tarea admite, en los hechos y no solo en la intención, ser partida sin perder la cadena de razonamiento que la sostiene.
Referencias
- Liu, N. F., et al. (2023/2024). Lost in the Middle: How Language Models Use Long Contexts. TACL. arXiv:2307.03172
- Kim, Y., et al. (2025). Towards a Science of Scaling Agent Systems. Google DeepMind. arXiv:2512.08296
- Zheng, L., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS. arXiv:2306.05685
- Panickssery, A., Bowman, S. R., & Feng, S. (202