Agentes de IA: cómo diseñar su arquitectura para producción

La arquitectura de agentes de IA empieza con un solo agente capaz de investigar un caso, proponer una acción y detenerse hasta recibir aprobación. Contrata el modelo y la infraestructura estándar; desarrolla las reglas de negocio, los límites de los permisos y las pruebas de que el trabajo se completó correctamente.

Un agente de soporte resulta útil cuando conecta el mensaje de un cliente con la cuenta, la política y la acción adecuadas. Para que además sea confiable, la aplicación que lo rodea debe poder explicar a qué accedió, impedir cambios no autorizados y recuperarse cuando falle una herramienta.

Imagina el sistema como una red de transporte. El modelo elige la ruta, las herramientas permiten llegar a los destinos, la memoria conserva el recorrido y la orquestación coordina los desplazamientos. Los controles de seguridad y los puntos de aprobación regulan el acceso; la evaluación y los registros indican si los pasajeros llegaron al lugar correcto.

Las descripciones de los componentes se verificaron con la documentación de Anthropic, OpenAI y Google Cloud, y con la especificación de Model Context Protocol, el 25 de octubre de 2026. El flujo de soporte es un diseño ilustrativo, no la descripción de un sistema desplegado para un cliente.

Arquitectura de agentes de IA: qué debe controlar la aplicación

La arquitectura define qué puede decidir el modelo y qué debe hacer cumplir la aplicación. Ese límite importa más que el nombre del framework.

El LLM aumentado de Anthropic —un modelo de lenguaje conectado a mecanismos de recuperación de información, herramientas y memoria— es un buen punto de partida. Su guía distingue entre un flujo de trabajo cuyo recorrido está definido en el código y un agente que elige sus siguientes acciones de forma dinámica. Recomienda añadir complejidad solo cuando la tarea lo exija. Guía de Anthropic sobre agentes

Al clasificar una solicitud de soporte, el modelo podría decidir si consulta una guía de resolución de problemas o revisa un pedido. El código de la aplicación debe seguir determinando a qué registros de clientes puede acceder, si se permite el reembolso propuesto y qué ocurre si la ejecución se interrumpe a mitad del proceso.

Mantén predecible lo que ya lo es. Autenticar una cuenta, comprobar un derecho de acceso y registrar una acción completada no requieren que un agente improvise. Reserva al modelo la parte incierta: interpretar el mensaje, seleccionar las pruebas relevantes y proponer un siguiente paso útil.

Diagrama de arquitectura: capas y conexiones del agente

Un agente necesita un bucle controlado, con estado persistente y comprobaciones a su alrededor. Las capas siguientes representan responsabilidades; no hace falta un servicio ni una suscripción independiente para cada una.

Las conexiones forman un bucle: la aplicación reúne el contexto, el modelo solicita una acción, el entorno de ejecución la comprueba y la ejecuta, y el resultado pasa a formar parte del contexto para la siguiente decisión. La guía del bucle de un agente explica en detalle este ciclo y sus condiciones de parada.

Modelo: interpretar el caso y proponer la siguiente acción

OpenAI Agents SDK, la biblioteca de OpenAI para crear flujos de trabajo con agentes, reúne un modelo, instrucciones y herramientas en un Agent; el modelo interpreta el ticket y propone qué hacer a continuación. En este diseño, recibe un problema de acceso a una cuenta y solicita el registro de derechos de acceso correspondiente antes de redactar una respuesta. Elige el modelo mediante la evaluación de casos de soporte representativos: una redacción elocuente no demuestra que seleccione la herramienta correcta ni que tenga autorización para actuar. Definiciones de agentes de OpenAI

Herramientas y MCP: conectar con los sistemas del negocio

Model Context Protocol (MCP), una interfaz estándar entre las aplicaciones de IA y las capacidades externas, define herramientas con nombre y un inputSchema, su descubrimiento mediante tools/list y su invocación mediante tools/call. La consulta de una cuenta puede exponerse a través de MCP o de una función convencional que llame a una API del negocio. En ambos casos, el servicio subyacente debe validar los argumentos y limitar el acceso a la cuenta correcta. MCP estandariza la conexión; la guía de MCP explica el protocolo y sus límites de confianza. Especificación de herramientas de MCP

Memoria: conservar el contexto adecuado

Agent Development Kit (ADK), el framework de Google para crear agentes, utiliza Session y state para la información de una interacción y permite mantener memoria entre sesiones mediante componentes como Memory Bank. En soporte, guarda el caso actual y la aprobación pendiente en el almacenamiento de la aplicación, consulta los datos actuales de la cuenta en su fuente y conserva las preferencias del cliente solo cuando corresponda. Son funciones distintas; la guía de memoria de agentes explica el contexto, el almacenamiento de sesiones y la memoria de mayor duración. Guía de arquitectura de Google Cloud

Orquestación: gestionar el avance, las pausas y la recuperación

La guía de OpenAI para crear agentes describe cómo Agents SDK gestiona el bucle de herramientas, los traspasos entre agentes y los controles de seguridad. Así proporciona a la aplicación un motor para ejecutar el trabajo que dirige el modelo. A su alrededor, guarda de forma persistente si el ticket está en investigación, pendiente de revisión, en ejecución o terminado, de modo que el proceso pueda recuperar el caso tras un reinicio. La guía de orquestación explica cómo encajan las ejecuciones de agentes en un proceso de negocio más amplio. Guía de agentes de OpenAI

Controles de seguridad y aprobación humana: controlar las consecuencias

OpenAI Agents SDK distingue los controles automáticos de seguridad de las interrupciones para obtener aprobación, que pausan una llamada a una herramienta y devuelven un estado desde el que se puede reanudar la ejecución. En el agente de soporte, valida automáticamente el acceso a la cuenta y los argumentos propuestos; después exige que una persona autorizada apruebe cualquier cambio sensible antes de ejecutarlo. Aplica estos controles junto a la herramienta que realiza la acción. La guía de controles de seguridad detalla las comprobaciones. Controles de seguridad y revisión humana de OpenAI

Evaluación y observabilidad: saber qué ocurrió y si estuvo bien

El sistema de trazas de OpenAI Agents SDK registra llamadas al modelo, llamadas a herramientas, traspasos entre agentes y actividad de los controles de seguridad. Su guía de evaluación de trazas explica cómo puntuar el comportamiento de un flujo según criterios explícitos. La observabilidad muestra cómo se desarrolló un ticket de soporte; la evaluación comprueba si el agente seleccionó la cuenta correcta, respetó la política y produjo una respuesta respaldada por pruebas. Define qué datos recopilar y durante cuánto tiempo conservarlos antes de comparar herramientas de observabilidad para LLM. Trazas del SDK, evaluación de agentes

La arquitectura de referencia de Google Cloud reúne ADK, Cloud Run, acceso al modelo, conexiones MCP, Model Armor y observabilidad en un despliegue concreto. El ejemplo documentado excluye expresamente del diagrama la memoria y el almacenamiento de sesiones. Por tanto, la persistencia del estado del caso sigue siendo una decisión de diseño; no se puede dar por incluida. Arquitectura de referencia

Del ticket entrante a una respuesta que resuelve el caso

Asigna al agente un caso acotado cuya finalización se pueda comprobar. En este ejemplo, un cliente dice que pagó por el acceso, pero aún no puede usar el servicio. El agente puede investigar y preparar una corrección; durante el despliegue inicial, una persona responsable de soporte aprueba tanto los cambios en la cuenta como la respuesta que se enviará.

Los nombres de herramientas que aparecen a continuación describen funciones que tendrías que implementar en la aplicación, no una integración de soporte que un proveedor ofrezca lista para usar.

1. 1

   Recibir e identificar el caso

   El webhook del ticket, un evento que envía el sistema de soporte, crea o retoma un caso a partir del identificador externo del ticket. Autentica al cliente mediante el flujo de cuentas existente; una dirección de correo escrita en el mensaje no debe servir para conceder acceso a una cuenta. Guarda el mensaje entrante como contenido del cliente que no es de confianza.

2. 2

   Recuperar pruebas mediante herramientas de alcance limitado

   Dota al agente de capacidades como get_account_entitlement y search_support_policy. Vincula el acceso a la cuenta con la identidad autenticada en el código de la aplicación y devuelve el registro pertinente y la referencia a la política. El modelo puede elegir qué pruebas solicitar sin disponer de acceso irrestricto a la base de datos.

3. 3

   Preparar una propuesta fundamentada

   El modelo contrasta lo que comunica el cliente con el registro de la cuenta y la política aplicable. Si las pruebas justifican corregir los derechos de acceso, redacta el cambio propuesto y la respuesta; si faltan pruebas o se contradicen, pide una aclaración o deriva el caso. Guarda las referencias de las pruebas junto con la propuesta para que quien la revise pueda comprobar su fundamento.

4. 4

   Pausar antes de actuar sobre el sistema del negocio

   Valida la operación propuesta según la política y guarda la acción pendiente y el estado de aprobación. Muestra a la persona responsable de soporte la cuenta afectada, el cambio exacto que se propone, las pruebas que lo respaldan y la respuesta para el cliente. Si rechaza la propuesta, la escritura sigue bloqueada y el caso vuelve a revisión o pasa a gestión manual.

5. 5

   Ejecutar y comprobar el resultado

   Tras la aprobación, vuelve a comprobar que la cuenta y la propuesta siguen coincidiendo con lo revisado y llama a la herramienta de corrección. Cuando el servicio subyacente lo permita, utiliza una clave de idempotencia: un identificador que impide aplicar de nuevo la misma operación al reintentarla. Confirma los derechos de acceso resultantes antes de enviar una respuesta que afirme que se ha restablecido el acceso; registra el resultado del envío antes de dar el caso por terminado.

6. 6

   Convertir el resultado en pruebas para la evaluación

   Vincula el resultado de la ejecución, la respuesta aprobada y el estado final del caso con la traza. Deriva a una persona los resultados inciertos, en lugar de interpretar un tiempo de espera agotado como un éxito o un fallo. Cuando la revisión detecte un error, conserva en el conjunto de evaluación un ejemplo del que se hayan eliminado adecuadamente los datos sensibles.

El fallo más delicado es una escritura de resultado ambiguo: el servicio de cuentas puede haber aplicado el cambio aunque tu aplicación nunca haya recibido la respuesta. Contrasta el estado con el sistema de origen antes de reintentar. Una transcripción que diga «Voy a restablecer el acceso» demuestra una intención, no que el acceso haya cambiado.

Patrones de arquitectura: cuándo conviene añadir otro agente

Mantén un solo agente mientras la tarea comparta una política coherente, un conjunto de herramientas y un responsable. Añade un especialista cuando resuelva un problema demostrado de separación de responsabilidades; después comprueba si la mejora se mantiene al sumar el trabajo de coordinación.

OpenAI distingue entre traspasos, en los que un especialista asume la conversación, y agentes como herramientas, en los que el agente principal llama a un especialista, pero conserva la responsabilidad sobre la respuesta. Su guía recomienda separar agentes cuando las instrucciones, las capacidades o la política difieren de forma sustancial. Orquestación y traspasos entre agentes

En el caso de soporte, buscar un artículo de ayuda y redactar una respuesta no justifican por sí solos agentes distintos. Una disputa de facturación sí podría hacerlo: puede exigir otra política, herramientas financieras restringidas y otra persona que revise las acciones. Puedes consultar a ese especialista para una evaluación acotada mientras el agente de soporte sigue siendo responsable del caso, o transferirle expresamente esa responsabilidad cuando deba hacerse cargo el flujo de facturación.

Diagrama de sistemas multiagente: separar por responsabilidades

Una política distinta es un motivo útil para plantear la separación, no un requisito universal. Las tareas independientes de recopilación de pruebas también pueden justificar agentes que trabajen en paralelo, pero solo si el responsable final puede conciliar resultados contradictorios y el beneficio observado compensa el trabajo adicional del modelo.

Antes de añadir un especialista, escribe qué fallo debería resolver: selección de herramientas incorrectas, instrucciones contradictorias, contexto excesivo o falta de conocimientos especializados. Compara el diseño propuesto con los mismos casos, incluidos los de fallo. Consérvalo solo si la mejora compensa el aumento de latencia, consumo, depuración y revisión. Es un criterio de decisión, no una promesa de mayor rendimiento.

Llamar a los agentes «investigador», «crítico» y «gestor» no les confiere un criterio independiente. Si parten de las mismas pruebas erróneas, su acuerdo puede limitarse a repetir el error. Para una clasificación más amplia, consulta el mapa de tipos de agentes de inteligencia artificial.

Qué contratar y de qué hacerse cargo en un sistema de agentes

Contrata los componentes intercambiables y conserva el control de las reglas del negocio. Para un primer agente en producción, la razón más sólida para desarrollar un componente es que tu flujo necesite un comportamiento que las opciones disponibles no puedan expresar u ofrecer.

Para fundadores: contrata un producto de agentes gestionado si admite tu flujo real, el punto de aprobación que necesitas y la exportación de pruebas. Desarrolla sobre componentes estándar cuando la política específica de cada cuenta o el comportamiento de las integraciones sea lo que te diferencia. Una demostración convincente no basta si no puedes recuperar un caso pausado o examinar una acción fallida.

Para CTOs y equipos de desarrollo: las herramientas del negocio deben tener un alcance limitado y poder probarse con independencia del modelo. Un entorno de ejecución gestionado puede alojar la aplicación, pero no puede deducir la diferencia entre un cliente que pide un reembolso y un empleado autorizado para concederlo. Define esa distinción en el servicio que realiza la operación.

Para responsables de operaciones: asume la responsabilidad de la cola de excepciones y de definir cuándo se considera resuelto un caso. Especifica quién se hace cargo de los casos pendientes, qué pruebas recibe y cuándo se puede cerrar un ticket. Una bandeja de aprobaciones que nadie atiende deja el flujo incompleto.

La ejecución de código es opcional para este agente de soporte. Si una tarea posterior requiere ejecutar código generado, trata su aislamiento como una decisión aparte y consulta la guía de entornos aislados para código de agentes. No añadas una shell de propósito general solo para consultar una cuenta.

Dónde pedir aprobación humana y qué registrar desde el principio

Sitúa la aprobación justo antes de la acción que requiere una autorización delegada. Revisar el texto del agente después de que el cambio en la cuenta ya se haya realizado no puede impedir ese cambio.

El mecanismo de aprobación de OpenAI devuelve una ejecución pausada y un estado que permite reanudarla; tu aplicación resuelve la decisión pendiente y continúa la ejecución. La misma documentación advierte que las comprobaciones de entrada y salida del agente no se aplican alrededor de cada llamada intermedia a una herramienta. Por eso hace falta una validación propia en el punto donde se realiza la acción. Ciclo de aprobación y límites del flujo de trabajo

En el despliegue ilustrativo, quien revisa ve juntos el cambio exacto en la cuenta y la respuesta. Si después de la revisión cambian la acción, el destinatario o las pruebas, exige una nueva decisión. Guarda quién aprobó qué, qué política se aplicó y si la ejecución coincidió con lo aprobado.

Usa la siguiente lista como base para definir los datos que se deben registrar. Una traza vincula los eventos de un caso; un span registra una operación individual dentro de ella.

• Identidad del caso: identificador del caso, identificador de la traza, evento de origen y referencia a la cuenta autenticada. Usa referencias en lugar de duplicar los datos del cliente por todas partes.
• Configuración: identificador del modelo devuelto por el proveedor, versión de las instrucciones, versión del esquema de herramientas y versión de la política. Estos datos explican qué comportamiento estaba vigente.
• Pruebas: identificadores de los documentos recuperados, revisiones pertinentes y ámbito de acceso. Registra en qué se sustentó la decisión sin copiar indiscriminadamente registros privados.
• Acciones: nombre de la herramienta, argumentos con los datos sensibles ocultos, marcas de tiempo, duración, estado del resultado e identificador de reintento o idempotencia. Conserva información suficiente para distinguir una acción propuesta de una completada.
• Decisiones: resultados de validación, motivo de derivación del caso, estado de aprobación, referencia a quien revisó y propuesta aprobada.
• Resultado y consumo: estado final del ticket, efectos confirmados en los sistemas, resultado de la entrega, consumo informado por el proveedor y etiquetas de evaluación. Haz seguimiento de las correcciones de los clientes y los casos reabiertos cuando el sistema de soporte facilite esos datos.

Este es un esquema recomendado para la aplicación, no una promesa de que un SDK recopile automáticamente todos los campos. Restringe el acceso, establece los plazos de conservación y elimina los secretos antes de exportar. No exijas registrar el razonamiento interno oculto del modelo: el rastro de auditoría debe sustentarse en entradas, salidas, acciones y pruebas observables.

Los límites que importan y las expectativas exageradas

El límite más importante es la autoridad que delegas. Establece topes explícitos de duración de las ejecuciones, actividad de las herramientas y consumo de recursos, además de una vía clara para derivar el caso. Define esos valores según tu carga de trabajo y los requisitos del servicio, en lugar de copiar un límite arbitrario de una demostración.

La memoria no es una fuente de verdad. Si una conversación guardada dice que el cliente tiene acceso y el sistema de cuentas indica lo contrario, investiga la discrepancia con los registros actuales de la fuente autorizada. Recordar más texto no corrige unas pruebas desactualizadas.

MCP no concede permisos. Su especificación de herramientas sigue exigiendo controles de acceso y validación de entradas. Un conector que expone una operación de amplio alcance necesita la misma revisión de autorizaciones del negocio que una API propia. Requisitos de seguridad de MCP

Terminar una ejecución no equivale a resolver bien un caso. Evalúa si se modificó la cuenta correcta, se respetó la política y la respuesta coincide con el resultado. La guía de evaluación de OpenAI pasa de inspeccionar trazas a utilizar conjuntos de datos para evaluaciones repetibles, de modo que los cambios se juzguen con criterios consistentes. Evaluación de flujos de trabajo con agentes

Tener varios agentes no elimina la necesidad de un responsable. Alguien debe hacerse cargo de la respuesta final, las pruebas compartidas y las excepciones sin resolver. Un especialista aporta valor porque tiene una responsabilidad distinta, no porque el diagrama de arquitectura parezca más sofisticado.

Preguntas frecuentes sobre la arquitectura de agentes

¿Qué es la arquitectura de agentes de IA?

La arquitectura de agentes de IA organiza las decisiones del modelo, las herramientas, la memoria, la orquestación, los controles y la evaluación que permiten a una aplicación llevar a cabo una tarea. En un agente de negocio, también determina quién puede autorizar acciones y cómo se comprueba que el trabajo se ha completado.

¿Qué es un agente de IA?

Un agente de IA utiliza un modelo para elegir acciones orientadas a un objetivo, observa sus resultados y decide cómo continuar. Su autonomía útil queda limitada por las herramientas, los permisos y las reglas de parada que proporciona la aplicación.

¿Qué tipos de arquitectura de agentes existen?

Una distinción práctica es separar los flujos predefinidos, los agentes individuales que eligen entre herramientas y los especialistas que colaboran. La elección depende de lo predecible que sea la tarea y de si las distintas responsabilidades necesitan herramientas, políticas o responsables separados. Son patrones de implementación, no una clasificación universal.

El primer paso: dibuja el caso antes de elegir la tecnología

Empieza ya si tienes una cola de soporte con casos recurrentes, acceso a los registros de origen y una persona responsable de las excepciones. Elige un caso representativo y señala el evento de entrada, las lecturas permitidas, las escrituras propuestas, el punto de aprobación y las pruebas necesarias para cerrarlo. Ejecuta el flujo inicial en modo de borrador y revisión; después, utiliza los fallos observados para decidir qué permisos se pueden ampliar de forma responsable.

Espera para habilitar la ejecución autónoma si aún no están resueltas la identidad de la cuenta, la responsabilidad sobre las políticas o las pruebas de finalización. Mientras resuelves esas dependencias, puedes mejorar la recuperación de información y la calidad de los borradores. Si el flujo ya sigue reglas deterministas confiables y no necesita el criterio de un modelo, conserva esa automatización.

El primer entregable debe ser un caso que puedas explicar desde su recepción hasta el resultado, incluido lo que ocurre cuando se deniega la aprobación o se desconoce el resultado de una herramienta.

Para recibir guías prácticas sobre cómo crear y operar sistemas de IA, suscríbete al boletín.