./blog/a2a-azure-foundry-agent-swarm-weekend
Two days, one Foundry resource, three agents that don't share a process — wiring A2A between them and putting a Magentic-style manager on top to see if dynamic delegation still works once "calling another agent" means a network hop.
A weekend with A2A on Azure AI Foundry
Agent swarms, Magentic orchestration, and what breaks when agents stop living in the same process
I had two things on my "someday" list: actually try the Agent2Agent (A2A) protocol instead of just reading the spec, and see whether Microsoft's Magentic orchestration pattern — the manager-with-a-ledger approach from Magentic-One — holds up when the workers it's delegating to aren't Python objects in the same process, but separate agents behind a network endpoint. Azure AI Foundry shipped incoming A2A support in public preview this cycle, which made it a reasonable weekend to stop reading and start wiring. This is the notebook version of that weekend: what I built, what the protocol actually gives you, and the three things that ate most of Saturday.
A2A gives agents a standard way to advertise themselves (an agent card) and talk to each other over JSON-RPC, regardless of what framework built them — it's the "agents calling agents" counterpart to MCP's "agents calling tools." Foundry Agent Service has supported outbound A2A (calling a remote agent as a tool) for a while; incoming A2A — exposing a Foundry agent as an A2A endpoint other agents can discover and call — is now in public preview, with identity, content safety, and audit logging applied per hop. I put three specialized agents behind A2A endpoints and ran Semantic Kernel's Magentic manager in front of them instead of calling them directly. The dynamic, ledger-based delegation pattern survives the trip over the network surprisingly well — the manager doesn't care that a "worker" is remote. What doesn't come for free: agent-card discovery being static rather than live, and every extra hop being one more place identity and content-safety policy has to be configured correctly, not assumed.
why --the-itch-behind-the-weekend
Most of the multi-agent demos I'd built before this were single-process: one Python script,
a handful of agent objects, a manager calling .run() on each of them directly.
That's a fine way to learn an orchestration pattern, but it quietly begs the question that
actually matters in production — most real agent swarms won't be one team's code in one
process. They'll be agents built by different teams, on different frameworks, sometimes in
different companies, that need to find each other and collaborate without everyone agreeing
on a shared runtime first. That's the problem A2A is trying to solve, and Foundry's incoming
A2A support landing in public preview was the excuse I needed to stop treating it as a spec
to read and start treating it as a Saturday.
a2a-in-30-seconds --what-the-protocol-actually-gives-you
A2A (Agent2Agent) is an open protocol, originally from Google and now under the Linux Foundation, for letting one agent discover and invoke another agent as a peer — not as a tool call into a function, but as a request to a whole other agent that has its own model, memory, and reasoning loop. Two pieces matter most:
- The agent card. A JSON document, typically served at a well-known path, that advertises what an agent is, what skills it exposes, and how to authenticate to it — the thing another agent (or orchestrator) reads to decide whether this is the right agent to delegate to.
- Tasks over JSON-RPC. A calling agent sends a task to the target agent's endpoint; the target can respond synchronously, stream partial results, or hand back a task ID to poll — closer to "delegate this piece of work and get a real answer back" than a typical tool-call schema.
The comparison I found most useful: MCP standardizes how an agent calls a tool (a database, a search API, a filesystem); A2A standardizes how an agent calls another agent. They're complementary, not competing — in the swarm I built, every worker agent still used MCP internally to reach its own tools, and A2A only sat at the boundary between agents.
setup --wiring-it-up-in-foundry
Foundry Agent Service already had an outbound A2A tool — an agent calling a remote A2A endpoint as if it were any other tool. What's new in public preview is the other direction: taking a Foundry agent and exposing it as an A2A endpoint, with an auto-generated agent card, so agents built on completely different stacks can discover and call it. I built three small Foundry agents for the weekend, each with a narrow job:
Grounded on Bing + a small internal knowledge index. Job: turn a fuzzy question into a cited set of findings.
Code-interpreter-backed. Job: take the research agent's findings and produce a small structured table or chart.
No tools, deliberately weaker model. Job: read the other two agents' output and flag unsupported claims before anything gets called "done."
Each agent got an incoming A2A endpoint enabled and its own agent card. Two protocol versions are supported side by side — v1.0 and v0.3 — with Microsoft's guidance being to target v1.0 for anything new, which is what I used throughout. Every call between agents goes through Foundry's managed endpoint rather than agent-to-agent directly, which means identity, content-safety filtering, and audit logging apply on every hop, not just at the outermost entry point — worth knowing before you assume a "safe" agent talking to a "safe" agent is automatically a safe conversation.
the-swarm --putting-a-magentic-manager-in-front
The actual experiment was upstream of Foundry's A2A tooling: instead of wiring the three agents together with fixed, hand-coded handoffs, I put a Magentic manager in front of them, using Semantic Kernel's implementation of the orchestration pattern Microsoft's AutoGen team introduced with Magentic-One. The core idea is a manager that doesn't run a fixed pipeline — it keeps a running task ledger, decides which agent is best suited to act next given everything learned so far, and re-plans as new information comes in, instead of a human wiring "agent A always hands off to agent B."
The question I actually cared about: does that dynamic selection logic still work cleanly when "the next agent to call" is a remote A2A endpoint instead of an in-process object? In the original Magentic-One, the manager's worker agents (WebSurfer, Coder, FileSurfer, ComputerTerminal) all live in the same process. Mine didn't — the manager had to go out over A2A for every delegation, and results had to come back the same way before the ledger could update.
In practice this worked. I gave the swarm an intentionally open-ended prompt — "how has our internal API error rate trended over the last two quarters, and is it worth a design review" — and watched the manager route: research first, data agent for the actual number-crunching, research again once the data agent surfaced a gap, reviewer last to sanity-check the conclusion before answering. Nothing about that sequence was hand-coded; the manager decided it from the ledger each time. The interesting part is what stayed the same versus a single-process build: the manager's decision-making logic didn't need to know or care that its workers were remote. A2A abstracted that difference away almost completely.
what-ate-saturday --three-things-that-werent-obvious
Agent cards are a snapshot, not a directory
The card is fetched and cached at wiring time. If I changed a worker agent's skills or model after the manager had already discovered it, nothing broke loudly — the manager just kept acting on stale capabilities until I refreshed it. Worth building a deliberate re-discovery step rather than assuming it's live.
Protocol version mismatches fail quietly
Foundry supports both A2A v1.0 and v0.3. Pointing one agent's outbound tool at a v0.3 assumption while its target had been upgraded produced a working-looking call with a subtly malformed response, not a clean error. Pin the version explicitly on both sides.
Every hop is a policy surface, not just the entry point
Because Foundry applies identity, content-safety, and audit logging per A2A hop, a prompt that's fine going into the manager can still get filtered three hops later at the reviewer agent — which is the right behavior, but it means testing the swarm end-to-end, not just testing each agent in isolation.
my-take --closing-thoughts
The thing I went in skeptical about — whether a dynamic, ledger-driven orchestration pattern like Magentic actually holds up once you stop cheating with in-process objects — turned out to be the part that worked best. The manager doesn't need to know an agent is remote; A2A's job is exactly to make that distinction disappear. What doesn't disappear is everything downstream of "now it's a network call": discovery going stale, version drift between caller and callee, and policy that has to be verified at every hop instead of assumed from the one at the front door. None of those are protocol failures — they're the normal cost of moving from a demo to something that looks like a real distributed system, just showing up faster than I expected because A2A makes the distributed part so easy to set up in the first place.
Next weekend project, if I get to it: point the reviewer agent's A2A endpoint at something outside Foundry entirely — a locally hosted agent on a different framework — to see whether "regardless of framework or cloud" holds up as well as the docs claim once identity and content-safety expectations don't match on both sides.
sources --further-reading
Related on this site: When the model broke its own sandbox · OWASP Top 10 for Agentic Applications