Arquitectura de agentes de IA: los patrones que aguantan producción
Las discusiones de arquitectura suelen empezar por el lado equivocado: un diagrama de cajas con nombres de conceptos. La versión útil empieza por el fallo que quieres evitar, porque cada patrón de abajo existe para impedir una tarde mala concreta.
Estos seis son a los que volvemos siempre. Se combinan: un agente en producción suele ser un bucle acotado con pasarela de herramientas, dos capas de memoria y una puerta humana, más un pase crítico solo donde el coste de equivocarse justifica otra llamada.
1. El bucle acotado#
El caso base y tu opción por defecto. Un bucle sobre un conjunto pequeño de herramientas con condiciones de parada explícitas: tope de pasos, tope de gasto, detección de repeticiones y límite de reloj. Su virtud es una traza lineal que se lee de arriba abajo. Todos los demás patrones son añadidos, no sustitutos.
Si no puedes dibujar tu agente como un bucle con una lista de salidas, aún no tienes arquitectura: tienes un prompt con ambiciones.
2. Planificador–ejecutor con replanificación#
Para tareas que superan los cinco pasos, pide primero un plan numerado, ejecuta y replanifica al fallar en vez de seguir un plan caduco. El beneficio no es precisión: es que una persona ve la intención antes de la acción, lo que hace posibles la aprobación y la depuración. El coste es una llamada más y la disciplina de tratar el plan como revisable.
3. El pase crítico#
Una segunda llamada revisa el borrador o la acción propuesta contra el objetivo y las pruebas recuperadas, y puede devolverla una vez. Eso captura una parte real de la salida segura pero sin respaldo. Úsalo donde un resultado erróneo sea caro y una llamada extra no lo sea: mensajes a clientes, resúmenes financieros, cambios de código.
| Patrón | Llamadas extra | Aporta | Sáltalo si |
|---|---|---|---|
| Bucle acotado | 0 | Trazabilidad, control de coste | Nunca: es la base |
| Planificador–ejecutor | 1–2 | Intención visible, auditabilidad | Tareas de menos de cinco pasos |
| Pase crítico | 1 por salida revisada | Menos afirmaciones sin respaldo | Salidas baratas y reversibles |
| Pasarela de herramientas | 0 | Permisos, auditoría, límites | Solo en prototipos |
| Memoria por capas | 0–1 | Relevancia con contexto largo | Ejecuciones cortas |
| Puerta humana | 0 | Lo irreversible sigue seguro | Si nada es irreversible |
4. La pasarela de herramientas#
No dejes que el agente llame directamente a tus sistemas. Pon una capa delante de cada herramienta que haga cuatro cosas: validar argumentos contra un esquema, comprobar que ese usuario final puede tocar ese registro, aplicar un límite de tasa y escribir una línea de auditoría con el identificador de ejecución. Es la pieza de infraestructura de mayor valor del sistema y es código corriente, de días y no de semanas.
5. Memoria por capas#
Un historial indiferenciado es la causa más común de que un agente empeore según avanza la ejecución. Separa: objetivo y restricciones, que nunca se recortan; turnos recientes literales; turnos antiguos comprimidos en notas factuales cortas; y conocimiento recuperado, traído por paso y nunca acumulado. El contexto largo es caro y la atención es finita.
6. La puerta humana#
Cada acción irreversible va tras una aprobación explícita con contexto suficiente para decidir en segundos: qué va a pasar, sobre qué registro, por qué el agente lo cree correcto y qué hará si se rechaza. La puerta es una función de producto, no una limitación: es lo que te permite lanzar donde los errores cuestan dinero.
Preguntas frecuentes
¿Necesito los seis patrones?
No. Empieza por el bucle acotado y la pasarela; ambos son casi obligatorios en cualquier cosa que toque sistemas reales. La puerta humana llega en cuanto aparece una acción irreversible. El resto se gana con fallos concretos en una traza.
¿El pase crítico mejora de verdad la precisión?
En tareas donde el modelo puede producir respuestas plausibles sin respaldo, sí y de forma apreciable, sobre todo si le das las pruebas y le pides comprobar afirmaciones. En consultas simples suele estar de acuerdo y duplica el coste.
¿Dónde debe vivir la pasarela?
En tu propio servicio, entre el agente y los sistemas, con la identidad del usuario final fluyendo por ella. Si vive dentro del framework, la reimplementarás al cambiar y tu revisión de seguridad empezará de cero.
arquitectura de agentes iapatrones de diseño de agentesplanificador ejecutorpasarela de herramientasmemoria de agentes
