Las aplicaciones de inteligencia artificial basadas en agentes requieren un diseño diferente al de las interfaces web tradicionales, no necesariamente por un protocolo nuevo, sino porque el propio patrón de tráfico es distinto. Una sola conversación puede extenderse durante decenas de solicitudes independientes, mientras el agente continúa trabajando a velocidad automática y sin los periodos de espera humanos que alivian la presión sobre la infraestructura.
El artículo, publicado en The New Stack como contenido patrocinado por Oracle, propone reutilizar principios antiguos de los microservicios para construir API compatibles con OpenAI y capaces de escalar, utilizando Oracle AI Database Free como base para el modelo de prueba de concepto.
¿Por qué el tráfico de los agentes difiere del de las aplicaciones web?
El navegador puede mantener la sesión a través de un único servidor gracias a la afinidad de enrutamiento y a los periodos en los que el usuario piensa. En cambio, un agente puede ejecutar 40 ciclos consecutivos, y cada ciclo llega como una solicitud HTTP independiente cuyo enrutamiento al mismo servidor no está garantizado por el protocolo. Si el historial de la conversación permanece en la memoria de un proceso local, la siguiente solicitud puede perder el contexto en cuanto se transfiera a otra instancia del servicio.
Además, las llamadas a herramientas pueden ramificarse de forma imprevista: una sola solicitud puede no invocar ningún servicio adicional o generar varias llamadas, incluidas búsquedas vectoriales que pueden tardar 400 milisegundos. Los agentes aumentan aún más la presión mediante sus propias políticas de reintento, mientras que el tráfico llega en forma de ráfagas continuas determinadas más por los límites de concurrencia y el hardware que por el comportamiento del usuario.
El problema silencioso del diseño inicial
El autor presenta un prototipo que conserva el historial de la conversación en un diccionario dentro del proceso, utiliza un único conjunto para controlar la concurrencia y ejecuta las llamadas a herramientas dentro de la misma ruta de la solicitud. Este diseño funciona en las pruebas, pero en la práctica depende de que todos los turnos de la conversación lleguen al mismo dispositivo.
Al distribuir 200 conversaciones, cada una con cuatro turnos, alternativamente entre varias instancias, los servidores pueden seguir devolviendo códigos HTTP 200, mientras el modelo responde sin el historial correcto de la conversación. Por eso, el fallo no necesariamente aparece como una avería técnica evidente, sino como un comportamiento incorrecto desde la perspectiva del usuario.
Tres principios para abordar el problema
- Sacar el estado del proceso: el estado de la conversación y el registro de llamadas a herramientas se almacenan en un almacén compartido, de modo que cualquier instancia pueda atender cualquier turno de la conversación.
- Aislamiento o barreras: las distintas rutas y dependencias, como la finalización de la conversación y la ejecución de herramientas, reciben límites de concurrencia y tiempos de espera independientes para impedir que el fallo de una de ellas agote todo el sistema.
- Endpoints inteligentes y canalizaciones sencillas: el protocolo compatible con OpenAI permanece como una capa de transporte estable, mientras que la lógica de enrutamiento, la gestión del presupuesto y la memoria, y las políticas de llamada a herramientas se sitúan por encima.
¿Qué cambia en la práctica?
El modelo de prueba de concepto divide el sistema en una puerta de enlace que se comunica mediante el protocolo de OpenAI y no conserva el estado, un servicio de memoria que posee el historial de la conversación y la auditoría, un servicio de herramientas independiente con límites de concurrencia y tiempos de espera propios, y Oracle AI Database Free como almacén compartido. El diseño utiliza señales de control independientes, como 24 ranuras para la concurrencia de las conversaciones y 8 para las llamadas a herramientas.
Esta división permite escalar horizontalmente sin depender del sistema de archivos local ni de la afinidad del enrutamiento de las solicitudes. Asimismo, el cliente oficial de OpenAI puede utilizar la interfaz sin modificar el SDK, siempre que el protocolo sea compatible.
La conclusión editorial es que la escalabilidad de los agentes de inteligencia artificial no se resuelve únicamente aumentando el número de instancias. La verdadera prueba consiste en conservar el estado, controlar las dependencias lentas y evitar que los reintentos o las llamadas a herramientas conviertan las ráfagas de agentes en un fallo en cadena. Dado que se trata de contenido patrocinado por Oracle, el artículo sigue siendo una presentación de un enfoque arquitectónico y un modelo de prueba de concepto, no una comparación independiente entre bases de datos ni una garantía de un rendimiento determinado en todos los entornos.