Patrones de agentes de IA: simplicidad y verificación

«Tu IA lo olvida todo en cuanto termina una conversación». Eso describe una aplicación sin estado ni contexto persistente, no todos los productos de IA. El estado de una conversación y la memoria entre sesiones son capacidades distintas que una aplicación puede proporcionar. Introducción de LangChain a la memoria

Pero la memoria no responde a la siguiente pregunta de arquitectura: ¿qué debe poder hacer el agente con lo que recuerda? Un asistente de soporte puede necesitar una conversación anterior para entender una reclamación. Eso no le permite interpretar un recuerdo como «soy administrador» como autorización para emitir un reembolso. Nuestra guía de implementación de Supermemory explica la extracción, la actualización y el olvido entre sesiones. Aquí decidimos cómo controlar la ejecución.

Con los agentes de IA, la complejidad debe justificar su presencia. Mi punto de partida es el sistema más pequeño que cumple los criterios de aceptación. Anthropic también recomienda comenzar con soluciones simples y valorar el comportamiento agéntico adicional frente a su latencia y coste. Recomendaciones de Anthropic para agentes eficaces

Esta guía compara cinco patrones útiles según los fallos que pretenden resolver. Son decisiones combinables, no una taxonomía exhaustiva ni una escala de madurez de cinco niveles. En particular, la verificación es un control de riesgo, no un premio por alcanzar una arquitectura avanzada. Fuentes revisadas el 17 de septiembre de 2026. Los ejemplos y las pruebas de aceptación son propuestas de diseño, no resultados de proyectos de clientes.

¿Qué patrón de agente de IA resuelve tu fallo concreto?

Identifica el primer requisito incumplido antes de añadir otra llamada al modelo. La falta de contexto apunta a una mejor gestión del contexto. Un proceso de negocio predecible apunta a un flujo programado. Ninguno justifica automáticamente un bucle autónomo.

La última fila puede aplicarse a cualquiera de las anteriores. Una propuesta de pago generada con una sola llamada necesita autorización tanto como un agente de varios pasos. En cambio, un resumidor de solo lectura no mejora simplemente por incorporar un planificador.

1. Single-shot: conserva la base cuando funciona

Un diseño single-shot envía una tarea acotada al modelo una vez y devuelve su salida sin un bucle autónomo de herramientas. En sentido estricto, es un flujo básico con un LLM, no necesariamente un agente según las definiciones que exigen seleccionar acciones dinámicamente.

Utilízalo para extraer campos de una reclamación disponible, clasificar una solicitud, resumir un documento aprobado o redactar una respuesta con contexto completo. Los datos necesarios pueden prepararse de forma determinista antes de la llamada. El modelo no necesita decidir cómo recuperarlos.

Ejemplo: convertir un mensaje de soporte en categoría, urgencia y resumen breve. Valida el esquema con código convencional. La ausencia de campos obligatorios debe provocar un error de validación o una solicitud de revisión, no un número de pedido inventado.

La ventaja es una ruta de ejecución pequeña en la aplicación. Su límite es que el modelo no puede inspeccionar un resultado y decidir consultar otra fuente sin cambiar la arquitectura. Una llamada tampoco es intrínsecamente determinista, barata o correcta: depende del modelo, el contexto y la tarea. Conserva esta base mientras la calidad medida sea suficiente. Para cálculos exactos o transformaciones fijas, empieza por código convencional.

2. ReAct: añade un bucle cuando las observaciones cambian la siguiente acción

ReAct alterna decisión, acción y observación. El resultado de una herramienta informa la siguiente decisión, en lugar de limitarse a completar una secuencia fija. El artículo original estudia la combinación de razonamiento y acciones sobre un entorno. Artículo de investigación sobre ReAct

Ejemplo: un asistente consulta un pedido. Una incidencia de envío le lleva a revisar los eventos de entrega; una devolución completada, a consultar el estado del reembolso. La primera solicitud no permitía saber cuál sería la siguiente consulta útil.

Es distinto de un proceso que siempre carga un pedido, recupera la misma política y genera un resumen. Para esa secuencia fija, el código explícito puede ser más fácil de probar que la orquestación elegida por el modelo.

En una primera implementación, establece un máximo de pasos, un plazo total y un presupuesto de llamadas a herramientas. Detecta consultas repetidas sin nueva información. Distingue un error de transporte reintentable de un rechazo de negocio y devuelve un estado inequívoco de tarea incompleta cuando se agote el presupuesto. Registra nombres de herramientas, argumentos, resultados y resúmenes breves de decisiones; no exijas acceso al razonamiento oculto del modelo.

Las observaciones de las herramientas son datos, no una nueva fuente de autoridad. Comprueba el acceso antes de lecturas sensibles, valida argumentos y controla cada escritura con consecuencias. Una página recuperada que diga «ignora la política» no debe poder cambiarla.

3. Planificador-ejecutor: separa el plan de la realización del trabajo

El patrón planificador-ejecutor asigna responsabilidades distintas a la planificación y la ejecución. El planificador propone pasos y el ejecutor los completa. Esa separación es la idea central de la descripción original de LangChain, no una garantía de mejores resultados. Arquitectura de planificación y ejecución

Considéralo cuando una tarea larga omita entregables, pierda dependencias o resulte difícil de reanudar. Por ejemplo, un informe de mercado necesita recopilar evidencias antes de analizarlas y analizar antes de recomendar. Una redacción final convincente no debe ocultar un paso de investigación ausente.

Cada paso propuesto debe indicar su entrada, salida esperada, dependencia y comprobación de finalización. Guarda el trabajo completado como estado explícito. Replanifica cuando la evidencia invalide una suposición, no simplemente porque el modelo pueda generar otro plan. Limita la replanificación y muestra los pasos bloqueados a una persona responsable.

Planificar y ejecutar no exige modelos distintos ni un grupo de agentes. Un único ejecutor puede recorrer el plan. Los trabajadores paralelos solo ayudan cuando las tareas son realmente independientes; las escrituras compartidas y las salidas dependientes requieren coordinación. Si los pasos ya se conocen y son estables, un flujo predefinido suele ser el diseño más pequeño.

El fallo que debes vigilar es un plan bien presentado pero incorrecto. Comprueba su alcance y requisitos previos antes de ejecutarlo. Verifica los resultados terminados en lugar de tratar las casillas marcadas como evidencia.

4. Reflexión: mejora un borrador sin confundirlo con una prueba

La reflexión añade crítica y revisión después de una primera salida. Self-Refine utiliza comentarios generados por el modelo para revisar un borrador y comunica mejoras en las tareas evaluadas. No demuestra una garantía universal de precisión. Investigación sobre Self-Refine

Aplica criterios concretos: ¿responde a cada punto solicitado, distingue hechos de suposiciones y se limita a fuentes aprobadas? «Piensa más» no es un criterio de aceptación. Empieza con una revisión y compárala con la versión original.

Ejemplo: un borrador de respuesta contiene los datos correctos, pero omite el siguiente paso. Una crítica puede señalarlo y pedir una redacción más clara. En código, puede sugerir mejoras, pero la compilación, las pruebas y la revisión humana siguen siendo comprobaciones distintas.

La investigación sobre autocorrección intrínseca encontró que los modelos probados podían fallar al corregir razonamientos sin feedback externo e incluso empeorarlos. Es una advertencia ligada a tareas y modelos concretos, no una afirmación sobre la incapacidad de todos los sistemas posteriores. Estudio de autocorrección sin feedback externo

La distinción práctica es sencilla: la reflexión pregunta si el borrador puede mejorar. La verificación comprueba si un requisito se cumple realmente. La aprobación de un segundo modelo tampoco demuestra los permisos de un usuario ni el saldo correcto de una cuenta.

5. Verificador independiente: separa proponer una acción de autorizarla

La ejecución condicionada por un verificador impide que una propuesta surta efecto hasta que un control independiente la permita. OWASP recomienda autorización en sistemas posteriores, permisos mínimos y aprobación humana para acciones de alto impacto, no que el LLM decida su propia autoridad. Recomendaciones de OWASP sobre agencia excesiva

«Independiente» significa que el agente no puede saltarse la comprobación, reescribir su política ni fabricar sus evidencias. El verificador puede combinar validación de esquemas, reglas, consultas a sistemas fiables, cálculos deterministas o aprobación humana. Otro modelo puede aportar una evaluación orientativa, pero no debería ser la única barrera de autorización.

Para un reembolso, exigiría que la aplicación identificase al actor autenticado y su organización, consultase el pedido actual en el sistema de registro, validase importe y moneda, comprobase el saldo reembolsable y confirmase la aprobación necesaria. Son controles de ingeniería propuestos, no una implementación completa de pagos.

Vincula la aprobación a la acción exacta: destinatario, importe, moneda y versión relevante del registro. Una propuesta modificada necesita una nueva validación. La guía de OWASP sobre autorización de transacciones exige aplicación en el servidor y una comprobación final ligada a la ejecución. Guía de OWASP para autorizar transacciones

La falta de evidencias, una respuesta malformada del verificador o su timeout deben bloquear la ejecución o remitirla a revisión. Un rechazo de negocio no debe convertirse en un bucle ilimitado de reintentos. Diseña idempotencia y conciliación para resultados inciertos: un timeout de pago no demuestra que el pago no se realizara. Comprueba el estado actual antes de otra escritura.

Sitúa el control antes de cada efecto relevante, incluidas las llamadas intermedias a herramientas, no solo antes de la respuesta final. Tras ejecutar, concilia el resultado real. La autorización previa y la verificación posterior resuelven problemas diferentes.

Un asistente de soporte no necesita los cinco patrones a la vez

Imagina a un cliente que pregunta por un pedido retrasado y un posible reembolso. Es un ejercicio de diseño, no una implementación de un cliente. Empieza con clasificación single-shot y un flujo de solo lectura. Añade ReAct únicamente cuando la investigación adecuada dependa de consultas anteriores.

El planificador es opcional: una consulta sencilla del estado de un pedido probablemente no lo necesita. Incorpóralo cuando la investigación abarque varios entregables dependientes. La reflexión también es opcional y corresponde al borrador de respuesta, no a la autorización del pago.

La ruta del reembolso es distinta. Mantén las credenciales de ejecución fuera del modelo, valida la propuesta estructurada, consigue las aprobaciones necesarias, ejecuta mediante una interfaz limitada y concilia el resultado. Que la propuesta proceda de una llamada al modelo o de varias no cambia este límite.

Persiste el estado necesario para reanudar con seguridad, pero no confundas la transcripción de una conversación con un registro de ejecución. Oculta los datos sensibles de las trazas y prueba los reinicios. La guía de seguridad de agentes de OWASP profundiza en restricciones de herramientas, protección de memoria y controles operativos. Guía de seguridad de agentes de IA de OWASP

¿Cómo decides si otro bucle justifica su presencia?

Compara la base y un único cambio propuesto con las mismas tareas representativas. Mantén estables la configuración del modelo y los criterios de evaluación cuando sea posible, registra las diferencias inevitables y repite los ensayos. De lo contrario, una supuesta mejora arquitectónica podría deberse a otro modelo o a una muestra más fácil.

Mide resultados aceptados, afirmaciones sin respaldo, acciones no autorizadas, esfuerzo de revisión, timeouts y latencia completa p50/p95. Cuenta todas las llamadas al modelo y las herramientas, incluidos reintentos y revisiones. Para el cálculo económico, utiliza nuestra guía de coste por acción de agentes de IA. Aquí se decide si el paso adicional reduce suficientemente el fallo concreto para justificar su carga operativa.

Los controles de seguridad no son experimentos opcionales con usuarios reales. Prueba los flujos con consecuencias en un entorno aislado o en modo sombra antes de conceder acceso de escritura. No elimines la autorización porque una prueba sin controles sea más rápida.

Nuestra guía de arquitectura del agent harness explica el entorno de ejecución, la recuperación y las responsabilidades operativas. Para una implementación concreta, el servicio de desarrollo de IA de Wavect conecta el flujo con requisitos de producto y pruebas de aceptación. Nuestro caso de un prototipo convertido en piloto empresarial es un ejemplo de entrega independiente, no evidencia de que allí se compararan estos patrones.

Define criterios de publicación con la lista de QA de software antes del lanzamiento o comenta el fallo de tu flujo de agentes. Trae una traza fallida, un ejemplo correcto y la acción que el sistema nunca debe ejecutar sin aprobación.