The AWS Agentic Stack Explained: Strands, AgentCore, MCP, and A2A.

Differences between: Strands, Agentcore, MCP and A2A.

Series: Golden Jacket Field Notes (22 articles)

1
The Cheapest Price Per Token Can Be the Most Expensive Way to Run an LLM
…
11
The AWS Agentic Stack Explained: Strands, AgentCore, MCP, and A2A. This article
12
S3 Files: What 20 Years of “You Can’t Mount S3” Looks Like When It Finally Ships

Erick Mancz

AWS Golden Jacket | Co-founder Golden Jackets Brazil Community | 40 AWS Credentials

Published May 5, 2026

Last modified Jun 30, 2026

Disclaimer

**Originally published on Medium as Week 2 of Golden Jacket Field Notes.**Canonical URL: https://medium.com/aws-tip/the-aws-agentic-stack-explained-strands-agentcore-mcp-and-a2a-a-practitioners-map-4ef995a2e5b4This is a republication on AWS Builder Center for the AWS community. The piece below appeared first on Medium and is preserved here in its original form.

— -

Golden Jacket Field Notes. Week 2.

— -

Strands Agents SDK. Amazon Bedrock AgentCore. Bedrock Agents (the original one). Model Context Protocol. Agent-to-Agent protocol. Agent Squad. Strands Labs. Each with its own blog post, its own GitHub repo, its own set of promises.

I have been building on AWS for almost fifteen years. I hold every certification they offer, including the Gen AI Professional early badge. I earned my Golden Jacket. And I was confused.

So I did what I always do when the documentation leaves me hanging. I built things, broke things, read the source code, and took notes. This article is those notes. A practitioner’s map of the AWS agentic stack as it exists today, in March 2026.

— -

Why This Matters Right Now

We are in a very specific moment. The agent hype cycle hit peak noise around re:Invent 2025, and now teams are actually trying to ship agents to production. The problem is that most of them are drowning in terminology before they write a single line of code.

I have talked to solutions architects across three continents in the last two months. The same question keeps coming up: “I know I need agents, but I do not understand what connects to what.” And honestly, the documentation does not help. Each service page explains itself well enough in isolation. But nobody draws the full map for you. Nobody tells you when to reach for Strands versus when AgentCore matters versus when you should just use plain Bedrock Agents and call it a day.

That is what this article does. No marketing language. No “exciting new capabilities.” Just a clear, opinionated map from someone who has built with all of them.

— -

The Four Layers: A Mental Model

Before I get into each piece, here is the mental model that finally made everything click for me. The AWS agentic stack has four distinct layers, and confusing them is where most of the pain starts.

Layer 1: The Framework (Strands Agents SDK). This is where you write code. It is the open-source SDK that gives you the agentic loop: model receives input, reasons about what to do, calls tools, reflects on results, repeats. You build your agent here. Think of it as the engine of a car.

Layer 2: The Infrastructure (Amazon Bedrock AgentCore). This is where your agent runs in production. Runtime environments, identity management, memory persistence, observability, policy enforcement. Think of it as the road system, traffic lights, and fuel stations. You could drive the car on a dirt path, but AgentCore gives you the highway.

Layer 3: The Tool Protocol (MCP Model Context Protocol). This is how your agent connects to the outside world. Databases, APIs, file systems, SaaS applications. MCP standardizes that connection so you do not have to write custom integrations for every tool. Think of it as the hands of the agent and how it grabs and manipulates things.

Layer 4: The Coordination Protocol (A2A Agent-to-Agent). This is how agents talk to each other. When one agent needs to delegate a task to another, or when multiple agents need to collaborate on a complex workflow, A2A provides the communication standard. Think of it as the language agents use to work as a team.

Four layers. Four concerns. And here is the crucial part: you do not always need all four. That is where the real decisions live.

— -

Layer 1: Strands Agents SDK: The Framework

Strands was born inside AWS. The teams behind Amazon Q Developer, AWS Glue, and VPC Reachability Analyzer were building agents internally and kept running into the same frustration: existing frameworks like LangChain forced them into complex workflow definitions that got in the way of what newer models could do natively.

So they built their own SDK. Tested it internally for over a year. Then open-sourced it in May 2025. By March 2026, it has been downloaded over fourteen million times.

The core philosophy is what AWS calls “model-driven.” Instead of you defining elaborate chains and graphs, you give the model a system prompt and a set of tools, and let the model figure out the execution plan. Three components:

Model. Strands supports Amazon Bedrock, Anthropic API directly, Meta’s Llama API, OpenAI through LiteLLM, Ollama for local development, and custom providers. You can swap models in one line of code. This matters more than people realize — I have switched models mid-project three times in the last six months as new ones came out.

Tools. This is where MCP comes in (more on that below), but Strands also ships with twenty-plus built-in tools and lets you turn any Python function into a tool with a simple `@tool` decorator. The TypeScript SDK hit preview in December 2025 for those of you who live in that world.

Prompt. The system prompt that shapes the agent’s behavior. Nothing fancy here . Jjust a string. But the quality of this string will make or break your agent. I have spent more time tuning system prompts than I care to admit.

Here is what a minimal Strands agent looks like:

```python

from strands import Agent

from strands_tools import calculator

agent = Agent(tools=[calculator])

agent(“What is the square root of 1764”)

```

That is it. Five lines. The agentic loop, reasoning, tool calling, reflection, happens inside the SDK. You do not orchestrate it. The model does.

Now, I have to be honest about something. This simplicity is both the strength and the trap. When things go wrong (and they will go wrong) the fact that the model is making all the decisions makes debugging harder. You need to invest in observability from day one. I learned this the hard way on a project where an agent kept calling the same API in a loop because the model misinterpreted a tool’s error response.

When to use Strands

You want to build agents, not just use them. You need flexibility to swap models, customize tools, and control the agentic loop. You care about open source and want to avoid lock-in. You plan to deploy on AWS but want the option to run locally during development.

When to skip Strands

Your use case is simple enough for Amazon Bedrock Agents (the managed service — no code required, configure through the console). You need a quick proof of concept and do not want to write Python or TypeScript.

— -

Layer 2: Amazon Bedrock AgentCore: The Infrastructure

This is where things get real. Building an agent is one thing. Running it in production with security, scaling, memory, and monitoring is a completely different problem.

AgentCore went generally available in October 2025 and has been evolving fast since then. It is not a framework — it is a platform. And the distinction matters. You can use AgentCore with Strands, but you can also use it with CrewAI, LangGraph, LlamaIndex, Google ADK, or OpenAI’s Agents SDK. Framework-agnostic. Model-agnostic.

Here are the services inside AgentCore that actually matter in practice:

AgentCore Runtime. This is where your agent physically runs. Secure, isolated environments with up to eight-hour execution windows. That last part is important — most serverless runtimes time out way before that. If your agent needs to complete a long-running workflow (and many real-world agents do), this matters. Runtime now supports A2A protocol natively and bidirectional streaming for voice agents.

AgentCore Gateway. Connects your agent to external tools and data sources. This is the managed MCP layer, essentially. Instead of configuring MCP servers yourself, you define tools through the Gateway and it handles authentication, rate limiting, and protocol translation. In practice, this saved me about three days of integration work on my last project.

AgentCore Memory. Three types: short-term (within a conversation), long-term (across conversations), and (as of re:Invent 2025) episodic (the agent learns from past experiences). Episodic memory is the one that changes the game. An agent that remembers “last time I tried approach X it failed because of Y” starts behaving like an experienced colleague instead of an amnesiac intern.

AgentCore Identity. OAuth, Amazon Cognito, IAM (Identity and Access Management) integration. Your agent can act on behalf of a user with proper scoped permissions. This sounds boring until you realize that agents without proper identity management are a security nightmare. I have seen demos where the agent had admin-level access to everything. Do not do this.

AgentCore Observability. OpenTelemetry compatible, CloudWatch dashboards, integration with Datadog, Dynatrace, Arize Phoenix, LangSmith, and Langfuse. You get traces of every tool call, every model invocation, every decision the agent made.

AgentCore Policy. This one just went GA this week. Literally March 2026. It intercepts every tool call in real time and enforces rules you define in natural language, which get converted to Cedar (the AWS open-source policy language). Example: “The agent can issue refunds up to $100 but must escalate anything above that to a human.” Deterministic enforcement, outside the agent’s code. This is how you prevent the horror stories of agents giving away the store.

AgentCore Evaluations. Preview since re:Invent 2025. Thirteen pre-built evaluation metrics covering correctness, safety, tool selection accuracy, and more. Think of it as unit tests for agent behavior. Run them during development, run them continuously in production.

The honest take on AgentCore

It is genuinely impressive. But it is also a lot. If you are a two-person team building a simple chatbot with tool use, you probably do not need all of this. A Strands agent deployed on Lambda behind an API Gateway will serve you fine.

Where AgentCore earns its keep is when you have multiple agents, when you need compliance and audit trails, when agents are making consequential decisions (financial, medical, operational), or when you are operating at scale across an organization.

I think of it like this: you do not need Kubernetes to run one container. But when you have fifty microservices in production, you are glad it exists. Same idea.

— -

Layer 3: MCP and How Agents Use Tools

Model Context Protocol was created by Anthropic, open-sourced, and donated to the Linux Foundation’s Agentic AI Foundation in December 2025. By February 2026, it had crossed ninety-seven million monthly SDK downloads. Every major AI provider supports it: Anthropic, OpenAI, Google, Microsoft, AWS.

The concept is simple. MCP standardizes the interface between an AI model and external tools. Instead of every agent framework inventing its own way to call a database or hit an API, MCP provides a universal protocol. JSON-RPC 2.0 under the hood. Client-server architecture.

Here is why this matters practically. Before MCP, if you wanted your Strands agent to query a PostgreSQL database, you wrote a custom tool. If you also wanted it to search Confluence, you wrote another custom tool. And another for Jira. And another for Slack. Each one with its own authentication logic, error handling, and data formatting.

With MCP, there are thousands of published MCP servers. You point your agent at the right server, and it can use the tool through a standardized interface. Strands has native MCP support. You can pass an MCP server as a tool source directly.

What the docs underplay

MCP is great for connecting an agent to tools. But it was not designed for agents talking to other agents. It can be stretched to do that (and some teams do) but it gets awkward. That is where A2A enters.

Also, not all MCP servers are created equal. I have used some that were well-tested and production-ready, and others that were basically someone’s weekend project wrapped in MCP. Always test the server you are integrating with. Trust but verify.

— -

Layer 4 — A2A: How Agents Talk to Each Other

The Agent-to-Agent protocol is what you reach for when a single agent is not enough. And for complex enterprise workflows, a single agent is almost never enough.

A2A was initiated by Google, and AWS has actively contributed to its development through the Linux Foundation. It uses HTTP and JSON-RPC — familiar territory for anyone who has built web services.

The key concepts:

Agent Cards. Every A2A agent publishes a JSON manifest at /.well-known/agent.json that describes who it is, what it can do, and how to communicate with it. This is the discovery mechanism. An orchestrator agent can read these cards and decide which specialist to route a task to.

Task lifecycle. A2A defines a structured lifecycle for tasks: submitted, processing, complete, failed. The orchestrator tracks the state of each task it delegates. This sounds obvious until you have tried to build this from scratch — it is surprisingly tricky to get right.

Framework interoperability. Here is the part that actually matters. An orchestrator built with Strands can delegate tasks to a specialist built with OpenAI’s SDK, which in turn collaborates with an agent built with Google ADK. They do not need to share a framework or even a model. A2A provides the common language.

AWS demonstrated this at re:Invent with a monitoring and incident response system: a Google ADK orchestrator coordinating with Strands and OpenAI SDK agents, all deployed on AgentCore Runtime. Different frameworks, different models, same protocol.

The real decision: multi-agent or single-agent-with-tools?

This is the question nobody answers clearly, so I will give you my take based on what I have built and seen.

Start with a single agent using tools (Strands + MCP). Seriously. The vast majority of use cases I encounter in the field do not need multi-agent orchestration. They need one well-designed agent with access to the right tools. Multi-agent adds complexity: network calls between agents, state synchronization, error propagation across agent boundaries, debugging distributed agent behavior. It is everything hard about microservices, plus the nondeterminism of LLMs.

Move to multi-agent (A2A) when you hit one of these:

The domain knowledge required is too broad for a single system prompt to cover well.
Different parts of the workflow need different models (e.g., a fast cheap model for triage, an expensive powerful model for analysis).
Organizational boundaries require separation (Team A owns the inventory agent, Team B owns the pricing agent, and they should be independently deployable).
You need strict context isolation — one agent should not see data that another agent processes.

If none of those apply, resist the multi-agent temptation. It looks cool in demos. It is painful in production.

— -

Where Does “Bedrock Agents” (The Original) Fit?

I know what you are thinking. “But wait, Amazon Bedrock Agents has been around since 2023. Is it dead?”

No. It is alive, it works, and for many use cases it is still the fastest path to a working agent. Bedrock Agents is the fully managed, console-configurable agent service. You define your agent in the AWS console, attach knowledge bases, define action groups, and deploy. No SDK required.

Think of it on a spectrum:

Bedrock Agents (managed) → fastest time to value, least customization, best for straightforward use cases.

Strands SDK → maximum flexibility, open source, requires coding, best when you need full control.

AgentCore → the production platform that can host either approach (plus agents from any other framework).

They are not competing. They are layers. And honestly, I have used Bedrock Agents for rapid prototyping and then moved to Strands when I needed more control. Nothing wrong with that progression.

— -

The Decision Tree

I am going to give you the cheat sheet I wish someone had given me.

”I just want a working agent, fast.”

→ Amazon Bedrock Agents. Console. Done.

”I need to customize the agentic loop, use my own tools, swap models freely.”

→ Strands Agents SDK + MCP for tools. Deploy on Lambda or Fargate.

”I need enterprise-grade security, memory, policy enforcement, and monitoring.”

→ Strands (or any framework) + AgentCore for deployment and operations.

”I have multiple specialized agents that need to work together.”

→ Everything above + A2A protocol for inter-agent coordination.

”My agents are built by different teams with different frameworks.”

→ A2A is non-negotiable. AgentCore Runtime as the shared hosting layer.

— -

What I Am Watching

Three things that are still evolving and worth tracking:

Strands Labs. Launched two weeks ago. This is where AWS is pushing experimental agentic concepts — AI Functions (code generation at runtime from natural language specs) and Strands Robots (connecting LLMs to physical hardware). It is early, but it signals where the roadmap is headed.

AgentCore Policy maturity. It just went GA. I want to see how it handles edge cases in production. The Cedar policy language is powerful but takes time to learn well. The natural language to Cedar conversion is convenient but I have not yet pushed it hard enough to know its limits.

The A2A + MCP convergence. The Linux Foundation’s Agentic AI Foundation now hosts both protocols. The emerging consensus is a three-layer stack: MCP for tools, A2A for agents, and eventually a web layer on top. How quickly this matures will determine how real multi-agent systems become outside of demos.

— -

The AWS agentic stack is not one thing. It is four layers solving four different problems: building agents (Strands), running them in production (AgentCore), connecting them to tools (MCP), and coordinating them with each other (A2A).

You do not need all four on day one. Start simple. Add layers as your complexity grows. And for the love of everything …invest in observability before you need it, not after your agent loops forever at 3 AM burning through your Bedrock bill.

I have been in cloud for almost fifteen years. The shift to agentic architectures is the biggest paradigm change since serverless. And like serverless, the teams that win will not be the ones using the fanciest tools. They will be the ones who understand which layer to reach for and when to stop adding complexity.

Build agents like you build architecture: with intention, not hype.

— -

This is part of the Golden Jacket Field Notes. A weekly deep-dive into AWS ML and GenAI from the field. If you found this useful, follow me for more practitioner insights that the documentation does not cover.

# amazon-bedrock-agentcore # amazon-bedrock-agents # agentic-ai # amazon-bedrock # rag