The Orchestration Layer: A Comparative Architecture of Agentic Frameworks for Multi-Agent Systems
Vector1 Research — Technical Paper
Author: Brian Curry, Vector1 Research Contact: brian at vector1.ai License: Creative Commons Attribution 4.0 International (CC BY 4.0) Date: June 2026
Abstract
Every major cloud provider and several platform companies now ship a framework for building multi-agent AI systems. AWS has Bedrock AgentCore. Microsoft has converged Semantic Kernel and AutoGen into the Microsoft Agent Framework, fronted by Azure AI Foundry’s Agent Service. Google has the Agent Development Kit and Vertex AI Agent Engine, recently rebranded under the Gemini Enterprise Agent Platform. Databricks has Agent Bricks, anchored by a beta Supervisor Agent. Anthropic has the Claude Agent SDK and, as of this spring, Claude Managed Agents. OpenAI has the Agents SDK and AgentKit. NVIDIA has the NeMo Agent Toolkit and OpenShell. Salesforce has Agentforce, scripted through a new domain-specific language called Agent Script. This is, by any measure, a crowded field, and the crowding is not cosmetic — each entrant encodes a different bet about where the orchestration logic should live, who owns the runtime, and how much of the “boring 99%” of agent engineering (memory, identity, observability, cost control) the platform absorbs versus leaves to the developer.
This paper does four things, where the previous version of this work did two. First, it builds a vendor-neutral taxonomy of the orchestration patterns that recur across every framework surveyed — sequential pipelines, parallel fan-out, hierarchical supervision, and handoff networks — and shows that despite different vocabularies, the platforms are largely implementing the same small set of coordination primitives. Second, it proposes a five-plane reference architecture (interface, coordination, agent, protocol, substrate) that every surveyed platform maps onto, and uses it to organize a structured comparison across portability, governance, protocol support, and — newly — actual cost structure, with published pricing pulled from each vendor where available. Third, it opens up the internals that the first version of this paper treated as black boxes: what Bedrock AgentCore’s runtime, gateway, memory, and identity layers actually do underneath a framework; how Semantic Kernel and AutoGen’s separate research lineages were architecturally merged into the Microsoft Agent Framework; and how the Model Context Protocol and Agent2Agent protocol compose at the wire level rather than just at the level of a one-sentence distinction. Fourth — and this is the heart of the expanded contribution — it implements the same four-agent insurance-intake workflow eight times, once per platform surveyed, in API-faithful pseudocode, so that the comparison between platforms is mechanical and checkable rather than descriptive: the same task, the same agent boundaries, eight different concrete realizations of coordination, tool access, and state.
The central finding holds and sharpens under this expansion: the framework war is largely settled at the orchestration-pattern level — sequential, parallel, hierarchical, and handoff topologies are universal — and what is actually being contested is the layer below and the layer beside it: who runs the agent’s compute and bills for it, who owns its memory, and which protocol mediates its boundaries to tools and to other agents. Looking at all eight implementations side by side makes a second, more specific finding visible that wasn’t as legible in the original draft: the platforms split cleanly into three architectural families — bring-your-own-framework runtimes (AWS, Azure, NVIDIA) that host orchestration logic you write, declarative supervisor platforms (Databricks, Salesforce) that generate orchestration logic from a description, and harness-native frameworks (Anthropic, OpenAI, Google) where the orchestration primitives are part of the SDK itself rather than a separate product layered on top. That three-way split, not the eight-vendor list, is the decision that should actually drive a build-versus-buy choice.
1. Why This Comparison Matters Now
A year ago, “multi-agent system” mostly meant a research demo built on LangGraph or AutoGen, glued together by a developer willing to hand-roll session state, retries, and observability. That work has not disappeared, but it has been joined — and in production contexts, largely supplanted — by managed infrastructure from every major platform vendor. The pattern is consistent enough across vendors that it’s worth naming directly: a managed runtime now sits underneath the agent framework, handling the parts that used to consume most of an engineering team’s time on a “simple” agent project.
The Databricks framing of this shift is unusually direct. Mosaic AI Research has been blunt that the core agent loop — the part everyone associates with “building an agent” — is roughly one percent of the actual engineering effort on a production system, while the remaining ninety-nine percent is the hidden technical debt of agentic systems: token capacity, deployment, security, evaluation, monitoring, context, and sharing. AWS’s own technical guidance arrives at the same conclusion from a different angle, framing the shift as a move away from “framework-only” logic toward a managed cloud agent runtime, because monolithic single-agent proofs of concept consistently fail once they hit real enterprise complexity — they run into state explosion and token inefficiency that collapses the ratio of intelligence delivered to dollars spent.
This matters for anyone deciding where to place an investment, because the decision is no longer “which agent framework do we like.” It’s at least a four-layer decision: which orchestration framework defines the agent’s logic, which managed runtime — if any — hosts that logic in production, which protocols let that system talk to tools and to other agents built on entirely different stacks, and what the resulting cost structure looks like once token pricing, runtime surcharges, and platform fees are all on the same invoice. Conflating those layers is the most common architectural mistake in this space right now, and it’s the reason vendor comparisons this year keep talking past each other: a comparison of LangGraph versus Agent Bricks is comparing a framework to a platform, not two frameworks, and a comparison of AgentCore’s price to Agentforce’s price is comparing a usage-metered infrastructure surcharge to a seat-and-platform license, not two numbers on the same axis.
2. A Taxonomy of Orchestration Patterns
Strip away the vendor branding and the same four coordination topologies show up everywhere. This is not a coincidence — they map onto the four ways work can actually be decomposed across more than one reasoning process: in sequence, in parallel, under a single point of authority, or by transfer of ownership. Figure 2 lays these out with the vendor-specific names attached to each.
Sequential pipelines chain agents in a fixed linear order, where each agent’s output becomes the next agent’s input. This is the right shape whenever the task has genuine stage dependencies — extraction must finish before classification, classification before routing. Every platform supports this as close to a first-class primitive: AWS Step Functions state machines, Microsoft Foundry’s workflow layer, the ADK’s SequentialAgent, and LangGraph's basic chain construction all reduce to the same control-flow shape.
Parallel fan-out is the pattern Anthropic has pushed hardest into its public framing this year. A lead agent decomposes a job and dispatches pieces to specialist sub-agents that run concurrently, each in an isolated context window, feeding results back for synthesis. Anthropic’s own description of the pattern is concrete: a lead agent breaks a job into pieces and delegates each piece to a specialist sub-agent with its own model, prompts, and tools, with the sub-agents working in parallel on a shared file system and feeding results back into the lead agent’s context, while the lead agent can check in on sub-agents mid-workflow to verify they’re on track. The motivating numbers are worth taking seriously: Anthropic’s own research found that multi-agent architectures outperform single-agent benchmarks by up to 90% when parallel sub-agents are coordinated by a lead planner, and a separate measurement from Cognition found that coding agents spend roughly 60% of their time on search rather than generation — which is precisely the kind of work that parallelizes well across specialist sub-agents. Bedrock AgentCore now supports this as a named pattern too, with its documentation specifically calling out Swarm-style parallel coordination once Agent-to-Agent protocol support landed natively. The NeMo Agent Toolkit ships the same idea as a literal example workflow type — a parallel_executor that runs independent branches concurrently and merges outputs with partial-failure handling — which is a useful confirmation that this pattern has converged on nearly identical semantics independent of who implemented it.
Hierarchical supervision generalizes the fan-out pattern into a standing structure: a planner or supervisor agent that persists across a longer task and routes subtasks to a fixed roster of specialized workers, rather than spinning up sub-agents per request. Microsoft’s Magentic-One pattern, now folded into the unified Microsoft Agent Framework, is the most fully worked-out version of this in a shipped product — and Microsoft’s own training materials describe the underlying judgment call clearly: deciding when a multi-agent architecture actually earns its coordination cost, then designing hub-and-spoke topologies with a central orchestrator, parallel agent spawning with synchronization and partial-failure recovery, and hierarchical supervisor patterns for multi-level delegation. That phrase — earning its coordination cost — is doing real work. Hierarchical supervision is more expensive and harder to debug than a sequential pipeline, and the platforms that support it well also tend to be the ones most insistent that you confirm you actually need it. Databricks has gone furthest in turning this specific pattern into a packaged, declarative product: the Supervisor Agent, now generally available on Agent Bricks, lets a developer define a task and connect existing systems, after which the supervisor coordinates execution across whatever Genie spaces, Knowledge Assistants, Unity Catalog functions, and MCP servers the end user has permission to reach — access control enforced automatically per user, not configured separately.
Handoff networks differ from the other three in a structural way: there is no fixed topology at all. Control transfers between agents based on the content of the request, and any agent can hand off to any other agent it’s been wired to. OpenAI’s Agents SDK makes this the centerpiece of its design — a triage agent evaluates an incoming request and transfers the full conversation, not just a summary, to a specialist, and the receiving agent inherits the entire conversation as if it had been present from the start. The mechanics are tightly scoped by design: the SDK’s documentation specifies that handoffs stay within a single run, with input guardrails applying only to the first agent in the chain and output guardrails only to the agent that produces the final output. This is the pattern that scales best to a genuinely open-ended set of specialists, because adding a new specialist doesn’t require touching the routing logic elsewhere in the graph — it just requires telling the triage agent the new specialist exists. Salesforce’s Agentforce implements essentially the same topology under different vocabulary: subagents — renamed from “topics” this spring — are evaluated by a start_agent classification step, and after each topic finishes responding, the agent returns to that same classification point for the next message, so the network re-evaluates which specialist should own each turn rather than committing to one specialist for the rest of the session.
The practical upshot of this taxonomy is that “which framework” matters far less than “which pattern, and does the framework make that pattern cheap to implement and observe.” A team that picks Bedrock AgentCore because it’s “the AWS one” and then builds a hierarchical supervisor when the actual task is a sequential pipeline has made a worse decision than a team on any framework that correctly matched pattern to problem.
3. The Five-Plane Reference Architecture
To compare platforms on equal footing, it helps to have a structure that every platform can be decomposed into, independent of vendor terminology. Figure 3 proposes five planes, ordered from the user-facing edge down to raw compute and data.
The interface plane is wherever the request originates — a chat UI, an API call, or increasingly, a messaging platform repurposed as an agent front end. The NVIDIA-Salesforce reference architecture is the clearest example of this last pattern: Slack becomes the primary conversational interface and orchestration layer for Agentforce agents, with Slackbot acting as the coordination layer that receives requests, triggers Agentforce workflows, and orchestrates agent actions across enterprise systems. That’s a meaningful design choice, not an incidental one — it puts the agent inside the tool millions of knowledge workers already have open, rather than asking them to adopt a new surface.
The coordination plane is where the orchestration patterns from section two actually live — the Step Functions state machine, the Foundry workflow definition, the ADK root agent, the LangGraph graph, the Agent Bricks Supervisor configuration. This is the plane most vendor marketing focuses on, because it’s the most visibly “agentic” part of the stack, but it is also the plane that’s easiest to reimplement on a different vendor if you need to — a claim section six tests directly by reimplementing the same coordination logic eight separate times.
The agent plane holds the specialist agents themselves — each one a model, a system prompt, and a deliberately bounded toolset. The bound on tool count is not a minor implementation detail; it shows up repeatedly across independent sources as the single most consequential design parameter in this whole space. One detailed AWS production walkthrough is explicit about the mechanism: an agent’s system prompt covering four distinct domains grew to thousands of tokens, the model paid less attention to instructions buried in the middle of that prompt, and with sixteen tools available the agent spent more reasoning effort on tool selection and picked the wrong tool more often — narrowing each agent to three to five tools measurably improved selection accuracy. A separate, independently authored AgentCore implementation guide converges on the identical diagnosis: an agent with more than twenty tools has a measurably lower probability of selecting the correct one, a “do-everything agent” produces mediocre answers across every domain it touches, and a single LLM call per turn makes parallel execution structurally impossible. Two unrelated engineering teams reaching the same number from different production systems is a stronger signal than either claim alone, and it’s the constraint every one of the eight implementations in section six was deliberately designed around.
The protocol plane is the newest addition to this stack and the one most likely to determine long-run portability. Two protocols have emerged as the de facto standard, and they are complementary rather than competing: the Model Context Protocol governs how an agent talks to tools and data sources, while the Agent2Agent protocol governs how one agent talks to another, independent of what either is built on. Figure 5 makes the composition concrete rather than just naming it.
The distinction is worth stating precisely because it gets collapsed constantly in casual usage: A2A connects AI agents to other AI agents for task delegation, while MCP connects agents to tools, and they are complementary layers in a multi-agent architecture — an agent uses A2A to delegate work to a specialist, which then uses MCP to call the tools it needs. The diagram shows why this matters architecturally and not just terminologically: an agent built on one framework can hand a task to an agent built on a completely different framework over A2A without either side learning anything about the other’s internal tools, memory, or implementation, and each side separately maintains its own MCP connections to its own tools underneath that boundary. Both protocols are now governed outside any single vendor: A2A was contributed to the Linux Foundation in mid-2025 and had surpassed a hundred and fifty supporting organizations by its one-year mark, with deep integration already shipped across Google, Microsoft, and AWS platforms, and MCP itself was placed into a newly formed, vendor-neutral Agentic AI Foundation under the Linux Foundation this spring, with founding contributions spanning Anthropic, Block, and OpenAI. That is an unusual degree of cooperation for infrastructure this strategically important, and it is the single best argument for building agent-to-tool and agent-to-agent boundaries on these two protocols rather than a proprietary equivalent, regardless of which platform hosts the orchestration logic above them.
The substrate plane is everything underneath: model endpoints, vector and feature stores, the lakehouse or data warehouse, identity and secrets management, and the observability and evaluation tooling that determines whether anyone can tell if the system is actually working. This is the plane Databricks has staked its entire agent strategy on — the argument that agents both consume data through tools and context and now produce substantial new data through their own outputs and actions, and that an agent platform only earns its keep if it connects that data to the AI rather than treating them as separate concerns.
Every platform surveyed in this paper can be located on this five-plane stack, even though none of them describes itself in exactly these terms. That’s the point of using a vendor-neutral structure: it’s the only way to compare AWS’s runtime-first approach to Databricks’s data-first approach to Anthropic’s harness-first approach without the comparison collapsing into a marketing-language contest.
4. Platform Survey
4.1 AWS: Bedrock AgentCore
AWS’s current position is that AgentCore is infrastructure, not a framework — it is explicitly the layer that sits below whatever orchestration framework a team chooses and above the cloud substrate, handling session isolation, persistent memory, and secure tool access via MCP, while LangGraph, CrewAI, or the OpenAI Agents SDK still define the actual agent logic running on top of it. Figure 6 breaks this layer into its six constituent services, because “AgentCore” as a single word obscures how much of what it does is genuinely separable.
Runtime gives each agent invocation session-isolated compute regardless of which framework wrote the agent logic. Identity issues per-agent credentials with scoped IAM and workload identity federation, so an agent’s blast radius if compromised is bounded by what that specific agent was actually granted. Observability captures traces, latency, and token metrics per invocation — the same telemetry a team would otherwise have to instrument by hand across every agent. Memory splits into short-term session state and a longer-term knowledge layer that persists across sessions. Gateway is the MCP registry, authentication, and lifecycle management layer — one URL that fronts a whole toolset rather than per-agent tool wiring. And the Browser and Code Interpreter primitives give agents sandboxed execution surfaces for tasks that need to run untrusted code or interact with a rendered web page, without that execution happening inside the same trust boundary as the orchestration logic.
AgentCore reached general availability at the end of April 2026, shipping with CLI-based deployment, CDK integration for infrastructure-as-code, A/B testing for agent versions, and a governance layer aimed specifically at moving agentic workloads from evaluation into production. As of February 2026 AWS’s own reference architecture for multi-agent orchestration on AgentCore put the running cost at roughly $1,456 per month for a workload processing 100,000 customer-support conversations, which is a useful anchor point for anyone trying to estimate what “production-scale” actually costs on this stack — and Figure 8, discussed in section five, places that cost structure next to the other seven platforms surveyed.
The native A2A support is recent and consequential: AgentCore’s documentation now specifically calls out that Agent-to-Agent protocol support unlocks additional Strands multi-agent patterns — graph, swarm, and workflow topologies — that weren’t cleanly expressible before. That’s a direct, observable instance of the protocol layer expanding what the platform layer can do, rather than the other way around.
The clearest limitation, documented candidly by third-party analyses rather than AWS’s own marketing, is model lock-in: AgentCore is primarily designed for Bedrock-hosted models, and while custom models can be brought in through SageMaker, models outside the AWS ecosystem entirely — GPT, Gemini, self-hosted open-source — cannot be directly integrated, which pushes teams who need multi-provider flexibility toward a framework like LangChain running independently of AgentCore’s managed layer. A second limitation worth flagging for cost-sensitive teams: AgentCore is cloud-only, applies a surcharge on top of raw model costs for the managed runtime, and abstracts away the kind of fine-grained cost optimization — quantized models, speculative decoding, cross-user KV caching — that a team running its own infrastructure at very high, stable volume might actually want control over.
4.2 Microsoft: Azure AI Foundry and the Microsoft Agent Framework
Microsoft’s framework strategy underwent a real consolidation this year rather than just a rebrand, and Figure 7 traces the lineage explicitly because the merge is easy to undersell in prose.
The Microsoft Agent Framework unifies what used to be two separate, sometimes redundant projects — Semantic Kernel’s enterprise-grade plugin and orchestration model, and AutoGen’s research-driven conversational multi-agent patterns — into one open-source SDK, stable across Python and .NET, so that developers no longer need to choose between the enterprise foundations of Semantic Kernel and the multi-agent orchestration strengths of AutoGen. This shipped to general availability at Build 2026 alongside a 1.0 release of Semantic Kernel itself, which added agent-centric patterns as first-class concepts: persistent long-term memory, planning, and delegation, plus the ability to define an agent declaratively in YAML rather than imperative code.
What distinguishes Microsoft’s approach from AWS’s is an explicit, repeated commitment to heterogeneity at the orchestration layer. Azure AI Foundry is described as supporting heterogeneous agent teams that mix agents built with Semantic Kernel, LangGraph, or plain REST APIs under a single orchestration plane, with a healthcare scenario specifically demonstrating a triage agent built in Python LangChain coordinating with a HIPAA-compliance checker built on Semantic Kernel, both visible on the same dashboard with shared latency and token metrics. Foundry’s own framing of its agent harness reinforces this as a deliberate design stance rather than an accident: it treats the agent harness as a flex point, not a lock-in, explicitly preserving investments teams have already made in LangGraph, the GitHub Copilot SDK, or the Claude Agent SDK. That’s a notably different bet from AWS’s Bedrock-first model positioning, and it’s consistent with Microsoft’s broader enterprise posture of meeting customers where their existing tooling already is. Foundry Agent Service also now explicitly supports hosted agents — externally-authored agents, including ones built on the Microsoft Agent Framework itself or on LangGraph, running inside customer-dedicated containers that Foundry manages, with scaling, observability, security, and governance bundled in rather than self-assembled.
The multi-agent workflow layer inside Foundry Agent Service adds the production scaffolding on top of the framework choice: persistent state and context sharing across long-running tasks, built-in error handling and retry logic, and visual authoring through either the VS Code extension or the Foundry web console. Microsoft’s own published evaluation framework for this, Agent Confidence Scores, assigns each agent’s output a percentage reliability rating derived from historical accuracy — a governance mechanism aimed squarely at the half of enterprises that, per the MIT Technology Review citation Microsoft uses in its own materials, are still evaluating AI agents manually rather than systematically.
On cost, Foundry Agent Service itself carries no separate charge for orchestration — Microsoft is explicit that there’s no additional fee to create or run Foundry-native agents using prompts and workflows — but every model call still bills at standard token rates (GPT-4o runs roughly $2.50 per million input tokens and $10.00 per million output tokens at current pay-as-you-go pricing, with GPT-4.1 marginally cheaper and Microsoft’s own small Phi-4-mini model running thirty-five to forty times cheaper still for workloads where a smaller model clears the quality bar), and any knowledge connection or action tool an agent invokes — Bing grounding, Azure AI Search, Logic Apps connectors — bills separately on top of that. This is a materially different cost shape from AWS’s AgentCore, which layers an explicit runtime surcharge on top of token costs; Foundry’s orchestration is free and the bill is almost entirely a function of model and tool choice.
4.3 Google Cloud: Agent Development Kit and the Gemini Enterprise Agent Platform
Google’s ADK is the most explicitly code-first of the major cloud frameworks, and the company has been candid in its own materials about positioning it that way relative to its other generative AI tooling: ADK is optimized for complex agents and multi-agent systems, providing higher-level abstractions for agent development with built-in integration for LiteLLM and Vertex AI Model Garden supporting a variety of models, in contrast to Google’s lower-level Genkit framework. The model-agnosticism is real and unusually thorough: beyond Gemini, ADK works with any model accessible via Vertex AI Model Garden, and LiteLLM integration extends that to Anthropic, Meta, Mistral AI, AI21 Labs, and many other providers. As of the Cloud Next 2026 rebrand, Claude’s Opus, Sonnet, and Haiku models are first-class citizens within Model Garden alongside Gemini and Llama, which is a meaningfully more open model-access posture than AWS’s Bedrock-first approach to AgentCore.
ADK’s multi-agent primitives map directly onto the taxonomy in section two: it natively supports composing specialized teams of agents that collaborate and delegate, offering both predictable pipelines through workflow agents — SequentialAgent and ParallelAgent as concrete, named classes — and adaptive, agent-coordinated dynamic routing for less predictable tasks. The tool ecosystem extends this further by letting other frameworks' agents — LangGraph graphs, CrewAI crews — be wrapped and used as tools from within an ADK agent, which is a pragmatic acknowledgment that teams rarely start from a clean slate.
The production path runs through Vertex AI Agent Engine, a fully managed, scalable runtime that Google explicitly frames as the last step in a development lifecycle that starts with sophisticated local prototypes and ends in robust, production-ready deployment. On pricing, Agent Engine charges per vCPU-hour for compute (roughly $0.0864 per vCPU-hour) plus separate, additive charges for session and memory storage (around $0.25 per 1,000 events) on top of whatever Gemini token costs the agent’s own reasoning consumes — and if the agent calls Vertex AI Search for retrieval, that’s a third additive line item again, in the $4 to $6 per 1,000 queries range. One detailed cost breakdown makes the compounding explicit: a single user interaction that retrieves documents, generates a response, maintains session state, and runs on Agent Engine can show up as four separate billing line items on one invoice, and at a daily volume of 100,000 queries that stacking stops being a rounding error. The June 2026 Cloud Next rebrand folded Agent Builder and the formerly separate Agentspace product into a single unified Gemini Enterprise Agent Platform, with existing customers explicitly told they don’t need to migrate anything — the underlying services are unchanged, only the name and packaging consolidated.
4.4 Databricks: Agent Bricks and the Supervisor Agent
Databricks occupies a structurally different position from the three hyperscalers above: it isn’t selling compute or a model API, it’s selling the proposition that agent quality is bottlenecked by data and evaluation, not by orchestration code. Agent Bricks, which launched in beta at the 2025 Data + AI Summit and matured into a comprehensive, generally-available platform by the 2026 edition, embodies that bet directly through its newest and most relevant piece for this paper: the Supervisor Agent, which reached general availability this spring specifically for orchestrating multiple agents and tools into a single workflow.
The Supervisor Agent’s actual mechanics are more concrete than “describe a task and Databricks handles it” suggests. A developer defines the task and connects the systems it should reach — Genie spaces for natural-language queries over Unity Catalog tables, Knowledge Assistant endpoints for document-grounded question answering, Unity Catalog functions for arbitrary registered code, and MCP servers pulled either from the Databricks Marketplace or configured against external endpoints — and the supervisor handles routing and synthesis across whichever of those the requesting user is actually authorized to reach. That authorization detail is not an afterthought: if an end user lacks access to any of the subagents a query would need, the supervisor ends the conversation rather than silently degrading, and if the user has access to some but not all relevant subagents, it redirects away from the ones they can’t reach rather than exposing that a restricted resource exists. For teams below the Supervisor Agent’s no-code threshold, there’s also a lower-level Supervisor API in beta — a single request to an OpenResponses-compatible endpoint that defines the model, tools, and instructions, after which Databricks runs the full agent loop, repeatedly calling the model, selecting and executing tools, and synthesizing the final response, while still giving the developer runtime control over model choice and per-request tool selection that the fully declarative Supervisor Agent doesn’t expose.
The adoption numbers Databricks reported at this year’s summit are large enough to take seriously as a market signal: over 100,000 agents built on the platform since launch, processing more than one quadrillion tokens per year, with named production customers including AstraZeneca, 7-Eleven, Fox Corporation, and Block. A customer testimonial from Hawaiian Electric makes the supervisor-versus-hand-built comparison concrete rather than abstract: Agent Bricks significantly outperformed their original open-source implementation built on LangChain in both LLM-as-judge and human evaluation accuracy metrics — though it’s worth flagging this is a vendor-published customer quote rather than an independently audited benchmark, and should be weighted accordingly rather than treated as a settled comparative result.
For multi-agent specifically, this puts Databricks in the most unusual position of any platform in this survey: every other platform treats orchestration as something a developer composes from exposed primitives, however high- or low-level those primitives are, while Databricks treats the orchestration topology itself as something the platform can generate and tune from a task description and a set of connected systems, with the actual coordination logic never directly written by a human at all in the fully declarative path.
4.5 Anthropic: Claude Agent SDK and Managed Agents
Anthropic’s framework has the most direct lineage to a production coding agent: the Claude Agent SDK was renamed from the Claude Code SDK in September 2025 and exposes the same harness that powers Claude Code, with subagents as a first-class primitive from the start. The SDK’s subagent model is built specifically around context isolation as a cost and quality lever: subagents can be spun up in parallel to handle distinct subtasks, each with its own isolated context window, returning only relevant summaries back to the orchestrating agent rather than flooding it with raw intermediate output.
The bigger development this year sits a layer above the SDK. Claude Managed Agents launched in public beta in April 2026 as a hosted harness handling secure sandboxing, credential management, durable session state, and persistent event history — explicitly replacing the need to build an agent loop from scratch — and then added three significant capabilities in May: Dreaming, a memory-consolidation mechanism that lets an agent improve between sessions by reading up to a hundred prior sessions; Outcomes, a self-grading loop that uses a dedicated evaluator agent rather than letting a generator grade its own work; and Multiagent Orchestration, a coordinator that fans tasks out to specialist subagents in parallel. The self-grading design choice deserves attention because it’s solving a specific, well-documented failure mode: separating evaluation into a dedicated agent eliminates the self-grade inflation problem where a generator rates its own output too favorably, a pattern Anthropic validated through a production architecture dividing work among a Planner agent for structure and goals, a Generator agent for execution, and an independent Evaluator agent that runs five to fifteen critique-and-refine cycles — sometimes spanning four hours — on genuinely hard creative or full-stack tasks. Anthropic’s own benchmark for this pattern reports roughly a ten-percentage-point improvement in task success rate over standard prompting on complex multi-step workflows.
A detail worth flagging precisely, because it’s easy to get backwards: subagents under this architecture do not share the lead agent’s accumulated reasoning by default, since each one has its own isolated context window, so context has to be passed explicitly through the shared filesystem or through event payloads rather than assumed to be implicitly available. Anthropic was unusually direct about why no new model accompanied these announcements at this year’s Code with Claude conference — the harness, not the frontier model, is now the more meaningful competitive battleground, with the framing offered being that Codex versus Claude Code is currently a more consequential contest than GPT versus Opus, because the scaffolding around a capable model is what determines whether it can actually be deployed reliably.
On cost, the SDK itself bills as standard API token usage with no separate runtime surcharge, while Managed Agents draws against a distinct monthly Agent SDK credit pool layered on top of subscription or API usage — a billing shape closer to OpenAI’s and Google’s per-token-plus-managed-feature model than to AWS’s explicit infrastructure surcharge.
4.6 OpenAI: Agents SDK and AgentKit
OpenAI’s framework is built around three tightly scoped primitives — agents, handoffs, and guardrails — rather than a general-purpose graph or pipeline abstraction, and the documentation is explicit that this is a deliberate choice: developers can drop down to the raw Responses API and own the loop themselves, or use the Agent-plus-Runner abstraction and let the SDK manage turns, tool calls, guardrails, handoffs, and session state. The handoff mechanism, covered in the orchestration taxonomy above, is the SDK’s signature multi-agent primitive, and OpenAI ships pre-built filtering utilities for the common case of stripping prior tool-call noise out of the conversation history before handing it to a new specialist.
The guardrail system is more granular than it first appears, and the distinctions matter for anyone building anything regulated. Tool guardrails apply only to custom function tools, run before and after each invocation, and explicitly do not cover the handoff call itself, since handoffs run through their own dedicated pipeline rather than the standard tool-call pipeline. Hosted tools — web search, file search, the hosted MCP tool, code interpreter, image generation — and built-in execution tools like computer use, shell access, and local shell similarly sit outside the standard guardrail pipeline, which means a team relying on tool guardrails for safety has to track, tool by tool, which categories are actually covered rather than assuming uniform coverage. OpenAI’s own guidance frames guardrails as one layer in a defense system that has to be paired with real authentication, authorization, and access controls — not a substitute for them.
AgentKit, the no-code-adjacent companion to the SDK, extends this stack toward business users and rapid prototyping, while the SDK itself remains the developer-facing layer for anyone building genuinely custom multi-agent logic — a split that roughly mirrors Google’s ADK-versus-Agent-Studio divide and Microsoft’s code-first-versus-declarative-YAML split within Semantic Kernel 1.0. On cost, the SDK is a pure pass-through on top of standard OpenAI API token pricing with no additional runtime fee for the orchestration layer itself, which puts it architecturally closer to Azure AI Foundry’s free-orchestration model than to AWS’s surcharge-bearing AgentCore.
4.7 NVIDIA: NeMo Agent Toolkit, OpenShell, and the Hardware-Adjacent Bet
NVIDIA’s entry into this space is structurally different from the others because NVIDIA isn’t trying to own the orchestration layer at all — it’s trying to make sure whichever orchestration layer wins runs efficiently on NVIDIA hardware and integrates cleanly with NVIDIA’s open model family. The NeMo Agent Toolkit is configured almost entirely through YAML — functions, LLMs, embedders, retrievers, and memory backends are each registered entities referenced from a single workflow definition — which makes swapping a model or a tool a one-line configuration change rather than a code change, and the toolkit ships a working nat run --config_file workflow.yml command-line entry point that takes a YAML file and an input string and executes the whole defined workflow. The example library that ships with the toolkit reads almost like a direct illustration of section two's taxonomy: a router_agent example that classifies incoming requests and routes them to the right branch, a sequential_executor that chains functions where each output feeds the next, a parallel_executor that fans out independent branches concurrently with partial-failure handling, and a hybrid_control_flow example demonstrating how to compose more than one of these patterns together in a single workflow.
The more strategically interesting move is the broader Agent Toolkit platform announced at GTC 2026, which bundles Nemotron — an open model family optimized specifically for agentic reasoning — with AI-Q, an open blueprint letting agents perceive, reason, and act on enterprise knowledge while automatically choosing the right data sources and depth of analysis, and OpenShell, an open-source runtime that enforces policy-based security and access controls for autonomous agents (which NVIDIA’s materials refer to as “claws”). The economic argument NVIDIA makes for this hybrid design is concrete: a frontier model handles high-level orchestration and reasoning while lighter, open Nemotron models do the heavy lifting on research and retrieval, and the result is reported as more than a fifty percent reduction in cost per query without sacrificing accuracy — a structurally different cost lever than anything else in this survey, since every other platform’s cost reduction options are about caching, batching, or model-tier selection within a single vendor’s catalog, not about routing different parts of one workflow to differently priced model families by design.
What makes this section of the survey unusual is the breadth of competing platform vendors NVIDIA has signed as partners rather than competitors: Salesforce is using the Agent Toolkit and Nemotron models inside Agentforce, SAP is using NeMo inside Joule Studio on its own Business Technology Platform, and LangChain — whose open-source frameworks have been downloaded over a billion times — is integrating AI-Q, OpenShell, and Nemotron into its own deep-agent library. NVIDIA’s pitch here is essentially horizontal: rather than asking enterprises to choose NVIDIA’s orchestration layer over Databricks’s or Microsoft’s, it’s positioning Nemotron and OpenShell as infrastructure that sits underneath whichever orchestration layer a customer has already chosen, deployable across AWS, Google Cloud, Azure, and Oracle Cloud Infrastructure.
4.8 Salesforce: Agentforce and Agent Script
Agentforce is the clearest example in this survey of a platform company building multi-agent orchestration specifically for its own application surface rather than as general-purpose infrastructure, and the most significant recent development here is Agent Script — a new, deliberately whitespace-sensitive, YAML-adjacent language for authoring agent behavior with the precision of code and the accessibility of structured configuration. The pitch is explicit and a little disarming for a platform historically associated with point-and-click configuration: if a developer can read YAML and write basic conditional logic, they can build an Agentforce agent directly in Agent Script rather than exclusively through the visual Agent Builder, and Salesforce offers three authoring methods on a deliberate skill-level gradient — natural-language description that gets auto-converted into topics, actions, and instructions; a visual block-based editor where Agent Script renders as expandable summarized blocks; and direct Agent Script authoring for developers who want full control.
The architecture this produces maps closely onto the handoff-network pattern from section two, with one meaningful deterministic addition. Agent Script is compiled into metadata consumed by Salesforce’s Atlas Reasoning Engine, and the engine’s core control-flow loop is explicitly stateful in a way pure LLM routing isn’t: after a subagent (the April 2026 rename of what were previously called topics) finishes responding to a request, the system returns to the start_agent classification point and waits for the next customer message before re-evaluating which subagent should handle it — meaning the routing decision is re-made every turn rather than locked in once a specialist takes over. The underlying reasoning engine itself claims a meaningful accuracy improvement from this more structured approach: NVIDIA-Nemotron-class benchmarking cited in third-party Salesforce developer analysis credits the Atlas Reasoning Engine's "System 2"-style inference loop with roughly a one-third accuracy improvement over conventional retrieval-augmented generation, though as with the Hawaiian Electric figure above, that number should be read as a vendor-adjacent claim rather than an independently reproduced benchmark.
Subagents connect to the Salesforce data model through Actions, which can be backed by Flows, Apex code, MuleSoft APIs, or prompt templates, and Salesforce’s own developer guidance is direct about treating these as software artifacts subject to the same engineering discipline as anything else on the platform: actions are the reason an agent should be thought of as a new type of application with a natural-language interface, not a fundamentally different category of artifact exempt from version control and review. The NVIDIA partnership described in section 4.7 extends this with a specific regulated-industry deployment model: Nemotron models can run on NVIDIA infrastructure inside a customer’s own security boundary, on-premises or in a tightly controlled private cloud, which lets a regulated financial-services customer run something like a compliance agent that reviews transactions, applies policy rules, and surfaces risk signals inside a secure Slack channel without sending data outside its own perimeter.
This is worth contrasting directly with the AWS, Microsoft, and Google entries above. Agentforce isn’t competing to be the orchestration layer a developer builds custom logic on top of — it’s competing to be the agent platform that ships pre-integrated with the CRM and support data Salesforce customers already have, where the orchestration logic is largely configured, and increasingly scripted in a deterministic DSL, rather than assembled from general-purpose code. That’s a legitimate and often underrated strategy for the large population of enterprises whose actual constraint is data integration and governance approval, not orchestration framework expressiveness.
5. Structured Comparison
Mapping all eight platforms onto the five-plane architecture from section three produces the comparison in Figure 1, organized along two axes that matter more than any feature checklist: how much of the runtime the vendor manages for you, and how much code-level control you retain over agent behavior versus configuring it declaratively.
A few patterns are visible in this layout that aren’t visible in a feature-by-feature table. The upper-left quadrant — self-hosted frameworks with high code-level control — is where LangGraph, CrewAI, and the Claude Agent SDK and OpenAI Agents SDK as standalone harnesses cluster. These give a team maximum portability and the steepest engineering burden, and they’re the right choice when the orchestration logic itself is the differentiated asset a team is building. The lower-right quadrant — managed, declarative, high-abstraction — is where Databricks Agent Bricks and Salesforce Agentforce sit, optimized for teams whose real bottleneck is the ninety-nine percent Databricks describes rather than the orchestration code itself. The upper-right quadrant, interestingly, is where the newest entrants are converging: Claude Managed Agents and the cloud-provider agent services (Bedrock AgentCore, Azure AI Foundry Agent Service, Vertex AI Agent Engine) are all racing toward managed runtimes that still expose code-level configuration, which is the position every major vendor seems to believe is the actual center of enterprise demand — full control without owning the operational burden.
This same eight-platform set, however, also sorts cleanly into three architectural families that the landscape diagram doesn’t surface directly because it’s organized by abstraction level rather than by where the orchestration logic originates. AWS, Azure, and NVIDIA are bring-your-own-framework runtimes: each explicitly positions itself as infrastructure underneath orchestration logic the developer still writes in LangGraph, CrewAI, the Microsoft Agent Framework, or any other framework of choice — the runtime’s job is hosting, identity, memory, and observability, not deciding how agents coordinate. Databricks and Salesforce are declarative supervisor platforms: in both cases, the orchestration topology itself is generated from a description and a set of connected systems, with the platform — not a developer — producing the actual coordination logic, and natural-language or Agent Script authoring sitting above that generation step. Anthropic, OpenAI, and Google occupy a third position worth calling harness-native: in each case the orchestration primitives (subagents, handoffs, ADK’s workflow agent classes) are part of the SDK itself, neither a separate infrastructure layer purchased on top of self-written logic nor a fully generated topology, but a fixed, opinionated set of coordination primitives a developer composes directly. That three-way split is arguably a more useful first filter for a build-versus-buy decision than the eight-vendor list, because it answers the question “who is actually deciding how my agents coordinate” before any feature comparison even starts.
The protocol layer cuts across all three families in a way Figure 1 can’t show directly: MCP and A2A support is now effectively universal across every platform surveyed, which means the portability axis is less binary than it looks. A team building on a managed, high-abstraction platform on the right side of Figure 1 can still keep its tool integrations and cross-agent communication portable by routing them through MCP and A2A rather than a vendor-proprietary equivalent — meaning the real lock-in risk concentrates specifically in the coordination-plane logic and the substrate plane underneath it, not in the protocol boundary between agents and their tools.
Cost structure is the axis the original version of this paper left out almost entirely, and Figure 8 corrects that with what published pricing actually allows — which is closer to a structural comparison than a literal one, since none of these vendors price multi-agent workloads with directly comparable units.
Three structural patterns are visible even without literal dollar comparability. First, AWS is the only major cloud provider charging an explicit, separately-named runtime surcharge on top of model tokens for AgentCore; Azure and OpenAI both keep orchestration nominally free and let the bill be almost entirely a function of model and tool token consumption, which is a materially friendlier cost shape for a team running high agent-call volumes with relatively light per-call reasoning. Second, Google’s Agent Engine pricing is the most fragmented of the eight, billing compute, session storage, and search retrieval as three additive line items before a single model token is counted, which the cost breakdown cited in section 4.3 shows compounding into four separate billing events for one user interaction. Third, Salesforce is the only platform in the survey where the dominant cost is a platform or seat fee rather than a token-metered charge at all, which is the clearest evidence that Agentforce is being sold as application software with an AI feature inside it, not as AI infrastructure with an application bolted on top — consistent with the architectural-family classification two paragraphs above.
6. Worked Implementation: A Four-Agent Insurance Intake System, Eight Ways
To make the comparison concrete rather than descriptive, this section implements the same multi-agent system on every platform surveyed. The motivating problem is the one described in section three: a single agent handling document extraction, coverage verification, and fraud detection saw its system prompt grow to thousands of tokens, lost attention to instructions buried in the middle of that prompt, and degraded in tool-selection accuracy as its toolset grew past sixteen options. The fix, on every platform below, is the same: decomposition into bounded specialist agents — an intake agent, a coverage agent, and a fraud agent — coordinated so that coverage verification and fraud assessment run in parallel once a structured claim object exists, then synthesized into a final decision. Figure 4 shows the shared request lifecycle every implementation below is realizing in its own platform’s idiom.
Figure 9 gives the structural shape of each of the eight implementations side by side before the code itself, since the differences in how coordination is expressed are often more legible as a diagram than as a paragraph of prose.
What should jump out from Figure 9 even before reading any code: AWS, Azure, Google, and NVIDIA all draw as some variant of an orchestrator node with arrows to specialist nodes underneath it — a topology any of these four could swap into any of the others with moderate effort. Databricks and Salesforce draw with a supervisor or classification node whose downstream connections are existing platform-native resources (a Genie space, a Knowledge Assistant, a CRM action) rather than freshly written agents — the coordination logic in both cases is closer to “wire up what already exists” than “write new orchestration code.” And Anthropic’s and OpenAI’s diagrams are visibly the least hierarchical of the eight: subagents and handoff targets sit at nearly the same structural level as the orchestrator, reflecting that both frameworks treat the lead agent and the specialists it dispatches to as peers exchanging structured handoffs or summaries, not a supervisor issuing commands to subordinates.
6.1 AWS: Step Functions coordinating Bedrock AgentCore agents
The coordination plane is a deterministic Step Functions state machine — not a fifth LLM acting as router — because for a regulated domain like insurance, a regulator who asks how a claim decision was made needs an answer that doesn’t depend on reconstructing an LLM’s reasoning after the fact. The workflow engine controls what runs and when and how errors are handled; the agents handle how, applying reasoning only within their bounded domain.
{
"Comment": "Four-agent insurance intake workflow",
"StartAt": "ExtractAndClassify",
"States": {
"ExtractAndClassify": {
"Type": "Task",
"Resource": "arn:aws:states:::bedrock:invokeAgent",
"Parameters": {
"AgentId": "${IntakeAgentId}",
"AgentAliasId": "${IntakeAgentAlias}",
"SessionId.$": "$.claimId",
"InputText.$": "$.rawSubmission"
},
"ResultPath": "$.structuredClaim",
"Next": "VerifyAndAssess",
"Retry": [{
"ErrorEquals": ["Bedrock.ThrottlingException"],
"IntervalSeconds": 2, "MaxAttempts": 4, "BackoffRate": 2.0
}]
},
"VerifyAndAssess": {
"Type": "Parallel",
"Branches": [
{ "StartAt": "VerifyCoverage", "States": { "VerifyCoverage": {
"Type": "Task", "Resource": "arn:aws:states:::bedrock:invokeAgent",
"Parameters": { "AgentId": "${CoverageAgentId}", "AgentAliasId": "${CoverageAgentAlias}",
"SessionId.$": "$.claimId", "InputText.$": "$.structuredClaim" },
"End": true } } },
{ "StartAt": "AssessFraudRisk", "States": { "AssessFraudRisk": {
"Type": "Task", "Resource": "arn:aws:states:::bedrock:invokeAgent",
"Parameters": { "AgentId": "${FraudAgentId}", "AgentAliasId": "${FraudAgentAlias}",
"SessionId.$": "$.claimId", "InputText.$": "$.structuredClaim" },
"End": true } } }
],
"ResultPath": "$.parallelResults",
"Next": "SynthesizeDecision"
},
"SynthesizeDecision": {
"Type": "Task", "Resource": "arn:aws:states:::lambda:invoke",
"Parameters": { "FunctionName": "${SynthesisFunctionArn}",
"Payload": { "coverage.$": "$.parallelResults[0]",
"fraud.$": "$.parallelResults[1]", "claimId.$": "$.claimId" } },
"End": true
}
}
}Each agent is hosted on AgentCore Runtime with a narrowly scoped toolset:
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from bedrock_agentcore.tools import mcp_gateway_tool
app = BedrockAgentCoreApp()
@app.entrypoint
def invoke(payload, context):
claim = payload["structuredClaim"]
policy_record = mcp_gateway_tool("fetch_policy_record", policy_number=claim["policyNumber"])
determination = app.model.generate(
system="You are a coverage verification specialist. You have exactly four "
"tools. Determine policy status, peril coverage, deductible, and limit.",
tools=["fetch_policy_record", "check_peril_coverage",
"calculate_deductible", "lookup_coverage_limit"],
input=f"Claim: {claim}\nPolicy: {policy_record}",
response_format="structured",
)
return determinationThe synthesis step deliberately runs as a plain Lambda function, not a fifth agent — combining a coverage determination and a fraud score into a final outcome is the kind of logic that should be deterministic code with unit tests, not a model call, whenever the combination rule itself is simple and auditable. The Retry block on the first state is not boilerplate either: throttling exceptions are the most common production failure mode for Bedrock-backed agents under load, and a state machine without retry logic surfaces a transient capacity issue as a hard failure to the end user.
6.2 Azure: a heterogeneous team under Foundry Agent Service
The same three specialist agents, deliberately built on three different frameworks to demonstrate Foundry’s stated heterogeneity claim, coordinated through a Foundry multi-agent workflow:
# foundry-workflow.yaml — multi-agent insurance intake
workflow:
name: insurance-intake
trigger: api
steps:
- id: extract_and_classify
agent: intake_agent # built on Semantic Kernel
input: "{{ trigger.rawSubmission }}"
output_as: structuredClaim
- id: verify_and_assess
parallel:
- id: verify_coverage
agent: coverage_agent # built on AutoGen (Microsoft Agent Framework)
input: "{{ steps.extract_and_classify.output }}"
- id: assess_fraud
agent: fraud_agent # hosted agent, built on LangGraph, run in
# a Foundry-managed container
input: "{{ steps.extract_and_classify.output }}"
- id: synthesize
type: function
function: synthesize_decision
input:
coverage: "{{ steps.verify_and_assess.verify_coverage.output }}"
fraud: "{{ steps.verify_and_assess.assess_fraud.output }}"
# coverage_agent.py — built on Semantic Kernel 1.0, declarative front matter
from semantic_kernel.agents import ChatCompletionAgent
from semantic_kernel.functions import KernelFunctionFromPrompt
coverage_agent = ChatCompletionAgent(
name="coverage_agent",
instructions=(
"You verify auto insurance coverage. You have exactly four tools: "
"fetch_policy_record, check_peril_coverage, calculate_deductible, "
"lookup_coverage_limit. Return a structured determination."
),
plugins=[PolicyLookupPlugin()], # plugin wraps the four bounded tools
)Every agent’s traces, regardless of which framework authored it, surface on the same Foundry dashboard with shared latency and token metrics, and each agent’s output can carry an Agent Confidence Score derived from its historical accuracy on similar claims — the governance layer Microsoft has built specifically because heterogeneous teams make “which agent is actually reliable” harder to answer by inspection alone.
6.3 Google: a single ADK process composing agents as tools
ADK expresses the same workflow as Python objects inside one process, using SequentialAgent and ParallelAgent as literal composition primitives rather than an external state machine:
from google.adk.agents import LlmAgent, SequentialAgent, ParallelAgent
intake_agent = LlmAgent(
name="intake_agent", model="gemini-2.5-pro",
instruction="Extract and classify the claim into a structured object.",
tools=[extract_claim_fields],
)
coverage_agent = LlmAgent(
name="coverage_agent", model="gemini-2.5-pro",
instruction="Verify policy coverage. You have exactly four tools.",
tools=[fetch_policy_record, check_peril_coverage,
calculate_deductible, lookup_coverage_limit],
)
fraud_agent = LlmAgent(
name="fraud_agent", model="claude-sonnet-4-6", # via Model Garden / LiteLLM
instruction="Assess fraud risk from claim patterns and history.",
tools=[check_claim_history, flag_anomalies],
)
verify_and_assess = ParallelAgent(
name="verify_and_assess",
sub_agents=[coverage_agent, fraud_agent],
)
root_agent = SequentialAgent(
name="insurance_intake",
sub_agents=[intake_agent, verify_and_assess, synthesis_agent],
)The notable detail is the fraud_agent's model line: because ADK is model-agnostic through Vertex AI Model Garden and LiteLLM, nothing about the orchestration code above changes if that agent runs on Claude instead of Gemini — the same root_agent composition holds regardless of which model backs which sub-agent, which is the most direct illustration in this entire worked example of what "model-agnostic orchestration" actually buys a team in practice.
6.4 Databricks: declaring the supervisor rather than writing it
Where the first three platforms required writing orchestration code, Databricks’s Supervisor Agent is configured, not programmed — though the underlying Supervisor API is available for teams that want the agent loop managed but the configuration done in code:
from databricks.agents import SupervisorAgent
supervisor = SupervisorAgent.create(
name="insurance-intake-supervisor",
description="Routes auto insurance claims through coverage and fraud review.",
instructions=(
"For each incoming claim, extract structured fields, then check "
"coverage and fraud risk. Only surface subagents the requesting "
"user has permission to reach."
),
subagents=[
{"type": "genie_space", "name": "policy_lakehouse", "space_id": "policies-uc"},
{"type": "knowledge_assistant", "name": "coverage_ka", "endpoint": "coverage-ka-endpoint"},
{"type": "uc_function", "name": "fraud_score", "function": "risk.fraud_score"},
],
)
# Databricks deploys this as an HTTP endpoint; MLflow traces every
# model call and tool execution in the resulting conversation automatically.There is no synthesis step to write, because the supervisor itself performs the final synthesis across whichever subagents it routed to — and there is no access-control logic to write either, because On-Behalf-Of-User authorization is a platform feature applied automatically, not something the developer implements per agent. The tradeoff this implementation makes visible directly: every other platform in this section gives a developer something to read and version-control as the actual coordination logic; the Databricks version’s “coordination logic” is largely the instructions string and the list of connected systems, with Databricks's own optimization loop responsible for the routing behavior that produces.
6.5 Anthropic: a lead agent with parallel, context-isolated subagents
from claude_agent_sdk import query, AgentDefinition
coverage_subagent = AgentDefinition(
name="coverage-agent",
prompt="Verify coverage for this claim. You have exactly four tools.",
tools=["fetch_policy_record", "check_peril_coverage",
"calculate_deductible", "lookup_coverage_limit"],
)
fraud_subagent = AgentDefinition(
name="fraud-agent",
prompt="Assess fraud risk for this claim using historical patterns.",
tools=["check_claim_history", "flag_anomalies"],
)
async for message in query(
prompt=f"Process this insurance claim end to end: {raw_submission}",
options={
"subagents": [coverage_subagent, fraud_subagent],
"max_parallel_subagents": 2,
},
):
# The lead agent dispatches both subagents in parallel once it has
# extracted a structured claim object. Each subagent runs in its own
# isolated context window; results return as summaries, not full
# transcripts, and the lead agent synthesizes the final decision
# in its own context rather than delegating synthesis to a third agent.
handle_stream_event(message)The structural difference from the AWS and Azure versions is that there’s no separate orchestrator artifact at all — the lead agent’s own reasoning, inside a single query() call, is the coordination plane. That's a meaningfully smaller surface area to write and maintain, at the cost of the coordination logic being implicit in a prompt rather than explicit in a state machine a non-engineer could audit line by line — the same auditability tradeoff flagged in section 6.1's justification for AWS's deterministic state machine, pointing in the opposite direction here.
6.6 OpenAI: triage and handoff between peer agents
from agents import Agent, Runner, handoff
coverage_agent = Agent(
name="Coverage Agent",
instructions="Verify policy coverage. You have exactly four tools.",
tools=[fetch_policy_record, check_peril_coverage,
calculate_deductible, lookup_coverage_limit],
)
fraud_agent = Agent(
name="Fraud Agent",
instructions="Assess fraud risk using claim history and anomaly detection.",
tools=[check_claim_history, flag_anomalies],
)
triage_agent = Agent(
name="Claim Triage Agent",
instructions="Extract claim details, then hand off to Coverage Agent "
"and Fraud Agent as appropriate.",
handoffs=[
handoff(coverage_agent),
handoff(fraud_agent),
],
)
result = await Runner.run(triage_agent, input=raw_submission)Because a handoff transfers the full conversation rather than a summary, the coverage_agent and fraud_agent above each see the entire intake conversation as if they had been present from the start, which removes the lead agent having to explicitly repackage context for each specialist — at the cost of every specialist's context window carrying the full history rather than a curated subset, the inverse of the Claude Agent SDK's isolated-context design in section 6.5. Input guardrails here would wrap only triage_agent as the first agent in the chain; output guardrails would wrap whichever of the two specialists produces the actual final response the caller sees.
6.7 NVIDIA: a parallel-executor workflow over open and frontier models
# workflow.yml — NeMo Agent Toolkit
llms:
frontier_llm:
_type: openai
model_name: gpt-4.1 # orchestration and synthesis
nim_llm:
_type: nim
model_name: nvidia/nemotron-4-340b-instruct # research/retrieval, lower cost
functions:
extract_and_classify:
_type: llm_function
llm_name: frontier_llm
description: "Extract structured claim fields from raw submission"
coverage_check:
_type: llm_function
llm_name: nim_llm
description: "Check policy coverage, deductible, and limit"
tools: [fetch_policy_record, check_peril_coverage, calculate_deductible]
fraud_check:
_type: llm_function
llm_name: nim_llm
description: "Assess fraud risk from claim history"
tools: [check_claim_history, flag_anomalies]
synthesize_decision:
_type: llm_function
llm_name: frontier_llm
description: "Combine coverage and fraud outputs into a final decision"
workflow:
_type: hybrid_control_flow
steps:
- sequential: [extract_and_classify]
- parallel_executor:
branches: [coverage_check, fraud_check]
merge_with: synthesize_decision
nat run --config_file workflow.yml --input "$(cat claim_submission.json)"The cost argument NVIDIA makes in section 4.7 is visible directly in this configuration: orchestration and final synthesis run on the frontier model (frontier_llm), where reasoning quality matters most, while the two specialist checks that mostly involve structured lookups and pattern matching run on the open Nemotron model (nim_llm) at a fraction of the per-token cost — a routing decision made explicit in the YAML rather than buried in code, and swappable to a different model pairing with a one-line edit rather than a rewrite.
6.8 Salesforce: Agent Script with deterministic transitions
# ============================================
# SYSTEM CONFIGURATION
# ============================================
system:
instructions: |
You are an intake assistant for Coral Insurance auto claims.
Be precise. Never fabricate a coverage determination.
# ============================================
# TOPIC: Coverage Verification
# ============================================
subagent coverage_verification:
description: "Verify coverage, deductible, and limit for an auto claim"
actions:
- fetch_policy_record # Apex action → Data 360
- check_peril_coverage # Apex action → Data 360
- calculate_deductible # Flow action
instructions: |
Given a structured claim, determine coverage status. Use only the
four actions available to this subagent.
# ============================================
# TOPIC: Fraud Assessment
# ============================================
subagent fraud_assessment:
description: "Assess fraud risk for an auto claim"
actions:
- check_claim_history # MuleSoft API action
- flag_anomalies # Apex action
# ============================================
# CONTROL FLOW
# ============================================
start_agent:
classify_intent: |
if claim.status == "new":
transition coverage_verification
transition fraud_assessment # both run, results merge before reply
else:
respond "This claim has already been processed."The deterministic if/transition block at the bottom is the detail that distinguishes Agent Script from a pure LLM-routed handoff network like OpenAI's: the decision to invoke both subagents for a new claim is a hard-coded rule the Atlas Reasoning Engine cannot reason its way around, not a probabilistic routing choice — the same deterministic-coordination argument made for AWS's Step Functions in section 6.1, expressed here in a domain-specific language that a less code-fluent Salesforce admin could still read and modify directly.
6.9 What the eight implementations show in aggregate
Lined up against each other, the eight implementations validate the three-family split proposed in section five more concretely than the abstract argument did on its own. The AWS, Azure, and NVIDIA versions all required writing genuinely new orchestration artifacts — a state machine, a workflow YAML, a hybrid-control-flow config — that exist as separate, inspectable files a reviewer could read without touching the agents themselves. The Databricks and Salesforce versions, by contrast, required almost no orchestration code at all in the strict sense: the Supervisor Agent’s configuration and Agent Script’s subagent declarations are closer to manifests than programs, with the actual routing behavior produced by the platform rather than authored directly — though Agent Script’s deterministic transition block shows that "declarative" and "rule-based" aren't synonyms, since that one line behaves identically to AWS's deterministic state machine despite living in a fundamentally different authoring paradigm. And the Anthropic and OpenAI versions are the shortest of the eight by a wide margin, because in both cases the SDK's own primitives — subagent dispatch, handoff — are doing work that every other platform required an explicit, separate orchestration artifact to express.
The portability claim from section three holds up under this test, with one caveat worth stating precisely. The tool-calling functions referenced across all eight implementations — fetch_policy_record, check_peril_coverage, check_claim_history, and so on — could be implemented once as MCP-exposed tools and pointed to from any of the eight orchestration layers above with no change to the tool implementations themselves, which is the practical payoff of building the protocol plane on an open standard rather than each platform's native tool format. What doesn't transfer for free is the orchestration logic itself: porting the AWS Step Functions definition to Azure's workflow YAML, or to NVIDIA's hybrid-control-flow config, requires rewriting the coordination artifact in the target platform's syntax even though the underlying topology — sequential intake, parallel verification, synthesis — is identical across all eight. That is the precise, mechanical version of the claim made more loosely in the original draft of this paper: the protocol plane is portable; the coordination plane is not, even when the pattern it implements is the same pattern everywhere.
7. Discussion: Where the Real Decisions Are
Pulling the survey, the structured comparison, and the eight-way implementation together, a few conclusions hold up better than a simple “which vendor wins” framing would suggest.
The orchestration-pattern layer is close to fully commoditized. Every platform surveyed implements sequential, parallel, hierarchical, and handoff topologies, under different names, with different ergonomics, but with no platform offering a coordination pattern genuinely unavailable elsewhere — and section six’s eight parallel implementations confirm this isn’t just true in the abstract; the same insurance-intake topology was realizable, without modification to its actual coordination structure, on every single platform surveyed. Choosing a framework primarily because of its pattern vocabulary is choosing on the least differentiated axis available.
The actual differentiation is concentrated in four places, one more than the original version of this paper identified. How much of the “hidden 99%” the platform absorbs is the first and most consequential: Databricks’s explicit bet, and increasingly Anthropic’s and AWS’s as well, with Dreaming, Outcomes, and AgentCore’s governance layer all targeting exactly this. How open the model-access layer is, is the second: Google’s ADK and NVIDIA’s Nemotron-plus-frontier hybrid model are notably more open than AWS’s Bedrock-centric AgentCore, and section 6.3’s worked example shows concretely what that openness buys — swapping a sub-agent’s model from Gemini to Claude inside the same ADK composition with zero change to the orchestration code around it. How committed the vendor is to standing on the shared protocol layer rather than a proprietary alternative is the third, and all eight platforms surveyed have now adopted MCP, A2A, or both, which suggests this question is closer to settled than the other three. And cost structure — the dimension this revision adds explicitly through Figure 8 — is the fourth: AgentCore’s explicit runtime surcharge, Vertex AI Agent Engine’s four-line-item billing fragmentation, Foundry and the OpenAI Agents SDK’s free-orchestration-plus-token-pricing model, and Agentforce’s seat-and-platform-fee structure are four genuinely different economic shapes that produce very different total costs depending on call volume, reasoning depth per call, and how many separate billable services a given workflow actually touches.
The bounded-toolset finding deserves to be treated as closer to a hard constraint than a best practice, and every one of the eight implementations in section six was built around it deliberately — no agent above carries more than four tools. Two independently authored production accounts converged on the same three-to-five-tool ceiling per agent from different systems and different vendors’ infrastructure, and the underlying mechanism — attention degradation across long prompts, and a roughly monotonic decline in tool-selection accuracy as the candidate set grows — is mechanistically plausible enough that teams should treat “how many tools does this agent actually need” as a first-order design question, not something to defer until after a monolithic agent has already started failing in production.
The three-family architectural split from section five — bring-your-own-framework runtimes, declarative supervisor platforms, and harness-native frameworks — is the single addition in this revision most likely to change an actual build decision, because it reframes the question away from “which of eight vendors” toward “which of three relationships to the orchestration logic itself does our team actually want.” A team that wants full authorship of and accountability for its coordination logic, with the platform vendor responsible only for hosting it reliably, belongs in the first family regardless of cloud preference. A team whose real bottleneck is integration and governance overhead, not coordination logic sophistication, is better served accepting a generated topology from the second family even if that topology is less inspectable. And a team that wants the coordination primitives themselves to be opinionated and battle-tested rather than something to design from scratch belongs in the third family, accepting the SDK’s fixed vocabulary of subagents or handoffs as the ceiling of what the system will express.
Finally, the protocol convergence around MCP and A2A remains the most underappreciated development covered in this paper, precisely because it’s the least flashy, and section six’s portability test gives it the sharpest possible confirmation: the tool layer ported across all eight platforms with no changes; the orchestration layer did not port at all, in any of the eight cases, without a full rewrite in the target platform’s idiom. A market this competitive rarely produces this much voluntary, cross-vendor agreement on shared infrastructure, and the practical consequence for anyone building today is that the coordination-plane and substrate-plane choices in Figure 1 are far more reversible than they look, provided the tool and inter-agent boundaries are built on the open protocols rather than a vendor-specific equivalent. That is the architectural decision most worth getting right at the start, because unlike the choice of orchestration framework — which section six now shows costs a full rewrite to change — it is the one least likely to be expensive to unwind later.
References
Anthropic. “Code with Claude 2026.” Developer conference announcements, May 2026.
AWS. “Build a multi-agent architecture with Amazon Bedrock AgentCore, MCP, and AWS Step Functions.” AWS technical blog, May 2026.
AWS. “Build highly scalable serverless LangGraph multi-agent systems in AWS with Amazon Bedrock AgentCore.” AWS Machine Learning blog.
AWS Solutions Library. “Guidance for Multi-Agent Orchestration Using Bedrock AgentCore on AWS.” GitHub, February 2026.
Azure. “Azure AI Foundry Agent Service — Pricing.” Microsoft Azure, accessed June 2026.
Azure. “Foundry Agent Service — Pricing.” Microsoft Azure, accessed June 2026.
CloudZero. “Google Vertex AI Pricing: Complete Enterprise Guide (2026).” May 2026.
Databricks. “Agent Bricks: Data + AI Summit 2026.” Databricks blog, June 2026.
Databricks. “Agent Bricks: The governed enterprise agent platform.” Databricks blog, April 2026.
Databricks. “Databricks Launches Agent Bricks: A New Approach to Building AI Agents.” Press release, June 2025.
Databricks Developer Documentation. “Use Supervisor Agent to create a coordinated multi-agent system.” Accessed June 2026.
Databricks Developer Documentation. “Supervisor API (Beta).” Accessed June 2026.
Google. “Agent Development Kit: Making it easy to build multi-agent applications.” Google Developers Blog.
Google Cloud. “Agent Development Kit | Gemini Enterprise Agent Platform.” Documentation, last updated June 2026.
Hidekazu Konishi. “Amazon Bedrock AgentCore Implementation Guide Part 4: Multi-Agent Orchestration.” March 2026.
Kovil AI. “Azure AI Foundry Pricing Guide 2026: What Enterprise AI Actually Costs.” May 2026.
Linux Foundation. “A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms.” Press release, April 2026.
Linux Foundation. “Linux Foundation Announces the Formation of the Agentic AI Foundation.” Press release, February 2026.
Microsoft Azure. “Introducing Microsoft Agent Framework.” Azure Blog, October 2025.
Microsoft Foundry. “Build and run agents at scale with Microsoft Foundry at Build 2026.” Foundry Blog, June 2026.
Microsoft Learn. “Implement Advanced Multi-Agent Orchestration Patterns in Microsoft Foundry.” Training module.
NVIDIA. “NVIDIA Ignites the Next Industrial Revolution in Knowledge Work With Open Agent Development Platform.” NVIDIA Newsroom, March 2026.
NVIDIA Developer Documentation. “NeMo Agent Toolkit — Workflow Configuration.” Accessed June 2026.
NVIDIA Developer Documentation. “NeMo Agent Toolkit — Overview.” Accessed June 2026.
OpenAI. “New tools for building agents.” OpenAI announcement.
OpenAI. “Agents SDK — Guardrails and Handoffs.” Developer documentation.
Salesforce Developers. “Agentforce APIs and SDKs | Agentforce Developer Guide.” Accessed June 2026.
Salesforce Developers. “Agentforce Guide to Context Engineering.” Accessed June 2026.
SFDC Developers. “Agentforce Custom Actions: Apex & Metadata Guide.” February 2026.
Panther Schools. “Building Agentforce Agents with Agent Script.” March 2026.
Wikipedia. “Agent2Agent.” Accessed June 2026.
This paper is part of Vector1 Research’s ongoing series on agentic AI architecture and multi-agent orchestration, building on prior installments covering orchestration patterns, the Model Context Protocol, and AWS-specific agent frameworks. This is a substantially expanded second revision of the original draft, adding internal-architecture diagrams for AgentCore and the Microsoft Agent Framework, a protocol-composition diagram for MCP and A2A, a published-pricing cost-structure comparison, and a full eight-platform pseudocode implementation of the worked example in place of the original single-platform version.
