From Terraform Modules to the Model Context Protocol

Most teams deploying AI on AWS were still running the same playbook: take a foundation model, wire up a retrieval layer, wrap it in an API Gateway endpoint, and call it a chatbot. By mid-2026, the same teams are deploying autonomous agents that reason through multi-step workflows, authenticate against enterprise APIs, call tools they discover at runtime, delegate subtasks to other agents, and roll themselves back when their evaluation scores drop, all without a human touching the AWS Console.

At the center of this shift is Amazon Bedrock AgentCore, a managed platform that treats AI agents as first-class infrastructure. Pair it with Terraform for declarative provisioning and the Model Context Protocol (MCP) for standardized tool connectivity, and you get a production stack where autonomous AI systems are deployed, governed, and scaled with the same discipline as any other critical workload.

From Models to Agents, What Actually Changed?

For the past couple of years, enterprise AI adoption on AWS looked roughly the same everywhere. Take a foundation model from Bedrock, Claude, Llama, Mistral, bolt on a RAG pipeline with OpenSearch or Kendra, wrap it in a Lambda function behind API Gateway, and serve it to users as a conversational interface. That pattern works for chatbots and summarization, but it hits a wall the moment you need an AI system to do things, not just answer questions, but take actions, call APIs, make decisions, and chain multiple steps together without a human in the loop.

That wall is the agentic paradigm. An AI agent is not just responding to prompts. It is reasoning about what tools it has access to, deciding which ones to use, executing multi-step plans, and adapting when things do not go as expected. Think of it less as a model and more as an autonomous worker that happens to be powered by an LLM.

AWS has made a very deliberate bet on this shift. Amazon Bedrock AgentCore, which went generally available in late 2025 and has been rapidly expanding since, is their answer to the question every platform team was asking: “We built an agent prototype. Now how do we actually run this in production?”

The scale is real. According to AWS, the number of tokens processed on Amazon Bedrock during Q1 2026 exceeded the total across all previous years combined. Inference, not training, has become the dominant workload. And a significant chunk of that inference is being driven by agents, not chatbots.

Amazon Bedrock AgentCore as the Platform Layer

Before it existed, deploying an AI agent on AWS meant stitching together Lambda functions, API Gateway routes, DynamoDB tables for session state, SQS queues for async processing, IAM roles for every downstream service, and custom auth flows for third-party APIs, basically building a bespoke platform every time. AgentCore replaces that patchwork with a managed platform that handles the operational plumbing so you can focus on the agent logic itself.

The service is organized around several composable capabilities, and understanding each one matters because they are designed to be mixed and matched depending on your deployment pattern.

AgentCore Runtime handles the actual execution of your agent code with complete session isolation and support for long-running workloads. You bring your agent, built with any framework, Strands, LangChain, CrewAI, or raw Bedrock API calls, and AgentCore runs it. The Runtime Endpoint is your API surface. No API Gateway. No Lambda. You deploy your agent code, and you get an endpoint that accepts invoke_agent calls directly.

AgentCore Gateway is probably the most architecturally interesting piece. It acts as a unified, secure entry point for all agentic traffic, converting your existing APIs, Lambda functions, and services into tools that agents can call via the Model Context Protocol. Your agents connect to the Gateway’s single MCP endpoint and discover available tools dynamically at runtime. More on this shortly, because MCP is the piece that ties the entire stack together.

AgentCore Identity integrates with existing identity providers for automated authentication and permission delegation. This is crucial because agents acting autonomously need to authenticate against downstream services, your Salesforce org, your Jira instance, and your internal APIs, and you really do not want to hardcode credentials into agent prompts or stuff OAuth tokens into the context window. AgentCore Identity handles OAuth2 flows, credential rotation, and scoped permission delegation so the agent authenticates like a human user would, just without the human.

AgentCore Observability and Evaluations provide real-time monitoring and continuous quality assessment. You can set up batch evaluation pipelines that A/B test different agent versions against defined metrics, latency, accuracy, hallucination rate, and cost per token and trigger automatic rollbacks when performance degrades below a threshold you define. Every tool invocation, every model call, every reasoning step is traced via OpenTelemetry.

AgentCore runs exclusively on AWS Graviton (ARM64) processors. If you are providing custom container images or S3 packages, they need to be ARM64-compatible. It is a small thing, but it will bite you if you do not catch it during your first deployment.

Why Terraform? Not Just for Agents, but Especially for Agents

If you are doing cloud infrastructure in 2026, you are almost certainly using some form of Infrastructure as Code. AI agents are complex systems with a lot of moving parts, runtime configurations, tool definitions, identity bindings, Cedar policy rules, memory store configurations, model selections, guardrail settings, and evaluation thresholds. When those are configured manually through the AWS Console, drift is inevitable. Someone tweaks a tool definition in staging. Someone changes a Cedar policy in production. Nobody remembers what the “known good” state was. Now multiply that by the number of agents your organization is running and by the number of environments (dev, staging, and production) each agent is deployed to.

Terraform solves this the same way it always has: declarative state management, version-controlled configurations, plan-before-apply workflows, and the ability to tear down and recreate infrastructure deterministically. But the value proposition is amplified for agents because the configuration surface area is larger and the consequences of misconfiguration are harder to detect. A misconfigured IAM role on a traditional Lambda function produces an obvious permission error. A misconfigured tool definition on an AI agent produces subtly wrong behavior that might not surface until the agent has processed hundreds of requests.

AWS has made the Terraform path straightforward. The official aws-ia/agentcore/aws Terraform module on the Terraform Registry handles creation and management of AgentCore resources. The AWS Labs team also maintains a repository of Terraform samples covering common deployment patterns, basic runtimes, MCP server configurations with JWT authentication, multi-agent systems with Agent-to-Agent (A2A) communication, and end-to-end examples with tools like Browser, Code Interpreter, and Memory.

A typical deployment flow looks something like this: define your agent infrastructure in HCL, runtime type, container or code configuration, tool bindings, and identity setup, run terraform plan to preview what is about to change, run terraform apply to provision everything, and invoke your agent via boto3.client(‘bedrock-agent-runtime’).invoke_agent(…). That is the entire deployment chain. No API Gateway. No Lambda. The AgentCore Runtime Endpoint is your API surface.

The automation story goes deeper than just provisioning. Combined with CI/CD pipelines, you can build workflows where a pull request that changes an agent’s tool definitions triggers a terraform plan, gets reviewed by a human, and upon merge, applies the change and kicks off an evaluation pipeline against a test suite of representative queries. If the evaluation scores drop below the threshold, an automatic rollback fires. This is the kind of governance loop that makes security teams comfortable with autonomous AI systems in production, and it is entirely a standard Terraform workflow, just applied to a new kind of infrastructure.

For teams already running Terraform for their broader AWS infrastructure, this means agents slot into existing modules, pipelines, and state management without introducing a parallel CDK world. The agent is just another resource in your Terraform state, managed alongside your VPCs, your RDS instances, and your ECS clusters.

The Model Context Protocol as the Universal Adapter for AI Agents

If AgentCore is the platform and Terraform is the provisioning layer, MCP is the connective tissue that makes agents actually useful. Without it, you have an autonomous reasoning engine with no hands.

The Model Context Protocol started as an open specification released by Anthropic in November 2024. The core idea is deceptively simple: define a standard way for an LLM client to discover and call tools on an external server. Think of it as USB-C for AI agents, a universal connector that works regardless of which model, which framework, or which tools you are using.

MCP defines three roles: the client (your application or agent), the server (the tool or data surface), and the host (the model runtime). It uses JSON-RPC under the hood, and since the 2026-07-28 specification, the largest revision since launch, MCP has become a fully stateless protocol that works on ordinary HTTP infrastructure. Each request is self-contained. No handshakes. No persistent sessions. No sticky load balancers. This is a bigger deal than it sounds, because it means MCP servers can run behind standard round-robin load balancers and scale horizontally like any other HTTP service.

Why does this matter for agentic AI? Because agents need tools. An agent that can only generate text is just a chatbot with delusions of autonomy. The moment it needs to query a database, call a Salesforce API, file a Jira ticket, check CloudWatch logs, or send a Slack message, it needs a standardized way to discover what tools are available and invoke them with proper authentication. MCP is that standard.

The governance angle is significant. MCP was donated to the Agentic AI Foundation under the Linux Foundation in December 2025, co-founded by Anthropic, Block, and OpenAI, with supporting members including Google, Microsoft, AWS, Cloudflare, Bloomberg, and Intuit. That is about as broad an industry coalition as you will find in tech. MCP is not a single-vendor play, it is infrastructure.

How AgentCore Gateway Implements MCP

This is where it gets practical. AgentCore Gateway is essentially a managed MCP gateway. It takes your existing APIs, defined via OpenAPI specs, Smithy models, or Lambda functions, and exposes them as MCP-compatible tools. Your agents connect to the Gateway’s single MCP endpoint and discover available tools dynamically.

But Gateway does more than protocol translation. It centralizes concerns that MCP alone does not address.

Authentication and authorization work in both directions. Inbound: who is calling the Gateway, and are they allowed to? Outbound: how does the Gateway authenticate to downstream services on behalf of the agent? AgentCore Identity handles credential management, including OAuth2 flows, so agents can authenticate against third-party services without exposing tokens in prompts or context windows. The agent never sees the credentials. It calls the tool through the Gateway, and the Gateway handles auth transparently.

Policy enforcement uses Cedar-based policies, the same policy language that powers Amazon Verified Permissions, to define fine-grained rules about which agents can use which tools, under what conditions, and with what guardrails. You can write policies like “Agent X can call the Salesforce MCP server only during business hours and only for accounts in the EMEA region.” The Cedar policies are, of course, managed in your Terraform configuration.

Observability is centralized because every tool invocation flows through the Gateway. This gives you audit trails, rate limiting per user or agent, token budgeting, and cost tracking in one place. When the CFO asks “how much are our AI agents spending on API calls?” you have an answer.

Agent-to-Agent routing supports passthrough targets for A2A traffic. One agent can delegate tasks to another agent through the same governance layer, which means your multi-agent orchestration gets the same authentication, authorization, and observability as your tool invocations. No side channels. No ungoverned agent-to-agent chatter.

The Gateway also offers one-click integrations with popular SaaS tools: Salesforce, Slack, Jira, Asana, Zendesk, meaning you can expose enterprise tooling to your agents without writing custom integration code. For teams running their own MCP servers for internal APIs, Gateway can front those as well, adding the auth, logging, and rate-limiting layer that a raw MCP server does not provide. AWS PrivateLink support ensures traffic stays within your VPC boundaries for network-sensitive workloads.

The Strands Agents SDK where Developers actually Write Code

One more piece worth understanding, because it is what most developers will actually touch day-to-day: the Strands Agents SDK.

Strands is AWS’s open-source Python and TypeScript SDK for building agents. It was launched in May 2025, and it powers production features inside AWS’s own services, Amazon Q Developer, AWS Glue, and VPC Reachability Analyzer. The Python package pulls over 16 million downloads per month as of mid-2026.

Strands takes a model-driven approach. Instead of manually scripting workflows, if X, then call tool Y, then check condition Z, you define your agent with a system prompt and a set of tools, and the LLM handles the planning, tool selection, and execution flow autonomously. The developer specifies what the agent can do; the model figures out how and when to do it, adapting its approach based on the results it gets back from each tool call.

The architecture boils down to the following: Model + Tools + Prompt = Agent

Strands has native support for MCP tool servers, Agent-to-Agent (A2A) communication, multi-agent graph and swarm patterns, and OpenTelemetry tracing. It works with multiple model providers, Bedrock, Anthropic direct, Meta Llama, OpenAI, Ollama, though the Bedrock integration is unsurprisingly the most polished.

When combined with AgentCore and Terraform, the full stack layers cleanly: the Strands SDK for building the agent logic, AgentCore Runtime for deploying and scaling it, AgentCore Gateway for connecting it to tools and other agents via MCP, and Terraform for defining and managing all of it as code.

What Production Deployments Actually Look Like

To make this concrete, consider two patterns that are running in production today.

The Infrastructure Bootstrapper Agent

Several teams have implemented a Strands-based agent running on AgentCore that manages real AWS infrastructure through natural language. You tell it, in plain English, what you need, “Create an SQS queue called ‘order-events’ in eu-central-1 with a 5-minute visibility timeout” and it figures out the right CloudFormation schema, generates the desired state, explains what it is about to create, waits for your confirmation, and deploys it.

Ask it about costs, and it queries Cost Explorer through the Gateway. Ask about logs, and it searches CloudWatch. Ask about the state of a deployment, and it checks CloudFormation stack status. The agent’s tools are exposed via AgentCore Gateway as MCP servers, its identity and permissions are managed via AgentCore Identity, and the entire infrastructure, the agent itself, its runtime, its tool bindings, and its Cedar policies are defined in Terraform.

The Multi-Agent Cloud Migration Framework

AWS Professional Services built a multi-agent framework for enterprise cloud migrations that demonstrates the full power of the A2A pattern. Four specialized agents work together:

An Intake Agent handles automated discovery and cataloging of applications targeted for migration. An IaC Agent generates infrastructure code that adheres to AWS Well-Architected security best practices. A Migration Intelligence Agent provides portfolio-wide governance, dependency mapping, and compliance assessments. An SRE Agent handles proactive post-migration operations, monitoring, runbook generation, and incident response.

All four agents communicate via A2A on AgentCore, and the results are significant: IaC development time went from three to four weeks per application to minutes across a 300+ application portfolio. These are not toy demos. They are production systems handling real enterprise workloads. And they are only feasible because the underlying infrastructure, the runtime, the tool connectivity, the identity layer, and the governance policies are managed as code and governed through standardized protocols.

Best Practices for Production Agent Deployments

Teams that have been running agents on AgentCore for several months report several consistent lessons.

Treat agent prompts like production code. Version them in your repository. Review changes in pull requests. Test them against a representative query suite before deploying. A subtle wording change in an agent’s system prompt can significantly alter its behavior across thousands of invocations, and unlike a code bug, the failure mode is not an error, it is subtly wrong output that passes silently.

Use Cedar policies to enforce least privilege. Just as you would not give a Lambda function admin access to your entire AWS account, do not give an agent unrestricted access to every tool in the Gateway. Define policies that scope each agent to the minimum set of tools it needs, with conditions that restrict access by time, by user context, or by data classification.

Run evaluation pipelines on every change. AgentCore’s batch evaluation feature lets you define test suites of representative queries with expected outputs. Wire these into your CI/CD pipeline so that every Terraform apply that changes an agent’s configuration triggers an evaluation run. If accuracy drops or latency spikes, the pipeline rolls back automatically. This is the same principle as integration tests for traditional software, just applied to AI agents.

Log everything through the Gateway. When an agent takes a consequential action, creates a Jira ticket, sends a Slack message, or modifies infrastructure, you need a clear audit trail. Because all tool invocations flow through AgentCore Gateway, you get centralized logging by default. Use it. When something goes wrong, and it eventually will, the ability to replay the agent’s exact reasoning chain and tool call sequence is the difference between a 10-minute diagnosis and a two-day investigation.

Start with a single, well-understood workflow. The temptation is to automate everything at once. Resist it. Pick one workflow, an infrastructure query agent, a code review assistant, or an incident triage bot, and get it working reliably before expanding. Prove it works manually with the Strands SDK locally, then deploy to AgentCore, then add Terraform governance, then scale.

What This Means Going Forward

The convergence of agentic AI platforms, Infrastructure as Code, and standardized protocols like MCP represents a maturation point. The industry is moving past the “wow, it can write code!” phase and into the “how do we operate this at scale with the same discipline we apply to any other critical system?” phase.

MCP is becoming infrastructure. The specification made it stateless and HTTP-native. Every major cloud provider and a growing number of enterprise SaaS tools support it. If you are building APIs or internal tools, making them MCP-compatible is increasingly table stakes, the same way making them REST-compatible became table stakes a decade ago.

Terraform’s role is expanding. As agent deployments become more complex, multi-agent systems with shared memory, tool registries, Cedar policy layers, and evaluation pipelines, the surface area of infrastructure that needs to be managed as code grows proportionally. The terraform-aws-agentcore module is actively maintained and expanding to cover new AgentCore capabilities as they launch.

The governance question is central. Autonomous agents acting on behalf of users and organizations create novel governance challenges. Who approved this tool invocation? What data did the agent access? Can we audit the entire decision chain? AgentCore’s combination of Cedar-based policies, centralized Gateway observability, and automatic evaluation-based rollbacks is an early answer, but the governance patterns for agentic AI are still being established across the industry.

Multi-agent architectures are production-real. The days of “one agent, one task” are ending. Production deployments increasingly involve specialized agents that collaborate, and the protocol and platform layers, MCP for tool connectivity, A2A for agent collaboration, and AgentCore Gateway for governance, are what make that collaboration possible without it devolving into chaos.

Amazon Bedrock AgentCore provides the managed platform for deploying autonomous AI agents with session isolation, identity management, and continuous evaluation. Terraform provides the declarative infrastructure layer that prevents configuration drift and enables governed, auditable deployments through standard CI/CD workflows. The Model Context Protocol provides the universal tool connectivity standard that lets agents discover and invoke tools across enterprise systems without custom integration code. And the Strands Agents SDK provides the developer experience for building model-driven agents that reason, plan, and act autonomously.

The stack is production-ready and actively used by engineering teams at scale. The technology is maturing fast. The patterns are emerging from real deployments, not whitepapers. If you are a cloud architect, a platform engineer, or a developer building AI-powered systems on AWS, now is the time to understand how these pieces fit together, not because the hype cycle says so, but because the production deployments are already here.

References:

Amazon Bedrock AgentCore

Terraform + AgentCore

Model Context Protocol (MCP)

Agentic AI Foundation (Linux Foundation)

Strands Agents SDK

Multi-Agent Cloud Migration (AWS Professional Services)

Cedar Policy Language

Written by: Karen Pearl V. Pabilando

Karen Pearl V. Pabilando "En" is a fourth-year BS Information Technology student at National University - Manila, an IT intern at Tutorials Dojo, and a full-stack developer passionate about building meaningful digital solutions. Her work spans client projects, academic research, and active involvement in various tech communities, where she contributes to advancing innovation and knowledge-sharing in the field of technology. Learn more about her work at https://envember.com to explore her projects and connect with her for collaborations and inquiries.

Agentic AI on AWS: From Terraform Modules to the Model Context Protocol

Agentic AI on AWS: From Terraform Modules to the Model Context Protocol

From Models to Agents, What Actually Changed?

Amazon Bedrock AgentCore as the Platform Layer

Why Terraform? Not Just for Agents, but Especially for Agents