El mapa del territorio
3 módulos. Una misma conversación.
Cada módulo es autosuficiente. Puedes usarlos juntos o por separado según la audiencia.
El mapa mental completo: 10 patrones en escalera ascendente de complejidad. Cada patrón existe porque el anterior tiene un límite.
6 dolores reales → 6 patrones que los resuelven. No "qué es cada patrón" sino "cuándo te salva la vida cada uno".
Anthropic, OpenAI, Factory y la academia llegaron independientemente a las mismas 4 conclusiones. Cuando 4 fuentes convergen, ya no es tendencia.
Slides 3–22 ↓
La escalera de complejidad
Cada patrón existe porque el anterior tiene un límite. No son opciones paralelas — son niveles de una escalera. Subir no siempre es mejor; subir cuando lo necesitas es obligatorio.
La pregunta correcta
No "¿qué patrón uso?" sino "¿cuál es el límite del que tengo ahora y cuándo lo voy a golpear?"
10 niveles, 4 capas
Desde un único agente con ReAct hasta un orquestador entrenado con RL. Cada capa añade coordinación, y coordinación tiene coste.
El error más común
Saltarse niveles por "ambición arquitectónica". Un Orchestrator-Workers para un problema de Routing es deuda técnica disfrazada de sofisticación.
El agente aprende a trabajar con otros
Un LLM en bucle Thought → Action → Observation. La unidad mínima de agente. Razona sobre su propia acción antes de ejecutarla.
El agente genera una crítica verbal de su propio intento antes del siguiente. Sin cambiar los pesos — solo razonando sobre qué falló.
Secuencia fija de agentes especializados: A → B → C. Topología definida antes de la ejecución. El output de cada etapa es el input de la siguiente.
Un clasificador inicial decide a qué agente especializado dirigir el input. Sin coordinador dinámico — la decisión es puntual y unidireccional.
La coordinación se hace explícita
Orchestrator-Workers
Un LLM central descompone la tarea, delega a workers especializados y sintetiza los resultados. La topología emerge en runtime según el input.
Creator-Verifier
Dos agentes con roles opuestos: uno genera, otro evalúa en contexto separado. El evaluador no tiene acceso al razonamiento del generador — solo al output.
Hierarchical + Broadcast
Árbol de agentes: un root-orchestrator coordina sub-orquestadores que a su vez coordinan workers. Broadcast permite notificar a múltiples ramas en paralelo.
El Creator-Verifier es el patrón más subvalorado: añadir un evaluador independiente es la intervención con mejor ROI en calidad del output de cualquier sistema agéntico.
Cuando los agentes se auto-organizan
Swarm / Mesh
Swarm: topología emergente en runtime. Los agentes se conectan dinámicamente según la tarea, como hormigas que construyen rutas sin coordinador central. Alta flexibilidad, baja predecibilidad.
Mesh: conexiones peer-to-peer fijas en design time. Cada agente conoce a sus vecinos. Más predecible que Swarm, pero con overhead de todos hablar con todos.
Missions (composición de 4 patrones)
El patrón de Factory para tareas de software de semanas de duración. Combina: Orchestrator-Workers (3 roles) + Creator-Verifier (Validation Contracts) + ejecución serial (sin merge conflicts) + Handoffs estructurados (5 campos). Dato de producción: Slack clone en 16.5h, 778M tokens, 89% test coverage.
Puppeteer / RL Orchestration
Un orquestador entrenado con Reinforcement Learning que aprende qué secuencia de delegaciones produce mejores resultados. Las 5 sub-decisiones que aprende: cuándo spawnear, a quién delegar, cómo comunicar, cómo agregar, cuándo parar.
El mapa completo
Regla de oro: usa la capa más baja que resuelve tu problema. Cada capa añade overhead de coordinación que no se recupera si no lo necesitas.
Cada patrón nació de un dolor real
En lugar de preguntar "¿qué es este patrón?", pregunta "¿cuándo te salva la vida?". El pain es el punto de entrada más honesto a la arquitectura.
Los próximos 6 slides cubren cada problema con el patrón que lo resuelve y por qué funciona.
El agente no detecta sus propios errores
El dolor
Un agente que genera código, lo prueba con tests que él mismo escribió y lo declara correcto está cerrando el bucle sobre sí mismo. Confirmation bias a escala de máquina: el evaluador tiene el mismo punto ciego que el generador.
Agente A: genera función + tests
Agente A: ejecuta tests → ✅ pass
Producción: 💥 falla en edge case no contemplado
El patrón: Creator-Verifier
Por qué funciona: el evaluador no tiene acceso al razonamiento del generador. Sus puntos ciegos son diferentes. La intersección de los dos errores es mucho menor que el error individual.
El contexto se degrada en tareas largas
El dolor
Un agente que trabaja días en la misma sesión acumula ruido en su context window. Los resultados parciales de hace 50 pasos compiten con las instrucciones actuales. La calidad del razonamiento cae de forma no lineal a medida que el contexto crece.
Calidad de razonamiento estimada (degradación acumulativa)
El patrón: Context Isolation + Structured Handoffs
Los 5 campos del handoff (Factory)
objetivo_completadoestado_actual_sistemadecisiones_tecnicas_tomadasproximos_pasoscontexto_criticoEl handoff no es un resumen informal — es un contrato. El worker siguiente puede arrancar desde 0 con solo esos 5 campos. La misión puede durar semanas.
Los agentes en paralelo se pisan los cambios
El dolor
Correr 10 agentes en paralelo escribiendo código parece la solución obvia para acelerar. El resultado real: merge conflicts, estados inconsistentes, linter que pasa en aislamiento pero falla en integración.
Factory midió esto: el overhead de coordinación de agentes paralelos sobre el mismo codebase supera el beneficio de velocidad en la mayoría de tareas de software.
El patrón: Serial con paralelismo interno read-only
Orchestrator planifica
descompone en tareas seriales sin solapamiento
Worker 1 implementa módulo A
acceso exclusivo de escritura · paralelismo solo en lectura
Validator verifica
tests · lint · code review (pueden correr en paralelo)
Worker 2 implementa módulo B
parte del estado validado del worker 1
El paralelismo es seguro cuando los agentes solo leen. Los validadores (tests, lint, reviews) pueden correr en paralelo porque no modifican el estado.
Los tests escritos por el mismo agente no atrapan bugs reales
El dolor
Si el mismo agente que implementa también escribe los tests, ambos parten del mismo malentendido. El agente no tiene un spec externo — tiene su propia interpretación de lo que debería hacer el código. Los tests validan esa interpretación, no el comportamiento correcto.
El patrón: Validation Contract
Validation Contract
✓ Criterios de aceptación funcional
✓ Casos edge obligatorios
✓ Performance thresholds
✓ Constraints de seguridad
Scrutiny Validator (pipeline)
→ Tests contra el contrato
→ Linter + type-check
→ Code review agente independiente
El contrato lo escribe el Orchestrator, que tiene la visión de la tarea completa. El Worker no puede alterar los criterios de aceptación.
El sistema queda obsoleto con cada nuevo modelo
El dolor
Si tu lógica de orquestación está hardcodeada en una state machine — "si output contiene X, haz Y, sino Z" — tienes que reescribirla cada vez que cambias de modelo. El modelo mejora sus capacidades y tu código no sabe aprovecharlo.
Orquestación frágil (state machine)
if (output.includes('error')) {
retryStrategy = 'exponential';
} else if (confidence < 0.7) {
escalate('human'); // hardcoded threshold
} Cuando GPT-5 / Claude 5 salgan, estos thresholds son basura.
El patrón: lógica en prompts (Factor 8)
Orquestación anti-frágil (lógica en texto)
"Si detectas que la implementación tiene baja cobertura de edge cases, genera tests adicionales antes de marcar la tarea como completa. Si encuentras un error de compilación, intenta corregirlo hasta 3 veces antes de escalar al orchestrator."
Un modelo mejor entiende mejor estas instrucciones. No hay código que actualizar.
Las Missions de Factory: ~700 líneas de texto
La lógica del orquestador está en prompts, no en código. Cada release de modelo la mejora gratis.
12-factor agents, Factor 8
"Codifica la lógica de negocio en prompts, no en state machines. El modelo es el intérprete."
Supervisar a los agentes sin microgestionar
El dolor
El pendulo oscila entre dos extremos igual de malos: aprobar cada acción (el agente pierde todo su valor) o no supervisar nada (el agente causa daños antes de que alguien los vea).
La solución no es un punto fijo en el espectro — es supervisión dinámica orientada a riesgo.
El patrón: HITL/HOTL + Mission Control
tests, lint, formatting, operaciones de lectura
commits, PRs, mensajes a usuarios, deploys a staging
producción, datos sensibles, acciones irreversibles
Marco de decisión rápida
EU AI Act, Art. 14: supervisión humana obligatoria para sistemas IA de alto riesgo.
4 fuentes independientes. Las mismas conclusiones.
Cuando una empresa hace una afirmación sobre IA, es una opinión. Cuando 4 fuentes que no se coordinaron llegan a lo mismo, empieza a ser una ley del campo.
Generator-Evaluator · 12-factor agents · Sprint Contracts
Harness Engineering · PNPM 750 packages · Persona-based reviewers
Orchestrator-Workers-Validators · Validation Contracts · 16.5h Slack clone
NLAH +16.8pts · Meta-Harness 6× variance · GRPO multi-agent
Las 4 convergencias que emergen:
Harness > Modelo
La arquitectura que envuelve al LLM determina más el rendimiento que el modelo en sí.
Solo cambiando la representación del harness (código → lenguaje natural). Mismo modelo, misma tarea.
La arquitectura del harness explica 6 veces más la variación en rendimiento que la elección del modelo.
Slack clone completo. 778M tokens, 89% test coverage. El harness define el patrón de éxito.
Si el agente necesita clarificación humana, el harness no dio suficiente contexto. El problema es siempre la estructura.
Implicación práctica: la decisión de qué modelo usar es secundaria a la decisión de cómo estructurar el harness. Invierte más tiempo en la arquitectura que en el benchmark.
Separar generación y evaluación
Tres empresas con tres nombres distintos para el mismo principio — señal de convergencia real.
El evaluador opera en contexto separado. No ve el razonamiento del generador — solo su output. Sesgo independiente es el objetivo.
Agentes reviewer con personalidades distintas (el escéptico, el optimizador de rendimiento, el de seguridad). Diferentes ángulos de ataque.
Dos tipos de validación: el Validator evalúa contra el Validation Contract; el Scrutiny Validator ejecuta el pipeline (tests → lint → type-check → review).
Por qué funciona: los LLMs tienen confirmation bias. Un modelo que genera también tiene el sesgo de "esto parece correcto porque yo lo generé". El evaluador independiente rompe ese ciclo.
Lógica en prompts, no en estado
Un sistema frágil requiere reescritura con cada nuevo modelo. Un sistema anti-frágil mejora solo.
Sistema frágil
// Orchestrator hardcodeado
if (confidence < 0.75) {
retry(3);
} else if (error_type == 'auth') {
escalate('human');
}
❌ Claude 5 sube baseline → thresholds son incorrectos
❌ Nueva categoría de error → reescribir código
❌ Cada release de modelo requiere QA completo
Sistema anti-frágil
"Si el resultado no cumple los criterios del Validation Contract, genera una descripción específica de por qué falló y reintenta con ese contexto. Si tras 3 intentos no converge, escala al orchestrator con un análisis de la causa raíz."
✓ Claude 5 entiende mejor estas instrucciones → mejora gratis
✓ Nueva situación → el modelo la maneja con razonamiento
✓ Sin código que actualizar con cada release
Estado externalizado y estructurado
Si el estado vive solo en el context window, el agente no puede trabajar más de unas horas. Si vive fuera, puede trabajar semanas.
5 campos JSON en el handoff. El estado del sistema en un formato que cualquier worker puede consumir sin el contexto histórico.
El estado de la misión se persiste en archivos. Si el agente se reinicia, recupera exactamente donde estaba. Sin perder progreso.
Los agentes leen y escriben en progress/ como memoria externalizada. El contexto window del agente es efímero; el estado no.
El historial de git es el estado externalizado. El agente puede "recordar" decisiones pasadas leyendo commits, sin que ese contexto esté en su ventana.
El principio
El context window es RAM — efímero y limitado. El estado externalizado es disco — persistente y sin límite de tamaño. Los sistemas agénticos de larga duración usan el context window como buffer de trabajo, no como almacén de estado.
La misma conclusión, 4 veces
Cuando Anthropic, OpenAI, Factory y la academia llegan independientemente a las mismas 4 conclusiones, dejan de ser recomendaciones y se convierten en restricciones del dominio. No seguirlas no es heterodoxia — es ignorancia.
Lo que se lleva el que estuvo en la sala
La escalera no se puede saltarse
Cada nivel de complejidad existe porque el anterior tiene un límite real. Saltar niveles por ambición arquitectónica produce deuda técnica disfrazada de sofisticación.
El evaluador independiente es tu mejor inversión
Un agente que valida su propio trabajo tiene confirmation bias. Añadir un evaluador en contexto separado es la intervención con mejor ROI en calidad del sistema.
Lógica en texto, estado fuera del contexto
La lógica de orquestación en prompts mejora con cada nuevo modelo sin tocar código. El estado en disco permite misiones de semanas. Estos dos principios juntos definen la anti-fragilidad.
Anthropic, OpenAI, Factory y academia dicen lo mismo
Las 4 convergencias no son tendencias — son restricciones emergentes del campo. El harness explica más varianza que el modelo. Invertir en arquitectura antes que en benchmarks.
Estos no son patrones de moda. Son respuestas ingenieriles a problemas concretos que aparecen siempre que un agente trabaja en tareas no triviales. El contexto cambia; el problema no.
Dato de producción · Factory · 2025
Sin los patrones de orquestación, este resultado no existe. La arquitectura no es accesoria — es el producto.
No es el modelo
que eliges.
Es cómo lo
envuelves.
▶ Vídeos
◎ Papers & Docs
- Anthropic Building Effective Agents — Erik S. & Barry Zhang (5 patrones canónicos)
- Paper Natural-Language Agent Harnesses — Tsinghua 2026 (+16.8 pts arXiv:2603.25723)
- Paper Meta-Harness — Stanford/MIT 2026 (Haiku #1 TerminalBench arXiv:2603.28052)
- Referencia LLM Powered Autonomous Agents — Lilian Weng (OpenAI, el post fundacional)
