--- title: "Arquitectura de agentes de IA: herramientas, memoria y control" description: "Guía para diseñar agentes de IA con herramientas tipadas, estado persistente, permisos mínimos, aprobación humana, idempotencia y evaluaciones reales." canonical: "https://darwa-front.darwa.co/blog/es/arquitectura-agentes-ia-herramientas-memoria-control" language: "es" category: "Agentes de IA" tags: ["agentes de ia", "tool calling", "memoria", "seguridad"] author: "Darwa Engineering" published: "2026-08-28T06:46:00Z" updated: "2026-08-31T19:34:34.240722Z" reading_time_minutes: 3 --- # Arquitectura de agentes de IA: herramientas, memoria y control Diseña agentes que puedan trabajar de verdad sin entregarles permisos ilimitados: herramientas estrechas, estado persistente, aprobaciones y pruebas de fallo. ## Define el trabajo antes de elegir el modelo Un agente no es una conversación con acceso a todas las APIs. Empieza por un resultado verificable: clasificar una incidencia, preparar un borrador o reconciliar dos registros. Documenta qué evento inicia el flujo, qué datos puede leer, qué decisiones puede proponer y qué condiciones obligan a detenerse. Esa definición permite comparar calidad, coste y riesgo entre versiones. El [AI Risk Management Framework de NIST](https://www.nist.gov/itl/ai-risk-management-framework) resulta útil para asignar propietarios, riesgos y mediciones. La seguridad no puede depender de una frase como “no hagas nada peligroso” incluida en el prompt. ## Convierte las integraciones en capacidades pequeñas Evita herramientas genéricas como `execute_sql` o `request_any_url`. Expón operaciones de negocio concretas: `leer_pedido`, `preparar_respuesta` o `solicitar_reembolso`. El servidor debe comprobar el usuario, la organización, el recurso, los tipos, los importes máximos y el destino en cada llamada. Separa lectura de escritura y utiliza credenciales distintas por entorno. El modelo nunca necesita ver el secreto. Además, trata la salida de documentos, correos y páginas como entrada no confiable: puede contener instrucciones diseñadas para desviar el flujo. ## Guarda el estado fuera del chat Para una tarea de varios pasos, registra en base de datos el identificador, la etapa actual, los datos aprobados, los intentos y el resultado de cada herramienta. La conversación sirve como contexto, pero no sustituye un registro transaccional. Usa una clave de idempotencia para cualquier efecto externo, de modo que un reintento no duplique una compra o un mensaje. Antes de ejecutar, vuelve a leer los datos autoritativos. Si el cliente canceló el pedido mientras el agente razonaba, un contexto antiguo no debe restaurarlo. Los cambios concurrentes necesitan versiones o actualizaciones condicionales. ## Diseña aprobaciones que expliquen la consecuencia Una aprobación útil muestra acción, destino, campos relevantes, coste, evidencia y tiempo de caducidad. Aprobar “lo que el agente decida” no informa al operador. Si cambia el importe o el destinatario, la aprobación anterior deja de ser válida. No todo paso requiere intervención. La búsqueda y el borrador pueden ser automáticos mientras el envío, el pago o el borrado se detienen. Así la autonomía se concede por herramienta y nivel de riesgo, no como un interruptor global. ## Evalúa fallos, no solo respuestas bonitas Crea casos a partir de trabajo real anonimizado: datos incompletos, permisos revocados, instrucciones contradictorias, inyección de prompt, timeouts y reintentos. Mide si eligió la herramienta correcta, si sus argumentos eran válidos, si pidió ayuda a tiempo, cuánto costó y si dejó el sistema en un estado recuperable. Un promedio alto no compensa una sola fuga entre clientes. Define límites de publicación para incidentes graves y compara cada versión con el mismo conjunto. Un agente preparado para producción sabe actuar, pero también sabe no actuar cuando carece de evidencia o autoridad.