En la actualidad, la interacción con modelos de inteligencia artificial de última generación suele realizarse mediante protocolos estructurados, muchas veces diseñados por los propios proveedores de estos modelos. Empresas como OpenAI y Anthropic ofrecen APIs que permiten comunicarse con sus sistemas de inferencia de manera sencilla y uniforme.
Una estrategia común es utilizar una API compatible con OpenAI que pueda gestionar agentes conversacionales capaces de mantener diálogos de múltiples turnos, donde la comunicación con el agente se mantiene a través de la misma interfaz en cada intercambio.
Estos sistemas están diseñados para escalar de forma eficiente según la demanda o la proliferación de subagentes, de modo que los ingenieros puedan adaptar la infraestructura sin que los usuarios perciban interrupciones. Por ejemplo, un sistema con una única réplica puede ampliarse a tres réplicas distribuidas detrás de un balanceador de carga, manteniendo intacto el contexto de conversación y los turnos anteriores. 
«Los principios de microservicios, que dejaron de comentarse hace cinco años, resultan ser precisamente lo que necesita el tráfico generado por agentes.»
Es fundamental entender qué ocurre cuando se producen picos en el tráfico generado por agentes de IA.
Por qué el tráfico de agentes difiere del tráfico web convencional
Una diferencia crucial radica en la forma en que la carga se distribuye, lo que dificulta la absorción de esta carga por parte de diseños con estado tradicional.
Estas son las cuatro principales características que diferencian a un cliente agente de un navegador web:
- Las conversaciones son largas y mantienen estado, pero las solicitudes individuales no. Por ejemplo, en un agente que mantiene una conversación de 40 turnos, se generan 40 solicitudes HTTP independientes sin un vínculo garantizado con un servidor específico. Cada llamada a una herramienta es independiente a nivel HTTP, lo que obliga a la aplicación a identificar a qué conversación pertenece cada solicitud y dónde se almacena su estado.
- Las llamadas a herramientas pueden expandirse de manera impredecible. Una sola solicitud de chat puede desencadenar desde ninguna hasta varias llamadas a herramientas diferentes, algunas de las cuales pueden tener tiempos de respuesta variados, como una consulta a un índice vectorial que dura 400 milisegundos.
- Los agentes suelen reintentar agresivamente. Los agentes de IA suelen estar envueltos en un mecanismo de control propio que gestiona errores y políticas de reintento, enviando múltiples solicitudes en rápida sucesión cuando hay errores o límites de tiempo agotados. Esto puede sobrecargar ciertos componentes si no se controla adecuadamente.
- La carga es abrupta y impulsada por máquinas. No hay tiempo de espera humano entre turnos, lo que genera ráfagas continuas de trabajo limitadas principalmente por el hardware y la concurrencia que admite el sistema.
Mientras que los navegadores mantienen la sesión en un servidor gracias a la afinidad y al tiempo que el usuario tarda en pensar, el agente puede enviar muchas solicitudes rápidamente a diferentes réplicas, perdiendo así el contexto necesario si la infraestructura no está diseñada para manejar este tipo de tráfico estatal distribuido.
El error común en la primera implementación típica
Un ejemplo habitual es implementar un endpoint API que almacena el estado de las sesiones localmente en un diccionario en memoria y limita la concurrencia globalmente mediante un semáforo. Aunque esta aproximación funcionará correctamente en un entorno monolítico con una sola máquina, falla al escalar a múltiples instancias.
En una prueba con 200 conversaciones de cuatro turnos cada una, distribuidas en varias réplicas, se evidenció que en un despliegue monolítico con tres máquinas el 75 % de los turnos perdía el contexto, frente al 0 % en un único nodo o en arquitectura descompuesta. Esto se debe a que, al escalar sin persistencia centralizada, las solicitudes se distribuyen aleatoriamente y el contexto almacenado localmente no está disponible para todos los nodos.
«El fallo es silencioso: el modelo responde, pero puede hacerlo sin el contexto correcto porque la solicitud llega a un nodo sin la información previa.»
Por tanto, un sistema que responde con éxito código HTTP 200 puede, en realidad, estar funcionando incorrectamente desde la perspectiva del usuario.
Volviendo a los principios fundamentales
La solución no es innovadora sino que reaplica principios clásicos de microservicios descritos por Lewis y Fowler en 2014, combinados con el patrón de compartimentación (bulkhead) propuesto por Michael Nygard en Release It!.
Los fundamentos clave son:
- Desacoplar el estado: Sacar el estado de la conversación del proceso y alojarlo en un almacén compartido. Esto permite que cualquier réplica pueda gestionar cualquier turno sin perder contexto, pues toda la información se recupera centralizadamente sin enviar largos historiales en cada petición.
- Compartimentación o aislamientos: Separar los diferentes componentes para impedir que los fallos en uno afecten a los demás. En este caso, aislar por dependencia evita que problemas en una herramienta afecten la ruta principal de chat.
- Endpoints inteligentes y canales simples: Mantener simples los protocolos utilizados, asignando la complejidad al backend que enruta, controla memoria y llama a herramientas, para facilitar compatibilidad y facilidad de integración.
Prueba de concepto: arquitectura basada en cuatro servicios y un protocolo común
La solución descompone la pila para aislar dominios de fallo manteniendo un único protocolo:
- Gateway: Administra el protocolo OpenAI, sin almacenar estado, escalable horizontalmente.
- Memoria: Gestiona el estado de la conversación y el historial de llamadas a herramientas.
- Herramientas: Ejecuta herramientas en procesos aislados, con gestión propia de concurrencia y tiempos de espera.
- Oracle AI Database Free: Actúa como sustrato común para almacenar y coordinar datos.
Esta arquitectura permite evolucionar cada componente de forma independiente y ajustar parámetros específicos como concurrencia y timeouts segmentados por servicio.
La concurrencia se regula mediante semáforos que controlan el acceso a los recursos comunes.
Dado que no se modifica el protocolo de acceso, el SDK oficial de OpenAI puede interactuar directamente con esta API compatible sin necesidad de cambios, incluso cuando las solicitudes se sirven desde distintas réplicas manteniendo coherencia gracias al almacenamiento centralizado.
¿Merece la pena implementar compartimentación (bulkheads)?
Separar las rutas de llamadas a herramientas de las de chat estándar evita que solicitudes lentas saturen la capacidad disponible para otras, mejorando calidad y mantenibilidad.
En pruebas comparativas con 32 slots de admisión por réplica, la arquitectura monolítica consumía todos los recursos en un único pool compartido, ocasionando esperas significativas para usuarios que demandaban solo chat básico debido a la carga pesada de herramientas. El diseño con compartimentación aislaba 24 slots para chat y 8 para herramientas, manteniendo la experiencia fluida para las interacciones regulares.
«Sin compartimentación, un usuario haciendo una pregunta básica al chat puede verse retrasado por llamadas lentas a herramientas porque todas las peticiones compiten por el mismo recurso.»
El papel clave de Oracle AI Database Free
Contrariamente al dogma habitual de «una base de datos por servicio» en microservicios, donde se evita compartir esquema para reducir el acoplamiento, en aplicaciones de agentes de IA esto puede ser contraproducente debido a la necesidad de transacciones coordinadas entre distintos tipos de datos.
Por ejemplo, en un solo turno del agente se deben escribir simultáneamente:
- El estado actualizado de la conversación.
- El registro y orden de las llamadas a herramientas.
- Los hechos extraídos para memoria semántica, episódica y de flujo de trabajo.
- La entrada en el libro de idempotencia para evitar re-ejecuciones pagadas en reintentos.
Dividir estas operaciones en bases dispares (Postgres, vectorial, Redis) genera complejidades de consistencia que la aplicación debe resolver. Una base de datos unificada que combina datos relacionales, JSON y vectores y soporte para transacciones atómicas facilita enormemente la garantía de integridad y simplifica el desarrollo.
Oracle AI Database Free permitió consolidar estos datos en una única transacción que respalda el modelo de agente escalable y tolerante a fallos. Además, su capacidad de búsqueda vectorial híbrida optimiza consultas semánticas complejas dentro de la propia base sin necesidad de enlaces externos engorrosos.
Para coordinar concurrencias en réplicas múltiples, se usan mecanismos como SELECT ... FOR UPDATE junto con versiones optimistas para serializar actualizaciones, evitando así sobrescrituras conflictivas del estado.
El planteamiento contraintuitivo: descomponer cálculo, converger datos
La tendencia general es descomponer microservicios en función de capacidades computacionales, pero al hacerlo sin considerar la convergencia de datos asociados al agente se originan problemas de consistencia y rendimiento.
«La división eficaz es asimétrica: descomponer la computación, pero unificar los datos.»
Los principios planteados en 2014 siguen vigentes, pero deben adaptarse a las demandas específicas que plantea la nueva generación de agentes de inteligencia artificial.
Para aquellos interesados en explorar esta arquitectura, Oracle pone a disposición Oracle AI Database Free y el paquete Python Oracle AI Agent Memory. Además, existen recursos adicionales en el Oracle AI Developer Hub que facilitan un rápido inicio en la construcción de APIs con estado persistente para agentes AI.
