MoEngage convirtió operaciones de sus API internas en herramientas para agentes con Amazon Bedrock AgentCore Gateway, según el caso técnico que AWS elaboró junto con la empresa. El diseño descrito parte de especificaciones OpenAPI y combina controles de acceso con una conexión privada a los servicios internos.
La idea práctica es reutilizar API que ya existen y decidir por separado qué herramientas puede ver y llamar cada agente.
De una especificación OpenAPI a una herramienta
Los equipos de MoEngage anotan sus especificaciones OpenAPI existentes con x-moe-mcp. OpenAPI describe las operaciones de una API REST; AgentCore Gateway registra esas especificaciones y genera a partir de ellas herramientas compatibles con el protocolo Model Context Protocol (MCP), que permite descubrir y llamar herramientas desde agentes.
Un proceso de integración continua (CI) valida la anotación, registra el destino en el gateway y aplica la política Cedar correspondiente. La exposición es voluntaria: el equipo añade la anotación cuando quiere habilitar una API para este uso. La plataforma de IA de MoEngage gestiona las capas de protocolo, políticas y conectividad.
El caso describe una infraestructura de unas 400 API REST internas, creadas por 25 equipos de ingeniería en siete regiones de AWS. El gateway sirve alrededor de 400 operaciones registradas a 10 agentes internos. El número de API y el de operaciones registradas se refieren a cosas distintas.
Qué puede ver y llamar cada agente
Cada agente tiene su propio rol de AWS Identity and Access Management (IAM). Las políticas escritas en Cedar se aplican en el servidor y determinan qué herramientas puede ver y llamar ese agente. Por ejemplo, la política de control de campañas que describe el caso permite operaciones de lectura y bloquea las acciones de escritura; las herramientas no autorizadas se omiten de la lista que recibe el agente.
El contexto del espacio de cliente, el usuario, el rol y la base de datos viaja en cabeceras X-MOE-*, no como argumentos que el modelo pueda modificar. Así, el agente solicita herramientas y operaciones, mientras la identidad y las reglas de acceso se gestionan en capas distintas.
Para el gateway interno, los servicios de agente firman las solicitudes con SigV4 usando sus roles IAM. MoEngage emplea otra configuración para su servicio MCP público: el caso la describe con tokens JWT de OIDC sobre AgentCore Runtime. Son dos superficies de acceso diferentes.
La ruta hasta las API privadas
En la arquitectura descrita, los servicios de agente se conectan por HTTPS a un punto de enlace de interfaz de una nube privada virtual (VPC), con DNS privado. AgentCore Gateway usa salida gestionada a través de Amazon VPC Lattice para llegar a las API internas. La ruta interna descrita no pasa por un punto de enlace público.
La separación permite entender el diseño sin confundir autenticación con conectividad: SigV4 identifica las solicitudes del gateway interno, mientras que el punto de enlace de VPC y VPC Lattice forman el recorrido de red hacia los servicios internos. Cedar decide qué herramientas puede usar cada agente.
Cómo encuentran herramientas los agentes
En vez de cargar todo el catálogo de herramientas en el contexto del modelo, la biblioteca cliente de MoEngage ofrece una metaherramienta llamada search_tools. El agente describe la tarea y la búsqueda semántica devuelve herramientas candidatas relacionadas.
El caso estima que un esquema JSON puede ocupar unos 50 tokens por herramienta y que un catálogo de 400 herramientas superaría los 20.000 tokens. La búsqueda selectiva está pensada para que el agente reciba candidatas pertinentes, en lugar de todo el catálogo de una vez.
La biblioteca también ofrece un modo de complemento para LangChain, Google ADK y marcos compatibles con MCP, además de un modo separado para ejecutar agentes. Entre los usos internos descritos figuran revisar campañas antes del lanzamiento, vigilar el estado de entrega y crear segmentos mediante lenguaje natural.
El esfuerzo que MoEngage atribuye al diseño
MoEngage estima que el enfoque ahorró alrededor de seis meses de trabajo de ingeniería de plataforma. La empresa también describe la incorporación de una nueva API como un proceso de horas, frente a días de preparación de red y revisión de seguridad. Esa comparación se refiere a la incorporación de API, no al tiempo que tarda una solicitud en responder.
El caso atribuye el cambio a registrar especificaciones existentes y aplicar en el proceso de integración las políticas y la conectividad necesarias, en lugar de preparar servidores MCP y redes para cada API por separado.
