Multi-Agent, MCP, or Just More Tools? What I Learned Wiring Agents on AWS AgentCore

Golden Jacket Field Notes, Week 12

Last month I set out to build a customer support system on AWS. The plan, drawn on a whiteboard with the confidence of someone who had read too many architecture diagrams, had four agents. A translation agent. An order-lookup agent. A policy agent. And an orchestrator on top to coordinate the other three.

I spent the better part of two weeks on it. Then, in review, a teammate asked a question I had not asked myself: which of these actually needs to think?

That stopped me. The translation step called a model and returned text. The order lookup read a record and returned a status. The policy lookup returned a static document. None of them reasoned about anything. None of them made a decision the orchestrator could not have made by calling a function. I had built three agents that were functions wearing costumes, and I had paid for the costumes in latency, in identity management, and in a debugging surface that grew every time two of them talked.

The production version has one agent. It reasons, and it reaches for tools. That is the whole system.

This is a field note about the decision I should have made on the whiteboard, before any agent code existed. It is the decision between the Model Context Protocol (MCP) and the Agent-to-Agent protocol (A2A), and it is what determines whether you are building a multi-agent system or just an agent with more tools.

The two protocols answer two different questions

People talk about MCP and A2A as if they compete. They do not. They sit on different axes.

MCP is vertical. It defines how a single agent reaches down to a tool or a data source: a database, an internal Application Programming Interface (API), a function, a document store. The agent stays in charge of the reasoning. The tool runs, returns a value, and the agent decides what to do with it.

A2A is horizontal. It defines how one agent hands work to another agent that reasons on its own. The second one is not a function you call. It receives a task, makes its own decisions about how to complete it, and returns a result you did not fully specify in advance.

The clearest way I have found to hold this in my head is simple: MCP connects an agent to a tool, A2A connects an agent to an agent. One commentator I read while checking my own assumptions framed it as the vertical layer versus the horizontal layer, and that framing has stuck with me.

So here is the test I now run before I draw a single box.

Does the thing on the other end need to make decisions?

If the answer is no, it is a tool. Expose it over MCP. If the answer is yes, if it genuinely reasons and you cannot predict the shape of its output from the input, then it is an agent, and you talk to it over A2A.

My translation step failed that test. So did the order lookup. So did the policy lookup. Three tools, one agent. The orchestrator I had designed was the only agent in the building, and everything below it was a tool wearing the wrong label.

Why the boundary is not free

Every agent boundary you add is a cost you pay on purpose.

It is a network hop, which is latency. It is an identity that has to authenticate to the next agent, which is configuration and a place for security to go wrong. It is a session that has to carry context across the boundary, which is a place for the conversation to get lost. And it is a line item on the bill, because a reasoning agent invokes a model, and models are not free.

None of that is an argument against multi-agent systems. It is an argument against multi-agent systems by default. When you genuinely have separate concerns, owned by separate teams, that each need to reason, A2A earns its keep. The coordination cost buys you modularity, reuse, and the freedom to let two teams move without tripping over each other. When you do not have that, the coordination cost buys you nothing, and you carry it anyway.

I carried it for two weeks. I would like that time back.

What AgentCore actually gives you here

Amazon Bedrock AgentCore reached general availability on October 13, 2025. I want to be precise about what it is, because the name gets used loosely. AgentCore is not a framework and it is not a model. It is the production platform underneath your agents: a managed runtime so you stop hand-rolling the hosting, plus a set of services you can adopt one at a time.

Two of those services map directly onto the decision above.

For the tool side, there is AgentCore Gateway. It turns existing APIs and AWS Lambda functions into MCP tools your agent can call, through managed connectors, so you are not writing fragile tool loops by hand. If your honest answer to the decision test is “these are tools,” Gateway is where they live.

For the agent side, when AgentCore reached general availability in October 2025, the Runtime already included native support for the A2A protocol. This is the part that retired a good chunk of my skepticism. The runtime can host an A2A server directly, acting as a transparent proxy: your container runs a stateless Hypertext Transfer Protocol (HTTP) server, and the runtime passes the JSON-RPC 2.0 messages (a remote procedure call format carried as JavaScript Object Notation) through unchanged, so the protocol stays intact. It exposes the standard discovery card at the well-known path /.well-known/agent-card.json, so other agents can learn what yours can do. It handles inbound and outbound authentication through AWS Signature Version 4 (SigV4) or OAuth 2.0, and it isolates each interaction with its own session. The same runtime also hosts MCP servers. One runtime, both axes.

There is more in the platform than I will cover here. Policy reached general availability on March 3, 2026, and it is worth knowing about. It lets a security or compliance team define which tools an agent may touch, in natural language that compiles to Cedar (the open-source policy language), enforced outside your agent code by intercepting traffic at the Gateway. Evaluations reached general availability on March 31, 2026. I mention these so you know the platform has grown well past the runtime, not because you need them on day one.

How this maps to the companion repository

If you read the Week 2 companion code, the aws-agentic-stack-starter, you have already seen both patterns in isolation. You can now see which one most teams actually need.

The strands-with-mcp module, talking to the mcp-lambda module, is the “one agent, MCP tools” pattern. A Strands agent reasons, and it reaches a remote MCP server hosted on a Lambda Function Uniform Resource Locator (URL) for its tools. That is the shape of most production systems I have built or reviewed. It is the shape my customer support system should have had from the first whiteboard.

The a2a-exchange module is the “agents delegating to agents” pattern. When I wrote it, I framed it as a didactic simulation, because A2A was still moving and I did not want to ship code that would break the moment the spec shifted. That caution has aged into something better than I expected. A2A was donated by Google to the Linux Foundation in June 2025, it is now at version 1.2 with cryptographically signed agent cards, and it is running in production across AWS, Microsoft, and Google, with more than 150 organizations behind it. The simulation in that module is no longer a placeholder for something that might never arrive. It is a stepping stone to a protocol you can deploy for real, on the AgentCore Runtime, today.

What the documentation does not tell you

A few things cost me time. I am writing them down so they do not cost you the same.

The region situation in São Paulo is worth a word, because it is easy to assume more than is there. When I first wrote the companion repository, AgentCore was not available in South America (São Paulo), the sa-east-1 region, and the repo says so. That changed in May 2026, when AWS launched the region with the core stack: runtime, identity, gateway, observability, code interpreter, and browser. The newest features are a different story. At the time of writing, the most recent additions, the managed harness, the Agent Registry, and AgentCore Payments, had not all reached São Paulo. This is the release pattern to expect when a new region lights up: the core lands first, and the newest pieces follow weeks or months later. Do not assume parity with us-east-1. Check the console in your target region for the specific capability you need before you write a line of Terraform.

If you expose a Lambda Function URL with no authentication for a quick MCP server, AWS requires two resource-based permissions, not one. You need lambda:InvokeFunctionUrl to authorize the endpoint, and lambda:InvokeFunction to authorize the execution after the endpoint lets the request through. Provide only the first and every request returns a silent 403 Forbidden. I lost an evening to this before the console quietly told me what was wrong. The mcp-lambda template in the repo provisions both.

If you invoke the newer Claude family on Bedrock, you go through a cross-region inference profile rather than on-demand throughput. The tell is the us. prefix on the model identifier. Copy a bare model identifier from an older example and the call fails validation, and the error does not always make the reason obvious.

If you deploy an agent or an A2A server to the AgentCore Runtime, the container has to be built for ARM64, the AWS Graviton architecture. The runtime supports nothing else, and it validates the architecture of the native binaries in your package at deploy time. A plain build on an x86 machine produces an x86 image, and the runtime rejects it. The nastier version of this is when a single native dependency slips through: you get a silent import error at runtime that reads like a code bug and is actually an architecture mismatch. I lost an afternoon to exactly that. Build with the ARM64 target set explicitly.

On the infrastructure-as-code side, the good news. The Terraform AWS provider ships the aws_bedrockagentcore_agent_runtime resource natively, since version 6.18, and newer versions let you point the runtime at an Amazon Simple Storage Service (S3) zip artifact instead of only a container image. So you can manage all of this in the same state as the rest of your stack, with a plan you can read, instead of reconstructing a multi-resource setup from console screenshots after a demo.

Takeaway

You make the multi-agent decision before any agent code exists. It is a classification problem with one question in it: does this component reason, or does it just run?

If it runs, it is a tool, and it belongs behind MCP, on the vertical axis, where one agent stays in charge. If it reasons, it is an agent, and it belongs behind A2A, on the horizontal axis, where the AgentCore Runtime will now host it as a first-class citizen. Get the classification right and the system almost designs itself. Get it wrong, as I did, and you pay coordination costs for components that never had a decision to make.

Mental shortcut: if it reasons, it is an agent, so A2A, horizontal. If it only runs, it is a tool, so MCP, vertical. Do not pay the price of an agent boundary for anything that does not decide.

About the author

I am an AWS Solutions Architect with almost 15 years in cloud, focused on production machine learning and generative AI workloads for regulated organizations. I hold every active AWS certification, including the Generative AI Professional credential as an Early Adopter, the status AWS recognizes with the Golden Jacket. I am the sixth Brazilian Golden Jacket holder and co-founder of Golden Jackets Brazil.

• Medium: medium.com/@erickmancz
• LinkedIn: linkedin.com/in/erick-mancz
• AWS Builder Center: builder.aws.com/community/@imancz
• Credly: credly.com/users/erick-mancz.66783c3e

Opinions expressed here are my own and do not represent the views of my employer or any affiliated organization.