A2A + MCP: Building Self-Orchestrating Multi-Agent Workflows on AWS Serverless

Give a single AI agent 30+ tools and watch its accuracy drop to 48%. The answer isn't a smarter model- it's specialized agents that coordinate.

Multiagent systems is where things get real.

This session combines two open protocols- Google's Agent-to-Agent (A2A) for inter-agent communication and Anthropic's Model Context Protocol (MCP) for tool access to build multi-agent workflows on AWS serverless.

We'll build a system where specialized agents discover each other via A2A, invoke tools through MCP servers, and orchestrate on Lambda, Step Functions, and Bedrock. No long-running servers.

What we'll cover:
- Deploying MCP servers on Lambda and zero-code via AgentCore Gateway
- A2A agent discovery and task delegation
- Step Functions for parallel agent invocation with retries and timeouts
- Strands Agents SDK; open source by AWS
- Sharp edges: cold start compounding, tool selection accuracy, context window limits
- When multi-agent makes sense vs when a single agent is enough

Includes a live demo, protocols, architecture, and code.

Himanshu Sangshetti
AI Engineer @ Mem0

Pune, India

Gave a session at AWS Community Day Bengaluru last weekend
Talked about self-orchestrating agents on AWS, and the protocols A2A+MCP

Then the fun part, tried running a benchmark: do self-orchestrating agents (a coordinator that decides at runtime who to call) actually beat a single agent or a hand-written DAG workflow' I built four agentic workflows and benchmarked them

The honest answer: it depends on the task shape (which is obv but still wanted to try benchmarking)

• -On a local single-shot benchmark (720 runs, 3 open models), the explicit DAG workflow won on every model. Up to +0.48 higher success than self-orchestration on the weakest one (llama3.1:8b: 0.83 vs 0.35), at roughly half the cost and about 1.7x lower latency

• -On ''-bench (Sierra's multi-turn, verifier-graded benchmark, 240 episodes), it flipped completely. On Claude Haiku 4.5, self-orchestration went from worst to best (explicit 0.20 to self-orch 0.60), and on Sonnet 4.5 it tied for the top.

A fixed DAG just can't adapt to where an open conversation actually goes. But self-orch paid for it: ~8.5 delegations and ~3x the latency to get there.

3. READ THE TRACES!! Unguarded, self-orch cascaded to 6 delegations every time on open-ended tasks

Autonomy is real, it just quietly costs you in latency and $.

Stack, for the curious:
> ''-bench (Sierra) + a local suite, Strands Agents SDK on Bedrock AgentCore (Runtime + Gateway), Step Functions + Lambda, litellm, and Ollama for the local models.
> Models: Claude Haiku 4.5 / Sonnet 4.5, Llama 3.3 70B, Pixtral Large, plus qwen3 / llama3.1 / glm4 locally.
> Metrics borrow from BFCL (tool-selection) and '-bench (pass^k).

____

Slides: lnkd.in/gnUEmSGj
Benchmark repo: lnkd.in/gZE83StR

This was my first time speaking in Bangalore, and it's so different from a Pune audience. Its filled with typical nerds and I loved it.

Would have loved to catch more Bangalore events, but it was a fast Pune<>BLR in the morning and back by evening. Honestly a bit travelled-out, coz just got back from Taiwan too

Had really nice chats with Sankalp, Sagar, Pratik, Adit, Jyoti and many more. Awesome speaker lineup too. And thanks to AWS User Group Bengaluru, Jones, Avinash and the organizers + volunteers for putting it together

As usual, some exciting things coming up :)

small benchmark im trying to run- does letting AI agents orchestrate themselves perform better'
or does it just add cost and more failures'

I built a quick benchmark harness along with 4 agent architectures to evaluate on:
- single: one agent with all tools
- explicit: a hand-authored workflow / DAG (deterministic)
- self-orch: a coordinator that decides at runtime which specialists to delegate to (A2A)
- hybrid: self-orch + a guardrail (a cap on delegations)

the setup kind of is:
-graded on ''-bench (Sierra's public tool-agent benchmark) with pass^k reliability [btw first 720 runs on my labelled task suite]
- scoring follows BFCL for tool-selection
- and the Inspect AI dataset'solver'scorer pattern
- local models on Ollama for NOW

I will be running the same four strategies on real AWS serverless architectures since i was originally experimenting as i will be speaking on this topic at AWS Community Day Bangalore

The TLDR till now from the base experiment (720 runs, 3 open models):
- The scripted workflow was more reliable than the autonomous one on every model, +58 points on the weakest (paired bootstrap, p'0)
- On an open-ended task, the unguarded self-orchestrator kept delegating until it hit its cap (6 hops); a simple guardrail held it to 2
- It costs more per query for less reliability, and the trade gets worse the weaker the model.

The read: self-orchestration is a tradeoff, for now

well it largely depends on the models and harness too. planning to take this further, primarily on AWS by using better inference models and I will setup AWS architectures for each workflow

and then locally for long runs with better models after i delete some games to free up space lol

you can check the bench here: lnkd.in/gZE83StR

I am trying to learn how do we even benchmark workflows in the first place. Honestly, just experimenting but its been fun. If yk a standard practice to it, please comment through or dm