Agentic patterns
Catálogo de arquitecturas reutilizables para sistemas con agentes IA. Análogo a los design patterns de GoF, pero para el problema “cómo organizar agentes + herramientas + memoria + loops de decisión”. El nombre canónico viene del episodio “9 Agentic Patterns, Simply Explained” de system-design-one (2026-05-03).
La regla de un solo agente (System Design One 2026-04-30)
Antes de elegir un patrón multi-agente, validar:
Un agente = un contexto, un set de herramientas, un loop. Cuando la tarea supera cualquiera de los tres, necesitas más de uno.
El error más común documentado: sobre-segmentar prematuramente — crear 5 agentes especializados cuando la carga real cabe en uno solo. Análogo al antipatrón microservicios prematuros en arquitectura-software (“equipo < 10: monolito”).
Los 9 patrones (catálogo Neo Kim 2026-05-03)
El episodio cubre desde ReAct (Reasoning + Acting iterativo, baseline) hasta multi-agente con memoria persistente. Cada patrón tiene un punto de quiebre específico:
| Eje de quiebre | Implicación |
|---|---|
| Complejidad | Patrones simples (ReAct, Plan-and-Execute) hasta complejos (Hierarchical, Swarm) |
| Costo | Más agentes → más tokens → más latencia y $ |
| Latencia | Patrones secuenciales VS paralelos cambian wall-clock 10x |
“La elección del patrón determina el comportamiento bajo incertidumbre.”
Conecta directamente con el frame de Beck “Genie Lessons: Nobody Wants Agents” (2026-05-02): si la tarea es determinística, el patrón correcto es workflow, no agente. Si el sistema siempre debería hacer los mismos pasos en el mismo orden, mantenlo determinístico (Emerging AI 2026-04-11 “AI Agents Playbook April 2026”).
Sub-agents vs Agent teams (Emerging AI 2026-05-04)
“Stop Making One Agent Do Everything”
| Patrón | Cuándo | Killer silencioso |
|---|---|---|
| Sub-agents | Tareas secuenciales con contexto compartido | Context drift en sesiones largas |
| Agent teams | Tareas paralelas e independientes | Coordination overhead |
El context drift es el killer del patrón sub-agents — el contexto inicial se diluye conforme avanzan los pasos, hasta que el último sub-agente toma decisiones basadas en una versión degradada del estado real.
Arquitectura base de 4 agentes (Emerging AI 2026-05-15)
Collector → Builder → Checker → Sender
Patrón de referencia para builders. Cuatro agentes, no diez. Cada uno con job card clara, herramientas mínimas, handoff packet estructurado (ver agent-memory), logs visibles.
“El poder está en el handoff, no en el número de agentes.”
Agent harness — la infraestructura olvidada (Emerging AI 2026-04-30)
“The Anatomy of an Agent Harness”
El “harness” = entorno de ejecución alrededor del agente:
- Memoria persistente.
- Verificación de resultados.
- Sandbox de ejecución.
- Logs y observabilidad.
Los fallos actuales de agentes se deben más a la falta de infraestructura que al modelo subyacente. Conexión directa con el frame de mcp-protocol como infraestructura (Pinterest 2026-05-12) y con AI Sandboxes (Engineer’s Codex 2026-04-29).
Cuándo NO usar agentes (regla de oro, abril 2026)
Del playbook “The New Way of Building AI Agents” (Emerging AI 2026-04-11):
Si los pasos son fijos, usa un workflow. Agentes = donde hay que decidir qué hacer basándose en lo que se descubre.
Otros criterios negativos:
- Si no podés explicar el trabajo claramente, el agente no lo hará claramente tampoco.
- Si la tarea no es frecuente, el ROI de construir + mantener el agente no cierra.
- Si el costo de un error es alto y no hay checker humano, posponer.
La voz contrarian — Kent Beck (2026-05-02)
“Nobody wants agents.”
kent-beck critica el framing “agente” — los usuarios quieren resultados, no agentes. La abstracción “agente” es del builder, no del usuario. Propone framing “Genie” (genio que cumple deseos) como más honesto.
Resolución del wiki: no son frames opuestos sino dimensiones distintas. Agentic patterns es vocabulario interno del equipo técnico. “Nobody wants agents” es regla de marketing externo: vender outcome, no abstracción.
Curva cuantitativa — Jared Kaplan (Anthropic, mayo 2026)
yc-ai-construccion-y-agentes-agregada captura el dato más operacionalmente útil sobre el horizonte de los agentes:
El time horizon de tasks que la IA puede completar exitosamente se duplica aproximadamente cada 7 meses.
Implicaciones operativas:
- Si hoy un agente maneja tareas de horas, en 7 meses manejará tareas de un día; en 14 meses, semanas; en ~2 años, meses; en 3-4 años, años.
- Lo que NO escala con esta curva son los otros bottlenecks que Kaplan menciona: organizational knowledge (operar dentro de una empresa como empleado experimentado), long-term memory y oversight nuance para outputs creativos fuzzy.
- Para builders: el patrón correcto hoy puede ser sub-óptimo en 14 meses. Diseñar la arquitectura asumiendo que el horizonte de cada agente individual va a crecer — los patterns que distribuyen trabajo en muchos sub-agentes pequeños pueden volverse obsoletos cuando un solo agente pueda absorber toda la tarea.
Patrón formal nuevo — Autonomy slider (Andrej Karpathy, mayo 2026)
yc-ai-construccion-y-agentes-agregada aporta un patrón formal que NO estaba en el catálogo Neo Kim:
Autonomy slider — el humano decide explícitamente cuánto autónomo es la IA para una tarea específica.
andrej-karpathy argumenta que los modelos son “people spirits” falibles → el ingeniero debe mantener al modelo “on the leash”, trabajar en chunks pequeños, construir GUIs custom para auditar código generado, NO aceptar dumps masivos sin verificación.
Diferencia con los 9 patrones de Neo Kim: los 9 patrones definen QUÉ arquitectura usar (ReAct, Plan-and-Execute, Hierarchical, etc.); el autonomy slider define cuánto control humano mantener dentro de la arquitectura elegida. Es ortogonal — cada patrón se ejecuta con un setting de slider distinto.
Cómo se implementa en producto real (en mayo 2026):
- Cursor / Claude Code tienen “approval modes” (auto / chat / agent) — discrete steps de slider.
- Cline tiene “auto-approve” granular por tipo de acción (read / write / execute).
- Nadie aún implementa un slider continuo — pendiente como pregunta abierta del concept.
Convergencia institucional — 7 voces (YC AI Startup School)
yc-ai-construccion-y-agentes-agregada consolida 7 voces convergentes sobre la transición chat → agentic:
| Voz | Aporte específico |
|---|---|
| Andrew Ng | ”Chat sin agentes = ensayo sin tecla backspace” — iteración loop como tesis central |
| Aaron Levie | Agentes prosperan en data NO estructurada (mayoría de enterprise) → desbloquea pricing por volumen |
| Aravind Srinivas | Perplexity = “cognitive operating system” — agentes corren async como procesos cloud paralelos |
| Sam Altman | Agente como “empleado junior” — tarea compleja, horas de trabajo, propuesta de vuelta |
| Andrej Karpathy | Autonomy slider + on-the-leash (ver sección arriba) |
| Jared Kaplan | Curva 7-meses (ver sección arriba) + organizational knowledge como ingrediente faltante |
| Jordan Fisher | ”Alignment es necesidad económica, no ética opcional” — confiar 5 min vs una semana son problemas distintos |
Esta convergencia eleva el concept de “catálogo de patrones” a consenso cross-industry sobre dónde va el campo en 12-24 meses.
Conexiones
- mcp-protocol — capa de tools que los patrones agentic asumen.
- agent-memory — dimensión arquitectónica de cada patrón.
- arquitectura-software — disciplina hermana: separar concerns, evitar sobre-ingeniería, “usá lo más simple que soporte el cambio previsible”.
- vibe-coding — los builders del cluster Starter Story aplican patrones de facto sin nombrarlos; el catálogo formal sube el techo de complejidad manejable por solo founders.
- ia-y-desarrollo — patrones agentic son la práctica concreta del frame “el código pasa de input a output”.
Posición en el wiki
- Concept central del cluster inbox-2026-05-ai-agents-mcp-agregada.
- Aporta vocabulario formal al topic agentes-ia-arquitectura (nuevo).
Update mayo 2026 — AI Engineer Conference 2025
ai-engineer-agentes-mcp-evals-agregada aporta patrones de durabilidad y tolerancia a fallos que faltaban al catálogo Neo Kim:
Durabilidad — ejecución que sobrevive a caídas
- Temporal y Vercel Workflow DevKit — frameworks de ejecución duradera. El ingeniero programa el “camino feliz”; el framework maneja reintentos, colas y persistencia del estado.
- Orquestación centralizada vs coreografía: para flujos complejos, un orquestador central (LangGraph) dirige a los agentes en lugar de permitir que se llamen libremente entre sí. Evita condiciones de carrera, bucles infinitos, y mantiene única fuente de verdad.
- Snapshot y restore (Trigger.dev): micro-VMs Firecracker toman instantánea del entorno (después de
npm install, dependencias, etc.), comprimen en disco y restauran en milisegundos cuando llega un nuevo evento. Durabilidad cross-turno sin servidores encendidos inútilmente. - Pausas (sleep/suspend): workflows duraderos suspenden ejecución sin consumir cómputo. Caso típico — agente espera aprobación humana → VM apagada → semanas después se reactiva exactamente donde quedó.
Patrones de recuperación de fallos
| Patrón | Función | Implementación típica |
|---|---|---|
| Circuit Breakers | Evitar fallos en cascada | Todo llamado a agente/tool envuelto en cortacircuitos; si falla 5 veces, el circuito abre |
| Patrón Saga (compensación) | Revertir cuando un paso falla | Cada agente tiene ejecutar + compensar; si C falla, orquestador llama compensaciones de B y A en orden inverso |
| Structured Handoffs | No perder información entre agentes | Reporte estructurado: qué se completó, qué comandos se ejecutaron (con códigos de salida), qué quedó pendiente |
| Agentes Validadores Adversarios | Evitar que el agente valide su propio código | Validador separado, sin “inversión emocional” en el código, interactúa con la app en vivo, da feedback duro |
| Estado inmutable (append-only) | Permitir time travel y multi-agente sin races | Cada agente genera nueva versión inmutable del estado (V1 → V2); permite linaje y rollback |
Sub-agentes para aislamiento de contexto (cross-link)
Más allá del frame “context drift = killer silencioso” ya documentado: la práctica concreta validada en AI Engineer es dar a sub-agentes contexto en blanco que ejecutan tareas largas (leer docs, buscar en código) y devuelven solo el resumen sintetizado al agente principal. Ver context-engineering para la disciplina general.
Sistema de archivos como memoria (cross-link)
Los agentes externalizan su memoria escribiendo planes, listas de tareas y decisiones de diseño en archivos persistentes (agent.md) dentro del entorno de trabajo. Ver agent-memory para la disciplina general — los archivos en filesystem son memoria episódica explícita y auditable.
Fuentes
- inbox-2026-05-ai-agents-mcp-agregada — fuente principal.
- system-design-one — catálogo formal (9 patterns).
- emerging-ai — operativa (harness, teams, 4-agent base, playbook April 2026).
- kent-beck — voz contrarian (Genie Lessons).
- yc-ai-construccion-y-agentes-agregada ⭐ — 7 voces convergentes + curva 7-meses (Kaplan) + autonomy slider (Karpathy) como patrón formal ortogonal a los 9.
- andrej-karpathy — voz canónica del autonomy slider y del frame “on the leash”.
- ai-engineer-agentes-mcp-evals-agregada ⭐ — patrones de durabilidad (Temporal, Trigger.dev snapshots), Circuit Breakers, Saga, Structured Handoffs, Validador Adversario, estado inmutable.
Preguntas abiertas
- ¿Hay convergencia entre los 9 de Neo Kim y los 4 de Emerging AI? Probable que sí — el episodio Neo Kim cubre superset. Falta verificar.
- ¿Existe equivalente del GoF book para patterns agentic — referencia canónica con código de ejemplo? Aún no en el wiki.
- ¿Qué patrón aplica para apps mobile B2C con un solo usuario (caso apps-mobile-b2c)? Probable: agentes son overkill, workflow + tool use simple basta.