Una plataforma compartida para agentes de IA empresariales

El objetivo nunca fue poner un chatbot en producción. Era lograr que muchos agentes distintos pudieran desplegarse sobre los sistemas empresariales existentes sin inventar un nuevo modelo de seguridad, integración y operación cada vez. Proveedores de modelos, APIs empresariales, credenciales, fuentes de retrieval, interacciones en streaming, fallas, requisitos de auditoría y observabilidad tenían que comportarse como capacidades de plataforma y no como código propio de cada proyecto.

Los agentes debían trabajar con los sistemas que ya existen: APIs modernas, contratos de integración antiguos, datos transaccionales, conocimiento documental y servicios que nunca fueron diseñados pensando en que quien llamara sería una IA.

La plataforma además tenía que atender a varias organizaciones y cargas de trabajo sin permitir que las herramientas, credenciales, datos o contexto de ejecución de un agente se filtraran hacia otro. Esas garantías debían venir de la arquitectura de la plataforma, y no de que cada equipo de desarrollo recordara las mismas reglas.

Un runtime de agentes agnóstico al proveedor opera detrás de capas de gateway gobernadas para el acceso a modelos y herramientas. Autenticación, enrutamiento de proveedores, límites por consumidor, rate limiting, políticas de solicitud y auditoría son responsabilidades de la plataforma, no código que cada agente reimplementa.

Las APIs empresariales se convierten en capacidades de agente a través de contratos legibles por máquina. Un catálogo y una capa de políticas determinan qué herramientas existen y cuáles puede invocar cada agente, mientras las credenciales permanecen en almacenes de secretos administrados y se resuelven solo cuando la capacidad se ejecuta.

El retrieval y el acceso al conocimiento se tratan como servicios de plataforma y no como plomería específica de cada prompt. La observabilidad sigue la ejecución a través de las fronteras del agente, el modelo, el retrieval y las herramientas, para que un operador pueda entender una ejecución de principio a fin. Las cargas corren sobre orquestación de contenedores con infraestructura gestionada como código.

Lidero la arquitectura y la dirección técnica de la iniciativa. Defino los límites de la plataforma, la estrategia de runtime y gateways, el modelo de herramientas, el aislamiento de tenants y credenciales, la integración de retrieval, el enfoque de observabilidad y los estándares que un agente debe cumplir antes de convertirse en carga de producción. También guío a los equipos que construyen sobre esa base.

1. Separar el comportamiento del agente de la infraestructura del proveedor de modelos

   Por qué

   Un agente debe expresar qué necesita de un modelo, no incrustar los supuestos de un proveedor a lo largo de toda la aplicación. Mantener ese límite explícito permite que la elección y el enrutamiento de modelos evolucionen sin reescribir cada agente.

   Concesión

   La abstracción pasa a ser responsabilidad de la plataforma, y las funciones específicas de cada proveedor hay que adoptarlas de forma intencional en lugar de recibirlas automáticamente.

2. Generar las herramientas de los agentes a partir de contratos de API

   Por qué

   Los sistemas empresariales pueden exponer cientos de operaciones. Escribir y mantener una herramienta a mano para cada una no escala, y las descripciones manuales terminan desfasadas de la API. Hacer del contrato la fuente de verdad convierte la exposición de herramientas en un proceso de integración gobernado.

   Concesión

   La calidad del contrato se vuelve crítica. Los sistemas más antiguos suelen necesitar que sus interfaces se describan o normalicen antes de poder ser buenas herramientas de agente.

3. Hacer de la identidad, las credenciales y el aislamiento de tenants responsabilidades de la plataforma

   Por qué

   Un agente debe recibir permiso para realizar una acción, no la credencial subyacente que esa acción requiere. Centralizar la identidad y la resolución de credenciales reduce el radio de impacto tanto de los errores de implementación como del comportamiento autónomo.

   Concesión

   La plataforma asume más complejidad de seguridad y se vuelve responsable de mantener políticas correctas en cada camino de ejecución.

4. Instrumentar el camino completo del agente

   Por qué

   La ejecución de un agente atraviesa varios pasos no determinísticos. Un log de aplicación convencional no explica por qué una ejecución eligió cierta herramienta, dónde se acumuló la latencia o qué dependencia causó la falla. La telemetría de extremo a extremo vuelve operables esas preguntas.

   Concesión

   La telemetría detallada introduce sus propias decisiones de almacenamiento, costo, privacidad y retención.

La plataforma convierte la entrega de agentes, antes una serie de experimentos aislados, en una capacidad de ingeniería reutilizable. Los equipos pueden concentrarse en el comportamiento del dominio mientras la capa compartida provee acceso gobernado a modelos, herramientas empresariales, retrieval, límites de identidad, telemetría y patrones de despliegue. El resultado más importante es arquitectónico: sumar otro agente ya no significa inventar su modelo de producción desde cero.

Esta descripción pública omite intencionalmente los sistemas involucrados, la configuración de proveedores de modelos, los detalles de tenants, el catálogo de herramientas, la topología de infraestructura y la configuración operativa.

• Kubernetes
• Apache APISIX
• Terraform
• OpenTelemetry
• Oracle Database
• PostgreSQL
• Redis
• Node.js