Part 2 of 3: Runtime, Identity, and Gateway
Part 1 of this series made the case for investing in platform foundations before shipping AI agents at scale, and introduced the nine concerns that define enterprise readiness. This post covers the infrastructure layer: the three AgentCore components that every agent deployment needs in place before anything else.
Why These Three Come First
Not all platform foundations carry the same urgency. Some, like agent discoverability or advanced policy rules, can be introduced incrementally as the platform matures. Others cannot. Runtime, Identity, and Gateway are the connective tissue of the platform. Without managed hosting, agents have nowhere secure to run. Without identity integration, every agent team is solving authentication independently. Without a centralised integration layer, every new agent creates a new web of bespoke connections to backend systems.
These three components define the shape of everything that comes after. The authentication model chosen in Identity determines how Gateway targets are configured. The Gateway architecture determines how Policy enforcement is applied. The deployment model established in Runtime determines how agents scale and how memory persists. Getting these decisions right early is not about perfectionism — it is about avoiding the expensive retrofitting that happens when teams skip the conversation and build around defaults.
This is also the layer that unlocks the first agent use case. You do not need Guardrails configured or the Registry populated to deploy your first agent safely. You do need an execution environment, a credential model, and a governed path for agent-to-tool communication. That is what this post covers.
AgentCore Runtime: Managed Agent Hosting Without the Infrastructure Tax
The platform concern: Running containerised agents in production requires managing ECS clusters, load balancers, autoscaling policies, VPC networking, and IAM roles, all before you’ve written a single line of agent logic. Every team doing this from scratch is spending engineering cycles on undifferentiated infrastructure.
What Runtime provides: A managed execution environment that understands the agent invocation lifecycle. You provide a container image; Runtime handles the hosting. You get VPC-resident deployment with multi-AZ resilience, configurable inbound authentication (IAM SigV4 or JWT-based), and a stable endpoint that agents can be invoked against without you owning the underlying compute layer.
One important constraint worth knowing at architecture time: a given Runtime version supports either IAM or JWT-based authentication, not both simultaneously. Where you need to support both patterns (for example, internal service-to-service calls via IAM alongside user-facing calls with JWT tokens), you deploy separate runtime versions with distinct authentication configurations. It’s not a limitation so much as a clear separation of concerns, but it shapes your deployment model.
Runtime is also the hosting layer for MCP servers — the tool containers that Gateway can route agent requests to. This means an agent and its associated tools can be deployed on the same underlying infrastructure, sharing the same lifecycle and delivery pipeline. The relationship between Runtime and Gateway is worth understanding early: Runtime handles where things run; Gateway handles what they can call.
AgentCore Identity: Integrating Your Existing IdP, Not Replacing It
The platform concern: Enterprises already have identity infrastructure: Entra ID, Cognito, internal OAuth providers. Agent platforms that require you to manage a parallel identity system create credential sprawl, complicate access reviews, and make offboarding harder. The right answer is for agents to authenticate through the identity systems you already govern.
What Identity provides: A managed integration point that connects AgentCore to your existing Identity Provider. It handles OAuth token issuance and validation so that agents can authenticate to downstream services using your existing IdP, without each agent team building and maintaining their own OAuth integration. Whether your organisation is on Cognito or Entra ID, Identity gives you a consistent model for how agent credentials are issued, scoped, and validated.
For the Gateway specifically, there are two inbound authentication patterns worth choosing between deliberately. IAM-based (SigV4) authentication is the right choice when the agent and its tools share a development lifecycle and trust boundary, typically the same team and the same repository. Cognito-based authentication is the right choice when MCP servers or Gateway targets are operated independently and accessed by agents across different teams. In this pattern, one Cognito client application per agent keeps credentials isolated and independently revocable. The MCP provider team retains full control over who can access their service without affecting other agents.
This decision (IAM or Cognito for Gateway authentication) is one of the few that is genuinely expensive to change later. It touches the agent code, the Gateway configuration, and the downstream service authentication setup simultaneously. The Identity section of Part 3’s companion post on architecture lessons goes into why this needs to be made at design time, not deferred.
AgentCore Gateway: The Integration Layer That Doesn’t Create New Risk
The platform concern: As the number of agents grows, so does the surface area of integrations. Without a centralised gateway, you end up with direct connections between agents and backend systems, each with its own authentication configuration, each generating its own logs (or not), each requiring its own network path. The result is an integration mesh that is opaque, hard to audit, and expensive to change.
What Gateway provides: A managed integration layer that sits between agents and everything they call. It supports five target types, each suited to different integration scenarios:
Lambda functions: the recommended default for new tool integrations. Stateless, event-driven, with native IAM authentication. The operational overhead is minimal and the economics work at most request volumes.
OpenAPI endpoints: for integrating existing REST APIs and third-party services without modifying them. Supports IAM, OAuth, and API Key authentication depending on what the upstream service requires.
Smithy models: for AWS service orchestration where type-safe contracts matter.
MCP Server on Runtime: containerised tools with serverless economics. Supports IAM, OAuth, and API Key.
MCP Server on ECS: for long-running services that need persistent connections, dedicated compute, or specific VPC networking requirements. The right choice when request volume justifies continuous running costs.
All outbound authentication to these targets flows through the Gateway’s configured credentials; agents never hold direct credentials to backend systems. Every call is logged. Every target is defined in infrastructure, not in agent code.
Two constraints worth knowing early: MCP Server targets require HTTPS endpoints, and VPC Endpoint access is currently limited to Lambda targets only. These shape architecture decisions that are expensive to revisit later.
Decoupling the agents and tools layers
Without a managed integration layer, agent teams and tool teams are tightly coupled at the implementation level. Every agent that needs a tool must know how to authenticate to it, speak its protocol, and handle its failure modes directly. Every new agent that needs the same tool duplicates that integration work. This becomes an M×N integration problem: M agents each directly integrating with N tools produces a sprawling web of point-to-point connections that is expensive to maintain, test, and audit as the number of agents grows.
AgentCore Gateway addresses this by introducing a hub-and-spoke model. Tool providers register their APIs, Lambda functions, or MCP servers as targets on a Gateway. Agents connect to the Gateway and discover whatever tools it exposes. Each side evolves independently. A tool team can update a backend service, rotate credentials, or swap an implementation without touching agent code. An agent team can onboard to a new capability by pointing at a Gateway endpoint rather than negotiating a bespoke integration. The M×N problem collapses to M+N: agents connect to the Gateway, tools connect to the Gateway, and the Gateway manages the surface area between them.
Shared gateways and independent tool teams
A single AgentCore Gateway can serve multiple agents simultaneously. The Gateway exposes its full tool catalogue as a unified MCP endpoint. Agents connect via HTTP with bearer token authentication, call list_tools to discover what is available, and invoke tools through that single interface. Cognito client applications control which agents can access which tools: one client per agent keeps credentials isolated and independently revocable, and the tool team retains full control over who can reach their service without coordinating directly with agent teams.
This means a platform team can provision a shared gateway that consolidates common enterprise tools (internal APIs, approved third-party services, shared data sources) and onboard agent teams by issuing them a Cognito client with appropriate scope. Tool teams work independently: each maintains and deploys its own targets, controls versioning within its domain, and does not need to coordinate with agent teams on implementation. The Gateway handles discovery, protocol translation, and authentication centrally. It also resolves tool naming collisions across teams, so independently developed tools with similar names remain distinguishable to agents without manual coordination.
When agent-specific tools should be co-deployed
The shared gateway model suits tools that are genuinely useful to multiple agents. It is less well suited to tools built for one specific agent that have no value outside that context: an internal reasoning helper, a workflow state manager, or a highly domain-specific data formatter. For tools like these, deploying the tool and the agent together in the same stack is the cleaner choice. Both share the same delivery pipeline, the same lifecycle, and can be tested as a unit before promotion to production. AgentCore supports this: an agent and its associated MCP server or Lambda tools can be deployed as a self-contained stack, with the Gateway providing the integration boundary between them and the rest of the system.
This is not a permanent architectural decision. A tool that starts as private to one agent but later proves useful to others can be promoted to a shared gateway without changing agent code; only the Gateway configuration changes. Building through the Gateway from the outset preserves that option.
What You Have at the End of This Layer
With Runtime, Identity, and Gateway in place, the platform can do something meaningful: deploy agents securely, connect them to tools in a governed and auditable way, and scale without each new agent creating new infrastructure debt. The authentication model is settled. The integration surface is centralised. The first agent use case has a solid foundation to run on.
What the platform cannot yet do is enforce behavioural boundaries on what agents attempt, control what the model says, persist context across sessions in a governed way, or give you visibility into what is happening across the full request path. That is the work of the next layer.
Part 3 of this series covers the controls, governance, and architectural decisions that shape how the platform operates at scale: Policy, Guardrails, Memory, Observability, Registry, cost governance patterns, when to consider a model gateway, and the implementation lessons that only surface once you are building in production.