Most AI-agent projects start by asking what the model should be able to do. MoEngage’s problem was the opposite. The machinery to create campaigns, query segments, and read delivery stats was already in production. What they did not have was a safe way for an agent to touch it: hundreds of private APIs, none of them on the public internet, and none of them written so a language model could rummage through the lot without making a mess of identity, permissions, or the prompt.
The capability was in production. The hard part was the door.
That account, co-written with MoEngage engineers Nikhil Kumar and Shakir Khan, is on the AWS Machine Learning blog under the title “How MoEngage turned over 400 APIs into agent tools with AgentCore Gateway.” The title and the listing do not even agree on the count. More on that in a moment. The brief is still better than most strategy decks.
What is actually running
MoEngage and AWS report three months in production: seven AWS Regions, about 400 registered operations, and 10 internal agents. Three of those agents are described. They are why a commercial reader should stay for the architecture.
A campaign QA agent checks targeting rules and content before a launch. It can read campaign and segment data. It is not given tools that write.
A delivery health agent watches send rates and bounce patterns across the channels MoEngage already runs: push, email, in-app, SMS, WhatsApp, and RCS.
A segment builder turns a plain-language audience description into a segment query the existing system already understands.
That is AI for sales and lifecycle work in the practical sense. Catch a bad offer before it leaves. Notice when a send is failing. Turn “people who bought twice and went quiet” into a query, not a slide. None of it required a new channel. It required a caller that could use systems of record without becoming a second security team.
The other seven agents are not listed. The account does not say whether “10 internal agents” means 10 services, 10 roles, or 10 logical types.
The APIs were already the product
MoEngage describes itself as an agentic customer engagement platform used by more than 1, 350 consumer brands. Behind the product, it says, sit roughly 400 internal REST APIs, built by 25 engineering teams, running in private networks across seven AWS Regions and kept regionally isolated for data residency. This is not a public developer platform with a key you paste into a demo.
Treat the count as scale, not an audit. The title says “over 400.” AWS’s own listing summary says “roughly 400.” Same story, softer number.
That listing is also the company’s published framing of the design, not a gloss on top of it: roughly 400 private REST APIs, seven Regions, one Amazon Bedrock AgentCore Gateway, tools drawn from OpenAPI specs, permissions scoped with Cedar policies, and managed egress over Amazon VPC Lattice. No MCP server per service. No public endpoints. No dump of a 400-tool catalog into every agent’s context.
The design a lot of companies reach for, once AI agents show up on the roadmap, is one protocol server per team. MoEngage looked at more than 20 of them and walked away. Deployment, patching, keeping protocol versions compatible, and coordinating across servers would have landed on product teams whose job is campaigns and delivery, not protocol stewardship. Every team would have had to learn the Model Context Protocol, the standard agents use to discover and call tools. Agents would have had to coordinate across that fleet just to do work the APIs already did.
Individual engineering teams do not implement MCP. Teams build REST APIs and declare which operations should be tools. The AI Platform team owns the MCP layer end to end. A team’s responsibility ends at a well-described OpenAPI spec.
That split is the organizational idea worth copying even if you never touch this gateway. Product teams keep the contract they already know how to review. A platform team owns protocol, policy, and connectivity.
A hand-built central server would still have been a platform project: generating tools from specs, a policy format, a way to survive renamed operations, failure handling. MoEngage treated that as work that does not make an agent smarter or a customer campaign better. They used AgentCore Gateway instead. MoEngage estimates that choice avoided about six months of engineering: not building and operating those 20-plus servers, and not provisioning a network path per API across seven Regions.
One front door, four rules
Four constraints had to hold at the same time. Each one is a business rule first and a mechanism second.
Nothing on the public internet
The APIs stay off the open internet. Agents are not given a public URL and told to behave.
MoEngage says inbound access reaches the gateway only through a private address inside their own cloud network, with private DNS. AWS’s listing says there are no public endpoints. Outbound calls to the internal APIs use the gateway’s managed egress over Amazon VPC Lattice, so they did not stand up a NAT gateway, reverse proxy, or VPN tunnel for every integration in every Region.
The model does not pick the customer
The model never chooses which customer it is acting for. The calling service stamps that on the request, where the model cannot edit it.
These APIs need tenant, user, role, and database context. MoEngage turns a small identity object into headers prefixed X-MOE-. Those values are not arguments on the tool the model sees. A prompt cannot flip the tenant, because the tenant is not on the model’s side of the request.
Internal calls are signed with SigV4, the AWS signature those services already produce from their IAM roles. That signature occupies the Authorization header. A bearer token forwarded from a caller cannot sit in the same place, so MoEngage puts it in a separate header with its own prefix. Listing and searching tools carry no tenant identity. Only the tool call does.
That signing choice is MoEngage’s, for internal agents that already have cloud roles. It is not “how AgentCore always authenticates.” AWS documents the gateway’s security features around OAuth, with inbound and outbound authentication. MoEngage also runs a separate public MCP server for human sessions from Claude and other clients, and that door uses OIDC login tokens. Two doors, two kinds of caller. The account does not say the public server reaches the same APIs. Do not assume it does.
Cut the catalog before it is sent
An agent holding 400 tool definitions is a new hire who was emailed the entire wiki and told to be useful before standup. Cut the list on the server, before it crosses the wire.
MoEngage’s sketch: roughly 50 tokens of JSON schema per tool, so a full tool list is over 20, 000 tokens on every connection. Filtering after the list arrives does not fix that. In their account, client-side filters, including ones in Google’s ADK or the MCP SDK, run too late, and a filter in the client is not an authorization boundary. An agent that is not supposed to see write operations should not receive them in the first place.
Cedar, a policy language, is how they say they enforce that. A campaign QA agent, identified along the lines of campaign-qa-bot-v1, can be allowed a read group and refused a write group. In their telling, the bot’s tool list never includes write tools. There is nothing left for the client to hide, because the tools were not sent. AWS’s summary confirms Cedar was used to scope permissions. The precise “filter before the list is serialized” step is MoEngage’s description of their setup, not a checkbox to assume on every gateway.
Do not rebuild the network for every API
Joining the agent layer should not be a new network project for every squad. Register the OpenAPI spec the team already maintains. The gateway turns the operations they opted into MCP tools and routes calls to the private service behind them. Generated names follow a Target___operationId pattern. CampaignsAPI___searchCampaigns is the example they give.
One shorthand is now too small. It is easy to call AgentCore Gateway a managed MCP server. AWS’s current documentation describes a wider product: a managed AI gateway, a single entry point that can turn OpenAPI, Smithy, and Lambda into tools, front other agents and HTTP services, and route inference across model providers. MoEngage used the OpenAPI-to-tool path. That is a use of the gateway, not the whole product.
Search first, then call
MoEngage’s client library shows the model one meta-tool, search_tools. The model describes what it is trying to do. Search returns a handful of candidates. Only those are callable for the rest of the turn. New agents are meant to start with zero hardcoded tool names: describe intent, receive candidates, call what they find.
Walk the segment builder that way. Someone asks for people who bought twice and went quiet. The agent does not open holding every definition in the catalog. It tells search_tools what it is trying to do, gets a short list back, and calls the operation that turns audience language into a segment query. Tenant, user, role, and database context are already on the request. The model never passed a customer identifier it could mistype, or be talked into changing.
Under that sits a gateway feature, x_amz_bedrock_agentcore_search. The agent describes the task instead of naming an identifier, which matters when operations get renamed. AWS documents the feature for large catalogs and says semantic selection can let agents work with thousands of tools while keeping prompts smaller. That “thousands” is an AWS product claim, not a MoEngage measurement.
Two setup facts matter before anyone plans a rollout. Search has to be enabled when the gateway is created. It is not automatic. And AWS documents it only in a listed set of Regions, which changes. Confirm the current list in the Amazon Bedrock AgentCore documentation. MoEngage has not named its seven Regions, so search sitting beside every API they run is an assumption, not a fact in the account.
Tool text is a separate craft. MoEngage found that reusing API descriptions verbatim led to poor tool selection. “Returns a paginated list” tells a developer what the endpoint does. It does not tell a model when to call it, or what to pass. Their OpenAPI extension, x-moe-mcp, is the opt-in. It carries flags for internal and external exposure, a description written for the model, and parameter overrides. If the block is absent, the endpoint is not a tool, and continuous integration does not nag anyone to expose it. Cache-warmup routes and migration triggers are the examples they give of things that should stay off the menu. A helpful agent that can trigger a migration is not helpful.
When a team does opt in, MoEngage says CI validates the block, registers the target, and applies the Cedar policy, with no ticket to the AI Platform team. They report onboarding dropping from days of networking and security review to hours of spec annotation.
Read that next to the other rule, or the two will collide. Adding the operation is a spec change. Restricting who can see or call it is a policy change. CI applying a policy at registration is the automation that removes the ticket. It does not make the API author the authorization author, and it does not mean opting in invents the permit. The account does not say who writes those Cedar rules, or what a loose one does.
The agents themselves run on ordinary compute, EC2 or a container, and call the gateway through an MCP client. MoEngage names the official MCP SDK, LangChain, Google ADK, and its own runner. Client lists differ by vendor. Match the list to the stack you actually run.
Before you copy the business case
The figures that travel furthest are the ones with the least measurement behind them. The six-month savings figure is MoEngage’s estimate for a specific alternative: not building and operating more than 20 MCP servers, and not provisioning per-API networking across seven Regions. No baseline headcount, ticket volume, or before-and-after study is published with it. AWS’s product documentation, separately, says the gateway can eliminate weeks of custom gateway development, infrastructure, and security work. Different scope. Different claim.
Same caution on the rest. No error rates, latency, measured token use, tool-selection accuracy, or security findings are in the account. Circuit breakers are named as custom work MoEngage avoided building. Public gateway docs describe serverless scaling, observability, and auditing. They do not say the service provides circuit breakers. Regional isolation for data residency is asserted, not explained. There is no published description of how an agent in one Region is kept off another Region’s APIs. A policy that can hide write tools can also hide the read tools an agent needs.
Questions worth asking
-
Did MoEngage build hundreds of new capabilities for its AI agents?
No. Campaign, segment, and delivery operations were already production APIs. The project was reach, identity, and who is allowed to see which tool.
-
Why not give each engineering team its own MCP server?
MoEngage judged that more than 20 team-owned servers would pile deployment, patching, protocol drift, and cross-server coordination onto teams that should ship REST APIs, not operate a protocol.
-
How does a catalog this size stay out of the prompt?
As MoEngage describes it, Cedar policies on the server keep an agent from being sent tools it should not have, and a single search_tools meta-tool returns a few candidates instead of the whole catalog. The “filtered before the list is sent” step is their account of how they applied Cedar, not a generic product guarantee, and the token sketch (about 50 tokens of schema per tool, over 20, 000 for a full list) is an approximation.
-
Can the model decide which customer it is acting for?
No. The calling service stamps tenant, user, role, and database context onto the request as headers, and those fields are not tool arguments the model can set. Discovery carries no tenant identity. Only the tool call does.
-
What does a product team actually change to add a tool?
An x-moe-mcp block on an OpenAPI operation they already document, including a description written for a model rather than a developer. MoEngage says CI then registers the target and applies policy without a platform ticket. Who may see the tool remains a policy change, and endpoints without the block stay ordinary APIs.
-
How much engineering time did the gateway save?
MoEngage estimates about six months, from not building and operating more than 20 MCP servers and not provisioning per-API networking across seven Regions. AWS’s separate product copy talks about eliminating weeks of custom gateway work (a different scope), and neither figure comes with a published baseline.
-
Is AgentCore Gateway only a converter from OpenAPI to MCP?
No. That is the path MoEngage used. AWS documents a wider gateway (OpenAPI, Smithy, and Lambda tools, plus other agents, HTTP passthrough, and model routing), and semantic search is optional at creation time and limited to listed Regions.
-
What should a sales or marketing leader copy?
Copy the jobs that sit on workflows you already trust: QA before a send, health during a send, audience language turned into a segment query. Do not assume the savings, the three-month runtime, or the security outcome transfer. No latency, accuracy, or incident data was published, and internal service agents are a different door from a public, human login.
The pattern underneath the product
The popular story about AI agents is that the model needs more tools, and every team should ship some. MoEngage’s experience points the other way. Most endpoints should not be tools. The ones that should need a description written for a model, a policy written by someone other than the model, and a network path that does not grow a new tunnel every time a squad has an idea.
If you are staffing AI automation, staff the platform boundary, not a protocol project in every squad. If you are assessing risk, ask who injects identity, who never receives write tools, and which Regions actually have the search feature you are counting on. A gateway can take a class of platform work off the roadmap. It does not remove the need to know what you refused to expose.