Same agent, two clouds: when one agent isn't enough

“Multi-agent” is the most over-prescribed idea in agent architecture right now. Many systems drawn as a team of agents chatting are really a workflow, and they’d be cheaper, faster and easier to debug if they were built as one.

This last part of the series covers what AWS and Azure give you when one agent really isn’t enough, and how to tell when it is. Part one covered the runtime, and part two covered tools.

Start with the question, not the pattern

The support agent from ATC-001 only drafts replies. Now the business wants it to handle refunds. That means finding the order, checking the refund rules, getting a manager’s approval when the amount is large, issuing the refund, and replying to the customer.

There are two ways to build that.

• A team of agents. A triage agent, an orders agent, a policy agent and a refunds agent, passing the conversation between them and deciding together what happens next.
• A workflow with agent steps. The order of steps is fixed in code. Models do the reasoning inside the steps that need it: understanding the request, picking the right order. Everything else is ordinary code, and the approval is a person.

The second version is the right one for refunds, and for most business processes, for three reasons:

1. Every hand-off costs tokens. Each agent that sees the whole conversation pays for it again. Three agents reading the same context cost roughly three times what one does.
2. Rules belong in code. “Refunds over $200 need a manager” shouldn’t depend on a model remembering it. Code applies it every time, and you can test it.
3. Workflows can wait. An approval can take two days. A workflow engine holds that state cheaply and reliably; a conversation between agents doesn’t.

Use a real team of agents when you can’t know the path in advance: open-ended research, investigating an incident, or work where the next step depends on what the last one found. Even then, put a budget and a step limit around the whole team.

Both clouds support both approaches. Here’s what each gives you.

AWS: Strands for the team, Step Functions for the workflow

Strands Agents, AWS’s open-source agent SDK, covers the team patterns:

• Agents as tools: a lead agent calls specialist agents the way it would call any tool. It’s the simplest pattern, and usually the right first step.
• Swarm: agents hand work to each other on their own, and the path emerges at run time.
• Graph: you define which agents can pass to which, and a model picks the route at each step.
• Workflow: a fixed graph of tasks, with independent tasks running in parallel.

Strands also speaks A2A, the open agent-to-agent protocol, in both directions. A Strands agent can be served as an A2A endpoint, and a remote A2A agent can be a node in a Strands graph.

For the workflow approach, Step Functions gained an agent step in June. It’s backed by the AgentCore harness and launched in four Regions, so check availability in yours. It can run agents in sequence or in parallel, pause for human approval, override the model, prompt or tools per call, and keep context across calls with a session ID. There’s no extra charge for the integration; you pay normal Step Functions, model and AgentCore rates. Waiting days for a manager’s approval is something Step Functions has always done well.

Two more AWS pieces matter once you have more than a few agents. AgentCore Gateway can front agents running on AgentCore Runtime, passing their traffic through, A2A included. And the AWS Agent Registry, generally available since August, is a private catalog of your agents, tools and MCP servers, so teams can find what already exists instead of building it again.

If you built multi-agent collaboration on the original Bedrock Agents, read AWS’s migration guidance carefully. The managed harness covers only the simple supervisor pattern, with agents as tools. Routing and full multi-agent collaboration need your own framework code on AgentCore Runtime. Plan that migration as a redesign, not a lift-and-shift.

Azure: Agent Framework for both

Microsoft Agent Framework reached 1.0 in April for .NET and Python. It replaces both Semantic Kernel and AutoGen: AutoGen is now in maintenance mode. Agent Framework ships five ready-made orchestrations:

• Sequential: agents run in a fixed order.
• Concurrent: agents work in parallel and the results are combined.
• Handoff: agents pass control to each other.
• Group chat: agents share one conversation under a manager.
• Magentic: a lead agent plans the work and assigns it to specialists, adapting as results come in.

Underneath sits a graph-based workflow engine with branching, fan-out and fan-in. All of it supports checkpointing, human approval steps, and pause and resume. That puts the workflow approach and the team approach in one framework.

To run these workflows on Azure, deploy them as hosted agents in Foundry, which part one covered. This is now Microsoft’s recommended path, because the visual workflows in the Foundry portal are being retired on December 1, 2026. For waits measured in days, Microsoft documents a Durable Task extension for Agent Framework. Each agent session becomes a durable entity with automatic checkpoints, on Azure Functions or any compute with the Durable Task Scheduler. And if your team already uses Logic Apps, its agent workflows can use more than 1,400 connectors as tools.

Across platforms, Foundry agents call other agents through the A2A tool, which is generally available. It replaces the classic “connected agents” feature, which didn’t carry over to the new Agent Service. Prompt agents can also be exposed as A2A endpoints. A2A version 1.0 is generally available on Foundry; the older version 0.3 is still in preview.

Side by side

AWS

Azure

• A lead agent with specialists

  AWS: Strands: agents as tools The simplest team pattern.

  Azure: Agent Framework: Magentic A lead agent plans and delegates.

• Agents pass work to each other

  AWS: Strands: swarm The path emerges at run time.

  Azure: Agent Framework: handoff Agents transfer control.

• Routes you define, a model chooses

  AWS: Strands: graph Model-chosen routes, cycles allowed.

  Azure: Agent Framework: workflow graph Branching, fan-out and fan-in.

• Fixed steps with agent tasks

  AWS: Step Functions agent step Backed by the AgentCore harness. June 2026.

  Azure: Sequential and concurrent Ready-made orchestrations, deployed as hosted agents.

• Waiting days for a person

  AWS: Step Functions Approval steps and long waits.

  Azure: Checkpoints, Durable Task Pause, resume, durable sessions.

• Agents on other platforms

  AWS: A2A in Strands and Runtime Serve and call A2A agents.

  Azure: A2A tool and A2A endpoints GA (A2A 1.0), in both directions.

The refund flow on each cloud

On AWS: a Step Functions state machine with an agent step for triage and order lookup, which uses the Gateway tools from part two. A Lambda function applies the refund rule. A task token waits for the manager’s approval, which arrives by email or in the helpdesk. Then a Lambda function issues the refund and a final agent step drafts the reply. The state machine is the audit trail.

On Azure: an Agent Framework workflow with the same steps: an agent executor for triage and lookup, a function executor for the rule, a human-approval step with checkpointing, then the refund and the reply. You deploy it as a hosted agent. If approvals can sit for days, run it on the Durable Task extension so nothing is held in memory while it waits.

Each cloud gets the same shape with different parts. The design choice that matters, a workflow with agent steps rather than a team of agents, is the same on both.

How to choose

• Your process is known in advance (refunds, onboarding, claims, approvals): use a workflow with agent steps. On AWS, that’s Step Functions; on Azure, Agent Framework workflows on hosted agents or Durable Task.
• The path is truly open-ended (research, investigations): use a team pattern. Start with a lead agent and specialists as tools before trying swarms or group chat, and cap the steps and tokens for the whole team.
• Agents live on both clouds, or belong to different teams: connect them with A2A, which both clouds support, and treat each agent as a service with its own owner, budget and limits.

That’s the series. The same support agent, built three layers deep on both clouds, comes down to three decisions: where your identities live, where your APIs already sit, and whether your process is a workflow or a conversation. Get those right and either cloud will serve you well.

---

Status as of October 2026; preview features may change. Primary sources: Strands multi-agent patterns, Strands A2A, Step Functions with AgentCore, AWS Agent Registry, Bedrock Agents Classic migration guidance, Microsoft Agent Framework 1.0, Agent Framework orchestrations, Durable agents with Agent Framework, Foundry workflows retirement, Foundry migration guide, Logic Apps agent workflows.