Executive Summary
A2A, or Agent2Agent, is an open standard for communication and interoperability between independent, potentially opaque AI agent systems. The official A2A specification says its primary goals include capability discovery, modality negotiation, collaborative task management, and secure information exchange without requiring agents to expose internal state, memory, or tools.
MCP, or Model Context Protocol, standardizes how AI applications connect to external tools, resources, prompts, and contextual systems. Its official architecture documentation defines an MCP Host, MCP Client, and MCP Server model, with a JSON-RPC data layer and transports such as stdio and Streamable HTTP. Since revision 2026-07-28 the protocol is stateless: there is no initialize handshake and no session.
OpenWOP, or Open Workflow Orchestration Protocol, is an open, vendor-neutral wire protocol for durable multi-agent workflow orchestration. Its documentation describes a system where clients start workflow runs, stream run events, pause for human checkpoints, replay history, use signed webhooks, and preserve portability across compliant hosts.
Most important architectural takeaway: these are not direct substitutes. A2A is the horizontal agent-to-agent layer. MCP is the vertical agent-to-tool/context layer. OpenWOP is the durable workflow-control layer that can orchestrate agents, tools, humans, events, and replayable state.
| Question | A2A | MCP | OpenWOP |
|---|---|---|---|
| Primary purpose | Agent-to-agent collaboration | Connect AI apps to tools, data, prompts, and context | Durable multi-agent workflow orchestration |
| Core unit | Task | Tool/resource/prompt interaction over an MCP session | Run |
| Main discovery object | Agent Card | server/discover plus primitive lists such as tools/list, resources/list, and prompts/list | Host capability document and workflow catalog |
| Best mental model | “Ask another agent to do something.” | “Give the model/app safe, structured access to external capabilities.” | “Run and observe a durable workflow.” |
| Primary boundary | Between independent agents | Between AI host application and context/tool servers | Between workflow client and workflow host |
| Internal execution visibility | Intentionally opaque | Visible at tool/resource/prompt-call level, not full workflow orchestration | First-class: events, traces, replay, artifacts, checkpoints |
Protocol Purpose and Scope
A2A: inter-agent collaboration
A2A solves the problem of independent agents discovering each other, exchanging messages, delegating work, and reporting task progress across framework, vendor, and language boundaries.
Its target users are agent platforms, agent marketplaces, enterprise automation systems, and specialist agents that need to collaborate without exposing internals.
MCP: tool and context integration
MCP solves the problem of connecting AI applications to external context providers and action surfaces through a shared protocol for tools, resources, prompts, notifications, and elicitation. Revision 2026-07-28 deprecates sampling, roots, and logging; they keep working through a deprecation window of at least twelve months.
Its target users are AI app developers, tool providers, IDEs, data platforms, SaaS integrations, local automations, and agent frameworks that need a standardized integration surface.
OpenWOP: durable workflow control
OpenWOP solves the problem of portable AI workflow execution: how to start, stream, interrupt, resume, replay, observe, and validate long-running multi-agent workflows.
Its target users are workflow authors, host implementers, pack authors, debuggers, evaluators, and enterprise platforms that need durable orchestration semantics.
Assumptions about the surrounding ecosystem
| Protocol | Assumptions |
|---|---|
| A2A | Multiple autonomous or semi-autonomous agents exist behind endpoints; callers should not need to know the remote agent's memory, plans, tools, or implementation. |
| MCP | AI applications need access to changing external context and actions; tool/resource providers should expose capabilities through a common client-server protocol rather than bespoke integrations. |
| OpenWOP | AI applications increasingly need durable, replayable, observable, multi-step workflows; workflow hosts should expose a common wire contract even if runtimes differ. |
Architectural Models
A2A architecture
A2A uses a remote-agent model. An A2A client discovers an A2A server through an Agent Card, sends a message, receives either a direct message or a task, and then follows task status, artifacts, streaming events, or push notifications.
- status updates
- artifacts
- messages
MCP architecture
MCP uses a host-client-server model. The host is the AI application. The MCP client is the connection manager inside that host. The MCP server exposes context or capabilities such as tools, resources, and prompts. The MCP data layer uses JSON-RPC, while the transport layer supports stdio for local process communication and Streamable HTTP for remote server communication. Revision 2026-07-28 removed the initialize handshake and protocol-level sessions. Every request now carries its protocol version and client capabilities in _meta, and every server MUST implement server/discover to advertise its versions, capabilities, and identity. A server that needs state across calls mints an explicit handle and passes it as an ordinary tool argument.
- APIs
- databases
- filesystems
- SaaS apps
- services
OpenWOP architecture
OpenWOP uses a workflow-host model. A client starts a run against a compliant host. The host executes a declarative workflow, emits events, may suspend for human input or approval, streams state over SSE, sends signed webhooks, and can support replay or fork behavior.
- SSE
- Webhooks
- OpenTelemetry
- Humans
- tools
- agents
- workers
- subflows
- artifacts
| Architecture concern | A2A | MCP | OpenWOP |
|---|---|---|---|
| Core entities | Client, server/remote agent, Agent Card, Message, Task, Artifact, Part | Host, client, server, tools, resources, prompts, elicitation, notifications; tasks via the Tasks extension (sampling, roots, and logging are deprecated as of revision 2026-07-28) | Client, host, workflow, run, event log, node, artifact, interrupt, pack |
| Communication pattern | Message/task exchange with streaming and push options | JSON-RPC over stdio or Streamable HTTP | REST run control, SSE event streams, signed webhooks; A2A and MCP are compositions over that wire, each advertised by its own facet (gRPC is an unadvertisable v2 extension, not part of the core wire) |
| Discovery | Well-known Agent Card | server/discover plus primitive list calls | Well-known host capability document plus workflow catalog |
| Lifecycle | Task state machine | Stateless requests, each carrying its protocol version and capabilities; primitive discovery, calls, notifications; with the Tasks extension, a per-request task lifecycle (working, input_required, completed, failed, cancelled) | Run lifecycle, event log, pause/resume, replay/fork |
| State management | Remote agent owns task state; execution internals are opaque | No protocol-level session since 2026-07-28; cross-call state is an explicit server-minted handle passed as a tool argument; list results carry cache hints (ttlMs, cacheScope) | Host owns durable run state and exposes events/snapshots |
| Trust boundary | Between independent agents | Between host application and MCP servers, including local or remote tool providers | Between workflow client and execution host; also between workflow nodes/tools/humans |
Specification Comparison
| Dimension | A2A | MCP | OpenWOP | Architectural implication |
|---|---|---|---|---|
| Agent/service discovery | Agent Card advertises identity, skills, endpoints, security, capabilities, input/output modes. | server/discover advertises supported versions, capabilities, and server identity; each request declares its own client capabilities; primitive discovery through list methods such as tools/list. | Capability document advertises protocol version, transports, limits, profiles, envelopes, node support, and host behavior. | A2A discovers agents; MCP discovers capabilities exposed by context/tool servers; OpenWOP discovers workflow hosts. |
| Identity and authentication | Agent identity and security schemes appear in the Agent Card; supports standard web-security patterns. | Transport-specific authentication, especially for Streamable HTTP; stdio often relies on local process trust. | Host/caller auth with operation scopes and production profiles; workflow execution identity may travel through run metadata and agent surfaces. | A2A has the most explicit remote-agent identity layer; MCP auth depends heavily on deployment mode; OpenWOP focuses on run-operation authorization. |
| Authorization and permissions | Agent-defined authorization; callers must respect security schemes and scopes exposed by the agent. | Server/tool permissions generally mediated by the host/client and transport authentication; tool authorization is often provider-specific. | Standardized operation scope vocabulary such as run creation, read, approval response, artifact read. | OpenWOP is strongest where workflow operation-level authorization matters. |
| Message format | Canonical protocol model with JSON representations and bindings including JSON-RPC, gRPC, HTTP+JSON. | JSON-RPC 2.0 request/response/notification messages. | HTTP JSON schemas, events, envelopes, workflow definitions, artifacts, and run snapshots. | MCP is the simplest RPC substrate; A2A and OpenWOP carry richer task/workflow semantics. |
| Transport layer | JSON-RPC, gRPC, HTTP+JSON, streaming, push notifications. | Stdio and Streamable HTTP, which may answer a request with an SSE response stream. The older HTTP+SSE transport is deprecated, and 2026-07-28 removed stream resumability. | REST, SSE, signed webhooks; v2 keeps gRPC out of the core wire. | MCP covers local and remote tool servers; A2A and OpenWOP are more naturally network service protocols. |
| Task delegation | Core purpose: delegate to another agent as a task. | Not task delegation; it is tool/context invocation by a host application. | Delegation happens inside workflow runs through nodes, workers, agents, subflows, or tools. | Use A2A for peer delegation; use MCP for capability invocation; use OpenWOP for orchestrated delegation. |
| Tool invocation | Possible inside the remote agent but not standardized as the primary abstraction. | Central abstraction through tools/list and tools/call. | Can model tool calls as workflow nodes and can compose with MCP tool calls. | MCP is the most direct tool integration protocol. |
| Human-in-the-loop | Task states such as input-required and auth-required can request user participation. | Elicitation lets servers request additional user information through the client/host. In 2026-07-28 it rides the Multi Round-Trip Requests pattern: the server returns an input_required result and the client retries with the answers. | First-class interrupts, approvals, clarifications, external events, resume schemas, and run suspension. | OpenWOP is strongest for auditable approval gates; MCP elicitation is narrower and tool-session-oriented. |
| Error handling | Binding-native errors plus protocol-specific task states and error semantics. | JSON-RPC error responses plus tool-call result semantics. | Run errors, lifecycle errors, capability-gated refusals, terminal events, and debug artifacts. | OpenWOP is strongest for workflow-runtime failures; MCP is strongest for RPC/tool-call errors. |
| Observability | Task status, streaming, push notifications, enterprise tracing guidance. | A logging primitive (deprecated in 2026-07-28 in favor of stderr or OpenTelemetry) and documented _meta keys for W3C trace context, but not full workflow tracing by itself. | OpenTelemetry naming, W3C trace context, run events, cost attribution, event logs, debug bundles. | OpenWOP has the most explicit production observability model. |
| Auditability | Caller can audit task-level outputs and status, not necessarily internal steps. | Tool calls can be logged, but audit semantics are largely host/platform responsibilities. | Event log, replay, artifacts, trace IDs, and signed events support audit-heavy systems. A host advertising auditLogIntegrity keeps a chained, checkpointed audit log that a privileged insider cannot silently rewrite, and serves GET /audit/verify (security-defaults.md). | OpenWOP is best for regulated workflow audit trails. |
| Extensibility | Agent Card extensions and protocol extension mechanisms. | Primitive capabilities, an extensions capability field for official and custom extensions (Tasks is one), and opt-in list-changed notifications over subscriptions/listen. | Host extensions, profiles, node packs, workflow-chain packs, pack registry. | All three are extensible, but in different layers. |
| Versioning | A2A-Version header/parameter and semantic compatibility expectations. | Dated specification revisions; every request carries its revision in _meta, and server/discover lists the revisions a server supports. | Versioned endpoint surface and compatibility/conformance profiles; its A2A and MCP interfaces negotiate the upstream version under authentication, fail closed below an advertised floor, and record every outcome as a negotiation.decided event. | A2A and OpenWOP are more explicit at the public wire-contract level; MCP now declares its version and capabilities per request. |
| Deployment model | Remote agent service. | Local process or remote server connected to an AI host. | Durable workflow host. | MCP can be embedded/local; OpenWOP usually requires a durable host; A2A requires addressable agents. |
Similarities
All three protocols attempt to reduce bespoke integration work in agentic AI systems. They each provide a standardized contract around a boundary that would otherwise become custom glue code.
| Shared pattern | A2A | MCP | OpenWOP |
|---|---|---|---|
| Capability declaration | Agent Card | server/discover and primitive lists | Host capabilities and workflow metadata |
| Asynchronous or long-running work support | Tasks, streaming, push notifications | Progress notifications, plus durable task handles when both sides support the Tasks extension | Runs, event logs, SSE, webhooks, pause/resume |
| Structured artifacts/results | Artifacts and Parts | Tool/resource content arrays and structured JSON-RPC responses | Artifacts, events, envelopes |
| Human involvement | Input-required/auth-required task states | Elicitation from server to user via host | Interrupts and approval/clarification gates |
| Security boundary awareness | Agent trust boundary | Host/server/tool trust boundary | Run/host/tool/human trust boundaries |
| Extensibility | Extensions and metadata | Capabilities, primitives, notifications, server-specific tools/resources/prompts | Profiles, packs, extensions |
Differences
Horizontal vs vertical vs orchestration layer
| Layer | Protocol | What it standardizes |
|---|---|---|
| Horizontal agent layer | A2A | How independent agents discover, message, delegate, and return results to each other. |
| Vertical tool/context layer | MCP | How an AI host connects to external tools, data sources, prompts, and contextual capabilities. |
| Workflow-control layer | OpenWOP | How durable multi-step workflows are started, streamed, interrupted, resumed, replayed, observed, and validated. |
Different answers to “what is opaque?”
A2A intentionally treats the remote agent as an opaque collaborator. The caller can see declared skills, task states, and artifacts, but not the remote agent’s private planning, memory, tool chain, or execution graph.
MCP is neither an agent transparency protocol nor a workflow protocol. It exposes capabilities from servers to hosts. A host can see and invoke tools/resources/prompts — and, with the Tasks extension, follow one long-running call through its own state machine — but MCP does not define an end-to-end workflow graph or independent agent collaboration model.
OpenWOP removes that opacity inside a workflow host. It standardizes run state, event streams, artifacts, interrupts, replay, node packs, and observability so the workflow can be inspected and validated.
MCP Tasks and OpenWOP runs are not the same durability
MCP revision 2026-07-28 added a Tasks extension: when a server decides a request will be long-running, it returns a durable taskId instead of blocking. The client polls tasks/get, answers mid-flight input_required prompts via tasks/update, and can tasks/cancel. The task is durably created before the response is sent, and the handle survives a client restart.
That is a real durability guarantee, and it closes the gap this page previously described as MCP having no execution lifecycle at all. It is worth being precise about what it does and does not cover, because the two models are easy to conflate:
| Dimension | MCP task | OpenWOP run |
|---|---|---|
| Scope | One request's asynchronous execution | A multi-step graph of nodes, edges, triggers, and variables |
| Who decides | Server-directed, per request | Client starts a named workflow |
| Retention | TTL-bounded (ttlMs) | Retention floors the host advertises |
| Cancellation | Cooperative — the server may still reach a non-cancelled terminal state | A cancelling → cancelled transition in the run state machine |
| History | Current status, then a terminal result | An append-only event log |
| Re-execution | Not defined | Replay and fork |
| Repeat-call safety | Not defined | Effect identity, atomic claim, and a GET /runs/{runId}/effects witness |
The practical read: MCP Tasks makes one call survivable. It does not describe the sequence of calls, what to do when the second attempt of one of them arrives, or how to reconstruct what happened. Those are the questions a workflow layer answers, and a harness that needs them still has to supply them — which is the same additive relationship the rest of this page describes, just at a closer distance than it was in June.
Since September the two models also meet on the wire. The v2 corpus specifies an MCP server mount on an OpenWOP host: tools/list lists the workflows the caller may run, and tools/call starts a run whose trust boundary is untrusted (RFC 0208). Without the Tasks extension, when that run stops for a human, the mount answers the call with an MCP input_required result carrying one elicitation/create request per open interrupt. A host caps those rounds at its advertised mcp.mrtr.maxRounds (at most 16). A host MAY also serve the Tasks extension there (RFC 0198). If it does, it answers a long tools/call with an MCP task whose taskId is the run's projected id, tasks/get reads the run without appending to its log, and tasks/update resolves the run's open interrupts. The MCP task is then a view onto one OpenWOP run. The event log, replay, fork and effect witness in the table above stay on the OpenWOP side of that view. The mount is optional. RFC 0198, like every RFC of the corpus's MCP/A2A program (0197–0216), is Accepted only provisionally, pending its cross-organization retrospective review. Its evidence is the steward's v2 reference host, a reference example rather than a production host. Every host the conformance matrix has measured is run by the steward or a steward-affiliated organization; no independent-organization host exists yet.
Different units of composition
| Protocol | Composition unit | Typical example |
|---|---|---|
| A2A | Skill advertised by an agent and invoked as a task | “Ask the procurement agent to compare vendors.” |
| MCP | Tool, resource, prompt, elicitation, logging; optionally a task | “Query CRM, read the contract, call the pricing API, use a prompt template.” |
| OpenWOP | Workflow definition, node, pack, run, interrupt, artifact | “Run a vendor-evaluation workflow, pause for approval, replay if policy changes.” |
Production Failure Modes — which layer fences them
An agent is a loop: a model reasons, calls a tool, observes the result, and repeats. That loop is what makes agents capable, and it is also where they fail in production — not in the model, but in the cycle wrapped around it. The well-documented failure modes are properties of the loop itself: small per-step error rates compound across steps, every lap costs tokens, an open-ended loop may never decide it is done, and a model that can call a tool can be tricked into calling the wrong one by poisoned input.
This is the dimension where the three protocols diverge most sharply, because OpenWOP is the only one of the three that owns the loop. A2A treats the remote agent's loop as opaque; MCP's Tasks extension gives a single call a durable, resumable lifecycle, but the loop around those calls is still the harness's. So the controls that fence a production agent — cap the steps, cap the time, cap the spend, gate the irreversible action, narrow the toolbox, mark untrusted input — land naturally in the workflow-control layer.
| Production failure mode | A2A | MCP | OpenWOP |
|---|---|---|---|
| Runaway loop — the agent never converges | Coarse task states; no iteration bound across the remote agent's internal loop | No loop construct to bound | maxLoopIterations run-execution bound; breach emits a terminal loop_limit_exceeded plus a cap.breached event, with the per-turn iteration counter observable on the run's event stream |
| Hang / stall — a step blocks indefinitely | Push-notification timeouts are caller-side | Per-call only; no workflow-level wall clock | runTimeoutMs wall-clock bound on the whole run, clamped to the host's limits.maxRunDurationMs; a breach emits cap.breached and fails the run with run_timeout |
| Cost blowout — every lap drags the full context | Not modeled; spend is internal to the remote agent | Per-tool-call only | First-class budget / quota / cost policy: reserve / consume / threshold / exhaust events plus cap.breached, with per-call accounting attributed on usage events. The events may carry the aggregate cost the caller capped, never the host's rate card or per-unit prices |
| Compounding errors — 90%-per-step ≈ 35% over ten steps | Caller sees the final task result, not intermediate self-correction | No self-correction model | Self-correction is first-class: an agent decision below the run's escalationThreshold MUST suspend the node on a low-confidence interrupt, and a verifier turn with explicit convergence criteria lets a run check its own work, so it escalates instead of confidently emitting a wrong result |
| Irreversible autonomous action — money out, data deleted | Coarse input-required / auth-required task states | Elicitation requests user input, but cannot enforce an approval gate | The model proposes; the host performs. High-blast-radius steps route through a first-class interrupt (kind: "approval") that suspends before the action. The host MUST refuse a resolver outside the listed approvers (and, where advertised, the named groups or roles), can require a quorum, and resumes deterministically. A reject fails closed: the raising node fails with approval_rejected (not retryable), and a rejected gate cannot satisfy a success edge, so the run continues only over an edge that admits a failed source (interrupt.md) |
| Over-broad toolbox — every tool is a way to go wrong | Tools hidden behind the agent; not the caller's to scope | tools/list exposes the catalog, but scoping is host/server policy | Portable tool catalog listing only the tools the caller may invoke. The host assigns each tool's safety tier, replay policy, and egress itself, never copying them from an MCP server's annotations, which are untrusted; an MCP tool it has not classified counts as write (tool-catalog.md). Per-tool authorization hooks sit on top, and a credential received inbound is never forwarded to an A2A, MCP, or webhook hop |
| Prompt injection — poisoned input redirects the agent | Trust boundary between agents; in-agent injection is opaque to the caller | Tool/server output flows to the host; trust handling is the host's responsibility | A documented threat model with conformance-tested invariants: external content (user input, retrieved knowledge, prior artifacts, and MCP/tool output) carries an untrusted trust marker, and — critically — untrusted tool/MCP output cannot advance an approval gate. A run started through the MCP mount starts untrusted |
The takeaway reinforces the layered reading of the rest of this comparison. None of these controls make A2A or MCP worse at what they do — A2A still owns agent collaboration, MCP still owns tool/context integration. But the moment an agent runs unattended against real systems, the production question becomes "what bounds the loop, and what stops it before the irreversible step?" — and that is the workflow-control layer's job. OpenWOP's contribution here is not that it makes the model more reliable (no protocol does); it is that when a run goes long, costs too much, loops forever, or reaches for an irreversible action, that fact is observable on the event stream and, for the irreversible case, stopped at a fail-closed gate.
Strengths and Weaknesses
| Protocol | Strengths | Weaknesses / open questions |
|---|---|---|
| A2A | Strong abstraction for independent agent collaboration. Agent Card creates a clear discovery and capability surface. Supports long-running and human-in-the-loop task interaction without exposing internals. Good fit for cross-vendor agent ecosystems and skill marketplaces. | Not designed to standardize internal workflow graphs, replay, or node-level traces. Tool invocation is hidden behind agent behavior unless paired with MCP or another tool protocol. Task states are intentionally coarse compared with a workflow engine. |
| MCP | Best protocol for connecting models/apps to tools, data, prompts, and APIs. Simple JSON-RPC interaction model with dynamic capability discovery. Works locally via stdio and remotely via Streamable HTTP. Widely adopted mental model: “USB-C for AI tool/context integration.” | Does not define agent-to-agent task delegation. Does not define durable workflow orchestration, replay, or full run audit semantics. Security posture depends heavily on host trust, server trust, local process isolation, tool metadata validation, and transport authorization. |
| OpenWOP | Strongest durable execution, replay, event-log, and observability model. Rich human checkpoint and interrupt semantics. Conformance-oriented approach for workflow-host portability. Composes naturally with both A2A and MCP. | Heavier implementation burden than A2A or MCP. Not a replacement for an agent-to-agent messaging protocol. Not a replacement for MCP’s direct tool/context integration surface. Requires durable host infrastructure to realize its full value. Every host measured so far is run by the steward or a steward-affiliated organization; and its current-A2A and current-MCP compatibility claims both still wait on a result against a real upstream peer. |
Use Case Fit
| Scenario | Best fit | Why |
|---|---|---|
| Agent-to-agent collaboration | A2A | Designed specifically for independent agents exchanging messages and tasks. |
| Tool/API/data-source integration | MCP | Tools, resources, and prompts are MCP’s core primitives. |
| Durable multi-step AI workflow | OpenWOP | Run lifecycle, event log, interrupts, replay, and observability are central. |
| Human approval flows | OpenWOP | First-class interrupts and resume semantics beat coarse task states or tool elicitation. |
| Simple remote specialist agent invocation | A2A | Lower-level workflow details do not need to be exposed. |
| Local filesystem/database/SaaS tool access from an AI app | MCP | MCP servers expose these as tools/resources over stdio or HTTP. |
| Workflow replay, fork, time-travel debug | OpenWOP | A2A and MCP do not define this as a core lifecycle. |
| Agent marketplace or skill catalog | A2A | Agent Cards and skills are the natural marketplace metadata unit. |
| Enterprise agent platform | All three | A2A for external agents, MCP for tools/context, OpenWOP for durable orchestration. |
| Secure tool execution inside audited workflow | MCP+OpenWOP | MCP invokes the tool; OpenWOP governs run-level policy, event log, human approval, and traceability. |
| Cross-vendor interoperability | Layer-specific | A2A for agents, MCP for tools/context servers, OpenWOP for workflow hosts. |
Integration Possibilities
The strongest architecture treats the three protocols as composable layers rather than alternatives.
- APIs
- databases
- files
- SaaS apps
- local services
Pattern 1: OpenWOP host exposed as an A2A agent
An OpenWOP host can publish an A2A Agent Card. Each workflow can be advertised as an A2A skill. An incoming A2A message creates an OpenWOP run. Run events are projected into A2A task status updates. Run artifacts become A2A artifacts.
In v2 this projection is normative, not just a design option. spec/v2/core/interop.md and its operation map (RFC 0208) pin it to A2A 1.0.1:
- the card lists one skill per invocable workflow, with
skills[].idset to the routedworkflowId; SendMessagemaps tocreateRun, or resolves an open interrupt when it names a waiting task;GetTask,ListTasksandCancelTaskmap togetRun,listRunsandcancelRun;- a task the caller could not read through
getRunis answered exactly as a nonexistent one; SubscribeToTaskre-attaches to a run's event stream, which needs the host'sa2a.durableTasksanda2a.streamingfacets;- a run suspended on a
credentialinterrupt projects to the A2Aauth-requiredstate (RFC 0199); - an A2A error carries a
google.rpc.ErrorInfodetail, and an A2A interface never answers in the OpenWOP error envelope (RFC 0211).
A host MAY also publish each inventoried agent as its own Agent Card (RFC 0202). It MAY serve a run artifact in the A2A Artifact/Part shape when the client negotiates application/a2a+json (RFC 0205). A2A push notifications are handled as webhook egress (RFC 0214). All of this is advertised through the optional a2a facet. The corpus makes no current-A2A compatibility claim yet: the v2 A2A 1.0 legs run against the conformance suite's own fake peer, the claim requires a result against a real upstream peer, and that result is still externally gated.
| A2A concept | OpenWOP projection |
|---|---|
| Agent Card | Host metadata plus workflow catalog |
| AgentSkill | WorkflowDefinition |
| Message | Run input |
| Task | Run |
| Task status update | Run event or run snapshot |
| Artifact | Workflow artifact |
| Input required | OpenWOP interrupt, approval, or clarification |
| Auth required | OpenWOP credential interrupt |
Pattern 2: OpenWOP workflow calls MCP tools
Inside a workflow run, worker nodes can call MCP servers for tool execution or resource retrieval. This keeps MCP at the tool/context boundary while OpenWOP governs run-level durability, state, observability, retry behavior, and approvals.
v2 gives this direction a normative home as well. A host advertising mcp.client exposes ctx.mcp.callTool, listTools, readResource and serverHealth to pack code (host-services.md). Each call is made against a host-configured server at the negotiated revision, and returns the server's MCP result unaltered, including an isError result (RFC 0204). A remote node-pack runtime can also name its MCP server by an inline subset of its MCP Registry record. That subset carries no install instructions and no credential values (RFC 0203). When an MCP server needs an OAuth grant, the host is the OAuth client: it runs PKCE, holds the credential itself, and can suspend the run on a credential interrupt until a user connects the account (RFC 0199, now Accepted provisionally). As with A2A, the corpus makes no current-MCP compatibility claim yet: that claim requires a result against a pinned real peer, and that result is still externally gated.
| OpenWOP workflow need | MCP role |
|---|---|
| Read external system state | Expose resource or tool call |
| Execute a business operation | Expose action as an MCP tool |
| Use a reusable instruction template | Expose prompt primitive |
| Ask user for missing tool input | Use MCP elicitation, optionally wrapped in OpenWOP interrupt |
Pattern 3: A2A agent backed by MCP and OpenWOP
A specialist agent can expose a simple A2A interface while internally using MCP to call actual systems and OpenWOP to coordinate the work. This is likely the cleanest enterprise pattern because it separates the public contract from internal execution and integration details.
Adapter responsibilities
| Adapter concern | Mapping / design choice |
|---|---|
| Discovery | Expose OpenWOP workflows as A2A skills; expose MCP server primitives to workflow node catalogs. |
| Invocation | Map A2A SendMessage to OpenWOP POST /runs; map OpenWOP tool nodes to MCP tools/call. |
| Identity | Propagate caller identity from A2A through OpenWOP run metadata and into MCP tool authorization where appropriate. |
| State | Project OpenWOP run states into A2A task states; preserve extra detail in metadata. |
| Human-in-the-loop | Map OpenWOP interrupts to A2A input-required states and/or MCP elicitation depending on where the user interaction belongs. |
| Observability | Preserve trace IDs across A2A, MCP, and OpenWOP calls. v2 specifies the carrier: params._meta on an MCP request, Message.metadata.openwop.traceparent on an A2A message, or the HTTP traceparent header (RFC 0207). |
| Security | Do not let MCP tool metadata implicitly escalate privileges; enforce host/workflow policy before tool invocation. |
Final Recommendations
Decision checklist
| Question | Likely answer |
|---|---|
| Do we need one agent to call another independent agent? | A2A |
| Do we need the agent to call external tools or read external data? | MCP |
| Do we need durable, replayable, observable workflow execution? | OpenWOP |
| Do we need human approval gates with deterministic resume? | OpenWOP |
| Do we need a simple integration between an AI app and a database/API/filesystem? | MCP |
| Do we want remote agents to remain implementation-opaque? | A2A |
| Do we want to expose workflows as agent skills? | A2A+OpenWOP |
| Do we want audited tool execution inside durable workflows? | MCP+OpenWOP |
| Do we want a complete enterprise agent platform? | A2A+MCP+OpenWOP |
Sources
The analysis distinguishes specification-grounded claims from architectural interpretation. These are the primary source documents consulted.
- Agent2Agent (A2A) Protocol Specification — official A2A specification (the page is labelled
1.0.0). - A2A release v1.0.1 — the latest A2A release: three specification fixes, and the version the OpenWOP operation map pins.
- Model Context Protocol Architecture Overview — official MCP architecture, primitives, transports, and lifecycle overview.
- Model Context Protocol GitHub repository — official MCP specification and schema repository.
- MCP specification, revision
2026-07-28— the current revision, checked for this review. - MCP
2026-07-28changelog — stateless protocol andserver/discover(SEP-2575), sessions removed (SEP-2567), Multi Round-Trip Requests (SEP-2322), Tasks moved to an extension (SEP-2663), and sampling, roots, and logging deprecated (SEP-2577). - MCP Tasks extension — durable handles, polling, mid-flight input, and the task lifecycle compared above.
- OpenWOP — Workflow Orchestration Protocol — OpenWOP overview and specification landing page.
- OpenWOP Spec v2 — Interop — the normative v2 home for A2A and MCP composition: facets, authenticated version negotiation, the operation map, the MCP Tasks projection, and per-agent cards.