Agentes IA en producción: los 5 patrones de arquitectura que realmente funcionan

Montar un agente de IA que funcione en un notebook es sencillo. Que ese agente funcione de forma fiable en producción, bajo carga real, con usuarios reales y sin que explote cada vez que el modelo alucina, es otra historia completamente distinta.

Llevamos dos años viendo cómo equipos de todo tamaño pasan por el mismo ciclo: prototipo impresionante, demo que funciona, deploy que colapsa. El problema casi nunca es el modelo. El problema es la arquitectura que rodea al modelo.

Estos son los cinco patrones que, tras revisar docenas de sistemas en producción, realmente marcan la diferencia.

1. ReAct con memoria episódica acotada

El patrón ReAct (Reasoning + Acting) es el punto de partida de casi todos los agentes. El agente razona, actúa, observa el resultado, y vuelve a razonar. El problema en producción es que la ventana de contexto crece sin control.

La solución que funciona es la memoria episódica acotada: en lugar de pasar todo el historial al modelo, pasas solo los últimos N pasos relevantes más un resumen comprimido del estado anterior. El agente sigue teniendo continuidad, pero el coste por llamada no crece indefinidamente.

def build_context(history: list[Step], max_steps: int = 10) -> str:
    recent = history[-max_steps:]
    summary = summarize(history[:-max_steps]) if len(history) > max_steps else ""
    return format_context(summary, recent)

2. Tool calling con contrato explícito

El mayor error en tool calling no es el modelo: es que los desarrolladores definen las herramientas de forma ambigua. Si el modelo puede interpretar la herramienta de dos maneras distintas, lo hará, y eligirá la incorrecta justo cuando no debes.

El patrón correcto es tratar cada tool como un contrato: nombre inequívoco, descripción que incluye cuándo NO usar la herramienta, ejemplos de input/output, y validación de esquema en ambas direcciones.

Los sistemas que usan Pydantic o Zod para validar los argumentos antes de ejecutar la tool tienen tasas de error hasta 60% menores que los que confían ciegamente en el output del modelo.

3. Supervisor-Worker para tareas largas

Cuando la tarea requiere más de 5-6 pasos, el patrón de agente único empieza a degradarse. El contexto se llena, el modelo pierde el hilo, y los errores se acumulan.

El patrón Supervisor-Worker divide el trabajo: un agente supervisor descompone la tarea en subtareas atómicas y delega en agentes worker especializados. Cada worker tiene un scope acotado y un contexto limpio.

Lo importante es que el supervisor no intenta ejecutar nada directamente: su único trabajo es planificar, delegar, y agregar resultados. La separación de responsabilidades es lo que hace que el sistema sea debuggeable.

4. Checkpointing y reanudación

Los agentes de larga duración fallan. El modelo tiene un error transitorio, la API externa devuelve un 503, el usuario cierra la sesión. Sin checkpointing, todo el trabajo previo se pierde.

El patrón es simple pero pocas implementaciones lo tienen desde el principio: serializa el estado del agente (qué pasos completó, qué observaciones tiene, qué plan sigue) después de cada paso significativo. Si algo falla, reanuda desde el último checkpoint válido.

@dataclass
class AgentCheckpoint:
    task_id: str
    completed_steps: list[Step]
    current_plan: Plan
    observations: dict[str, Any]
    created_at: datetime

async def run_with_checkpoint(task: Task, storage: CheckpointStorage):
    checkpoint = await storage.load(task.id) or AgentCheckpoint.new(task)
    async for step in agent.run(task, resume_from=checkpoint):
        await storage.save(step.checkpoint)
        yield step

5. Evaluación continua en el loop

El quinto patrón es el menos glamuroso y el más importante: un evaluador automático que corre dentro del loop de ejecución, no solo al final.

En lugar de ejecutar toda la cadena y ver el resultado al final, el evaluador revisa cada paso intermediario: ¿la acción tiene sentido dado el objetivo? ¿el output de la tool es plausible? ¿el agente está en bucle?

Los equipos que implementan esto detectan el 80% de los fallos antes de que el agente llegue a cometer un error visible al usuario. El coste es una llamada adicional al modelo por paso —normalmente con un modelo más pequeño y barato—, que compensa con creces.

El patrón que no está en esta lista

Hay un patrón que todo el mundo menciona y pocos usan bien: human-in-the-loop. No como fallback cuando todo falla, sino como decisión de diseño deliberada para acciones de alto impacto.

Los sistemas de producción más robustos no intentan automatizar el 100%. Identifican con precisión qué decisiones deben pasar siempre por un humano y construyen el flujo alrededor de eso desde el principio, en lugar de añadirlo como parche después.

Eso, más que cualquier patrón técnico, es lo que separa los agentes que dan vergüenza mostrar de los que dan orgullo.