Arquitectura de integración de herramientas para agentes

Problema

El agente podía razonar sobre una tarea. No podía invocar con fiabilidad capacidades que ya existían en otros sistemas. Los equipos compensaban con un mosaico de herramientas de datos de RR. HH. y operaciones, cada una con su propio modelo de autenticación, contrato y factura. Las automatizaciones eran frágiles. Las consultas se duplicaban. La factura crecía mientras el agente seguía aislado del trabajo que debía hacer.

Restricciones

Varios entornos de producción, cada uno con su propio límite de seguridad. Los servicios existentes tenían que seguir siendo la fuente de verdad; una reescritura quedaba fuera de alcance. La presión de coste exigía que cada integración se justificara frente a la herramienta que iba a sustituir. La capa tenía que ser general: añadir un sistema debía parecer registrar una herramienta, no abrir un programa de trabajo nuevo.

Arquitectura

Una capa generalizada de integración de herramientas, según el patrón del Model Context Protocol, se situaba entre el runtime interno del agente y los servicios externos. Las skills describían lo que el agente podía hacer. Las tools describían cómo esas skills se mapeaban a APIs existentes. Una pasarela de API mediaba la identidad, los límites de tasa y el aislamiento de entornos. Los pipelines de Kafka movían los datos de cambio hacia una ruta de sincronización. El CI/CD automatizado promocionaba solo la configuración revisada y acotada al entorno. La infraestructura distribuida sustituyó el patrón anterior de una herramienta por equipo.

Rol

Como ingeniero principal definí la taxonomía de skills y tools, los contratos de integración MCP y la forma de las pasarelas y los pipelines. Me encargué de la ruta de promoción que evitó que la sincronización entre entornos fuera un proceso manual, y diseñé la infraestructura distribuida que permitió al equipo retirar las herramientas de datos fragmentadas.

Resultados

• Reducción del 35–45 % del coste operativo al retirar herramientas fragmentadas de datos de RR. HH. y operaciones.
• Una sola superficie de integración para los sistemas posteriores, de modo que las capacidades nuevas no exigieran un stack de proveedor nuevo.
• Promoción acotada al entorno: la configuración avanzaba por CI/CD en lugar de copiarse entre producciones.

Stack