Gateway, Tools, and the M by N Problem

One agent calling one internal API is an afternoon. The trouble arrives with scale in two dimensions at once.

Every agent that needs a capability needs an integration to it: the call, the auth, the schema, the error handling, the retry policy, and a description the model can use to decide when to call it. Do that per agent and per tool, and the work is the product of the two counts, not the sum. AWS names this directly in its Gateway announcement as the M by N integration problem.

Key idea: a gateway converts a multiplication into an addition. Each tool is adapted once, each agent connects once, and the integration count grows with the sum rather than the product. At 50 agents and 200 tools that is the difference between 10,000 pieces of glue and 250.

AgentCore Gateway's job is to take things you already have and make them look like MCP tools, which is the interface agents already know how to consume.

AWS documents the supported inputs precisely:

• REST APIs described by an OpenAPI specification, or by a Smithy model.
• AWS Lambda functions, with a defined schema.
• Existing MCP servers, connected through rather than rebuilt.

The phrase in the announcement is zero-code MCP tool creation from APIs and Lambda functions. The mechanism underneath is unglamorous and exactly right: your OpenAPI document already declares the operations, their parameters and their types, which is most of what a tool definition needs, so the conversion is a transformation of a description you have already written rather than new code.

In practice: this reframes a stalled question many teams face. "How do we expose our systems to agents?" often becomes "is our OpenAPI spec accurate and are its descriptions written for a reader who is not us?", which is a documentation problem with a known fix, not an integration project.

AWS also lists connectors for common SaaS systems including Salesforce, Zoom, Jira and Slack, so the same endpoint can front internal and third-party capabilities.

Solving M by N creates a second problem immediately, and it is a model problem rather than an infrastructure one.

Gateway's answer is to stop offering everything. AWS provides semantic tool selection through a built-in tool named x_amz_bedrock_agentcore_search: the agent describes what it needs in natural language, and search returns the small set of relevant tools rather than the catalogue.

Key idea: this is retrieval applied to tools instead of documents, and it is the same insight as RAG. Do not put the corpus in the context; put a way to find the relevant part of it. Once tool counts pass a few dozen, tool selection stops being a prompt-engineering problem and becomes a retrieval problem.

A gateway sits between callers and systems, so it faces an authentication question on each side, and conflating them is a common design error.

Inbound is: may this caller use this gateway and these tools? AWS implements OAuth-based authorization following the MCP specification, working with Amazon Cognito, Okta, Auth0 or custom providers, and supporting both the authorization code flow, three-legged OAuth, and the client credentials flow, two-legged OAuth.

Outbound is: what credential does the gateway present to the target system? AWS documents IAM role-based authorization for Lambda and Smithy targets, and for OpenAPI targets either an API key, in a header or query parameter, or OAuth client credentials, with the credentials managed through AgentCore Identity's resource credential provider.

The distinction that matters for design: three-legged flows carry a specific end user's authorisation, so the downstream system can enforce that user's permissions. Two-legged flows carry the application's identity, so the downstream system sees one service account and cannot distinguish users. Choosing the second for convenience is how an agent quietly becomes a way for any user to reach data they were never entitled to.

Prompting a model not to do something is a request, not a control. Because a model's tool choice is probabilistic, any guarantee about what an agent will never do has to live outside the model.

AgentCore Policy provides that layer. AWS describes it as deterministic control that keeps agents within defined boundaries and business rules, with rules authored in natural language or in Cedar, AWS's open-source policy language, and integrated with Gateway to intercept every tool call before execution. It can constrain which tools an agent may access, what actions it may perform, and under what conditions.

The placement is what makes it meaningful:

• Enforcement is at the call site, before execution, not in the prompt where the model may ignore it.
• Rules are declarative and reviewable as artefacts, so a security reviewer reads policy rather than inferring behaviour from prompts.
• The guarantee holds regardless of how the model was persuaded, which is the only defence that survives prompt injection.

Gotcha: an agent that reads untrusted content, a web page, an email, a support ticket, is an agent that may act on instructions written by whoever produced that content. No prompt hardening closes that hole. What closes it is the boundary the model cannot argue with: a policy that says this agent may never call the refund tool above a threshold, evaluated outside the model, every time.

Beyond your own systems, AgentCore ships two capabilities that are hard to provide safely yourself, and the reason is the same in both cases: they execute something the model produced.

Code Interpreter is an isolated sandbox where the agent writes and runs code, supporting Python, JavaScript and TypeScript. It is the standard fix for a real limitation: a language model doing arithmetic or data manipulation by prediction is unreliable, while a model that writes six lines of code and runs them gets an exact answer. Data analysis, format conversion and calculation move from a generation problem to an execution one.

Browser is a managed cloud browser runtime, letting agents navigate sites, fill forms and extract information, and AWS lists it as working with automation frameworks including Playwright and BrowserUse. It is the escape hatch for systems with no API, which in most enterprises is a long list.

In practice: browser automation is the most brittle capability in any agent stack, because it depends on other people's markup. Prefer an API when one exists, keep browser paths narrow and well-tested, and expect maintenance whenever a target site changes.

The platform makes exposure easy, which shifts the difficulty to a question it cannot answer for you: what should this agent be able to do at all?

The design rules that hold up:

• Expose capabilities, not endpoints. refund_order(order_id, reason) is a tool. A generic POST /transactions that can do fourteen things depending on a body field is a puzzle the model must solve on every call, and a permission you cannot scope.
• Write descriptions for the model, and test them. The description is the entire basis of the selection decision. When an agent picks the wrong tool, the fix is usually one sentence of description, not a smarter model.
• Scope narrowly, then widen. Registering everything because Gateway makes it cheap creates both tool overload and a large action surface for a probabilistic caller.
• Make destructive actions distinct. Read tools and write tools deserve different policies, and irreversible actions deserve confirmation, a spend cap, or a human.
• Version the contract. Agents depend on tool schemas exactly as clients depend on APIs; changing a parameter's meaning silently breaks behaviour without breaking a call.

Key idea: Gateway solved the plumbing, which promotes the real problem to the front: an agent's capability set is a security perimeter and a product decision at the same time. The next lesson covers what the agent remembers across those calls, who it is acting as, and how you find out what it actually did.