MoEngage exposes 400 private APIs to 10 agents through AgentCore Gateway

MoEngage, a customer engagement platform used by more than 1,350 consumer brands, has described how it made about 400 private internal APIs usable by AI agents. In a post published on the AWS Machine Learning Blog on 29 October 2026 and co-written with two MoEngage engineers, the authors report that the system has run in production for three months and serves 10 internal agents across 7 AWS Regions.

This is a vendor-published account: AWS hosts it and the product is AWS's. It is more useful for its design decisions than as evidence of outcomes.

The problem: hundreds of APIs, no public endpoints

According to the post, the APIs were built by 25 engineering teams and run in private virtual private clouds. MoEngage keeps them regional to meet data residency commitments and does not expose them to the public internet. The authors say the agents needed capabilities that already existed, such as campaign creation, segment queries and delivery stats. Making them reachable safely was the hard part.

MoEngage costed out the obvious route, one Model Context Protocol (MCP) server per team, and rejected it. The authors say more than 20 servers would mean more than 20 deployments to patch and keep compatible, and every team would need MCP expertise unrelated to its product. They set a rule instead: product teams build REST APIs and declare which operations become tools, and the AI Platform team owns the MCP layer.

Three controls the authors say mattered

• Tool visibility is enforced before the catalog is sent. Each agent signs requests with its own IAM role, and a Cedar policy filters the tool list for that agent. The post says this is server-side scoping, not client-side filtering after the full catalog has already been transmitted.
• Identity is out of the model's reach. Tenant, user, role and database context are turned into X-MOE-* headers by the client library. The model does not see them and cannot set them. The authors note that SigV4 signing occupies the Authorization header, so a caller's bearer token has to travel in a separate, MoEngage-prefixed header.
• Context stays small. The post puts a 400-tool catalog at over 20,000 tokens at roughly 50 tokens per tool, sent on every connection. MoEngage's client exposes one meta-tool, search_tools; the gateway's semantic search returns candidates and only those become callable for the turn.

What teams have to do to add a tool

A team adds an x-moe-mcp block to its existing OpenAPI spec. Exposure is opt-in: an endpoint without the block is not a tool, and the authors say cache-warmup routes and migration triggers should not become tools. A continuous integration pipeline validates the block, registers the target with the gateway and applies the Cedar policy, with no ticket to the platform team.

The authors report that reusing API descriptions verbatim led to poor tool selection, so they added separate model-facing description fields.

What it runs and what it claims

The post names three of the 10 agents: a campaign QA agent that validates targeting rules and content before launch, a delivery health agent that watches send rates and bounce patterns, and a segment builder that turns plain-language audience descriptions into segment queries. MoEngage estimates the approach saved about six months of engineering effort and says onboarding a new API now takes hours of spec annotation instead of days of networking and security review.

What the post leaves out

• No cost figures: gateway charges, token spend per task or the platform team's headcount are not given.
• No quality or safety results: nothing on tool-selection accuracy, failed calls, or how often a policy blocked an agent.
• The six-month saving is MoEngage's own estimate against a custom build it did not do, not a measured comparison.
• It is tied to AWS: Cedar policies, VPC Lattice egress and SigV4 are AgentCore features, and the post notes feature availability varies by Region.

For a team starting on agent access to internal systems, the portable parts are the opt-in exposure rule, per-agent permissions that decide what an agent is shown, and identity carried outside the model's control. The managed gateway is one way to get them, not the only one.