A2A Is the Task

Every conversation I have about A2A eventually arrives at the same question: couldn’t you just do this with MCP? The honest answer is “mostly, yes,” and I think A2A fans would be better served by saying so out loud. In this month’s deep dive I set out to figure out what’s doable in A2A that you can’t do with MCP. I think the approach to tasks really highlights the nature of how these two protocols approach agentic interaction, and that’s the interesting part in my opinion. Unfortunately, it gets lost when we pretend the two protocols have nothing in common.

In this post I attempt to isolate that part. In short: A2A has one primitive that MCP does not have in the same shape, and it is the Task. With small housekeeping exceptions, anything in A2A either produces a task, feeds one, or watches one. As the centerpiece of A2A, I’ll explore this object and its state machine in depth. As in other posts on my blog, there are interactive components you can use to navigate the state machine yourself, so feel free to drive the tasks as you see fit!

Disclosure, as usual: I work at Arcade, where my days are mostly MCP. I’m also an AAIF ambassador, which motivated me to look closer at A2A, and I am not neutral about any of this. I am, however, trying to be accurate, and every claim about the protocols below is grounded in the A2A specification and the MCP Tasks extension.

The “MCP vs A2A” conversation

Most “MCP vs A2A” conversations take the same basic shape. Take an agent. Put an MCP server in front of it with a single tool, ask_agent(prompt), that forwards the prompt and returns whatever the agent says. Now list what you have:

• Discovery. tools/list tells the caller what the agent can do. Add a description and you have something that looks a lot like an Agent Card.
• Skills. One tool per skill, each with an input schema. Depending on the implementation, it’s even more precise than A2A’s prose-and-tags skills.
• Auth. OAuth at the transport.
• Long-running work. A former MCP limitation, now the MCP Tasks extension (io.modelcontextprotocol/tasks) gives you a durable task handle, working and input_required and terminal states, polling with tasks/get, a way to answer mid-flight questions with tasks/update, cooperative cancellation, and push notifications. It is very much happening, and it is good.

So what’s left? Let’s look at the same request in both envelopes.

{  "jsonrpc": "2.0",  "id": 1,  "method": "SendMessage",  "params": {    "message": {      "messageId": "msg-01",      "role": "ROLE_USER",      "parts": [        {          "text": "Chart last quarter’s churn by month."        }      ]    }  }}

{  "jsonrpc": "2.0",  "id": 1,  "result": {    "task": {      "id": "task-01",      "contextId": "ctx-3e8a",      "status": {        "state": "TASK_STATE_SUBMITTED",        "timestamp": "2026-08-28T14:02:11Z"      },      "history": [        {          "messageId": "msg-01",          "role": "ROLE_USER",          "parts": [            {              "text": "Chart last quarter’s churn by month."            }          ]        }      ],      "artifacts": []    }  }}

// request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "ask_analyst",
    "arguments": {
      "prompt": "Chart last quarter’s churn by month."
    },
    "_meta": {
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": {
          "io.modelcontextprotocol/tasks": {}
        }
      }
    }
  }
}

// response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "task",
    "task": {
      "taskId": "mcp-7c2e",
      "status": "working",
      "ttlMs": 600000,
      "pollIntervalMs": 2000,
      "createdAt": "2026-08-28T14:02:11Z"
    }
  }
}

// request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-01",
      "role": "ROLE_USER",
      "parts": [
        {
          "text": "Chart last quarter’s churn by month."
        }
      ]
    }
  }
}

// response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "task": {
      "id": "task-01",
      "contextId": "ctx-3e8a",
      "status": {
        "state": "TASK_STATE_SUBMITTED",
        "timestamp": "2026-08-28T14:02:11Z"
      },
      "history": [
        {
          "messageId": "msg-01",
          "role": "ROLE_USER",
          "parts": [
            {
              "text": "Chart last quarter’s churn by month."
            }
          ]
        }
      ],
      "artifacts": []
    }
  }
}

The MCP task is a receipt. It stands in for one request, it has a TTL, and when it completes, its result is exactly what that one request would have returned if it had been fast. The A2A task is a thread. It belongs to a context that other tasks can share, it carries the history of messages from both sides, and its outputs are a list that fills in over time. Both are called tasks. They are wrapping different things.

Here is the full comparison, including the rows where the answer is “same”:

From that table we can see how the two protocols approach tasks in a way that reminds me of parallel evolution.

• Convergent traits: pausing for input and cooperative cancel are nearly identical. Pausing for auth and declining are both expressible in MCP, as conventions layered on input_required and error codes. A2A achieves the same with a stronger contract, giving each a named state instead.
• Divergent traits: A2A allows for partial delivery and retains the context of one or multiple tasks that you can group. MCP does not have a convention for this at all.

In the scenarios below I walk through A2A-optimized task “threads”. A2A is a natural choice for some of these scenarios, which would be difficult to generalize using MCP.

The pieces on the board

I present 7 distinct scenarios below, but the actors are all the same:

• Your agent. The client. A personal agent that runs on your behalf and delegates work it can’t do itself.
• The Analyst. The remote agent. Run by another team, it has access to the data warehouse and, if you allow it, the billing system. It is the A2A server in every scenario.
• The warehouse and the billing system. Behind the Analyst. You never talk to them, but they cause most of the interesting states.
• Message, Part, Task, TaskStatus, Artifact. The nouns. A Message is what either side says, made of Parts (text, file, structured data). A Task is the unit of work. TaskStatus is its current state plus an optional message explaining that state. An Artifact is an output.
• contextId and taskId. The context is the conversation. The task is one piece of work inside it. Several tasks can live in one context.

Setup: the Agent Card

Like MCP, A2A has a discovery step that allows the client and server agent to negotiate capabilities and expectations of their interactions. The Analyst publishes an Agent Card at /.well-known/agent-card.json. Your (client) agent fetches it once.

{  "name": "Analyst",  "description": "Answers questions about product usage, churn and revenue from the warehouse and the billing system.",  "supportedInterfaces": [    {      "url": "https://analyst.example/a2a",      "protocolBinding": "JSONRPC",      "protocolVersion": "1.0"    }  ],  "provider": {    "url": "https://analyst.example",    "organization": "Data Platform Team"  },  "version": "2.3.0",  "capabilities": {    "streaming": true,    "pushNotifications": true,    "extendedAgentCard": false  },  "securitySchemes": {    "bearer": {      "httpAuthSecurityScheme": {        "scheme": "bearer"      }    }  },  "securityRequirements": [    {      "schemes": {        "bearer": {          "list": []        }      }    }  ],  "defaultInputModes": [    "text/plain"  ],  "defaultOutputModes": [    "text/plain",    "text/csv"  ],  "skills": [    {      "id": "churn",      "name": "Churn analysis",      "description": "Churn rates by month, region, cohort or plan.",      "tags": [        "analytics",        "churn"      ]    },    {      "id": "revenue",      "name": "Revenue joins",      "description": "Joins usage metrics with billing revenue. Requires your consent for billing access.",      "tags": [        "analytics",        "billing"      ]    },    {      "id": "export",      "name": "Aggregate exports",      "description": "CSV exports of aggregates. Never exports PII.",      "tags": [        "export"      ]    }  ]}

{
  "name": "Analyst",
  "description": "Answers questions about product usage, churn and revenue from the warehouse and the billing system.",
  "supportedInterfaces": [
    {
      "url": "https://analyst.example/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "provider": {
    "url": "https://analyst.example",
    "organization": "Data Platform Team"
  },
  "version": "2.3.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": false
  },
  "securitySchemes": {
    "bearer": {
      "httpAuthSecurityScheme": {
        "scheme": "bearer"
      }
    }
  },
  "securityRequirements": [
    {
      "schemes": {
        "bearer": {
          "list": []
        }
      }
    }
  ],
  "defaultInputModes": [
    "text/plain"
  ],
  "defaultOutputModes": [
    "text/plain",
    "text/csv"
  ],
  "skills": [
    {
      "id": "churn",
      "name": "Churn analysis",
      "description": "Churn rates by month, region, cohort or plan.",
      "tags": [
        "analytics",
        "churn"
      ]
    },
    {
      "id": "revenue",
      "name": "Revenue joins",
      "description": "Joins usage metrics with billing revenue. Requires your consent for billing access.",
      "tags": [
        "analytics",
        "billing"
      ]
    },
    {
      "id": "export",
      "name": "Aggregate exports",
      "description": "CSV exports of aggregates. Never exports PII.",
      "tags": [
        "export"
      ]
    }
  ]
}

The card says who the agent is, where to reach it, how to authenticate to it, and what it can do in prose. For this post the only fields that change anything are capabilities.streaming and capabilities.pushNotifications. Flip them off and the Analyst becomes an agent you can only poll; the state machine is unchanged, but two of its observation modes go away. Everything else about discovery (well-known URIs vs registries vs direct configuration, signed cards, authenticated extended cards) deserves its own post and may get one in the future.

An important distinction that can create confusion later: securitySchemes on the Agent Card is about your agent authenticating to the Analyst. The auth-required state we’ll meet in scenario 3 is about the Analyst needing your permission to act somewhere else. Different problem, different layer. If you’re familiar with tool-level auth in MCP, this is a very similar distinction.

Message or Task

In A2A, the client calls SendMessage, and the server returns either a Message or a Task. That choice is the server’s.

The spec describes three archetypes. A message-only agent never creates tasks and relies on contextId for continuity, which is fine for a chatbot. A task-generating agent creates a task for everything, even “what data do you have?”, and ends up with a lot of trivially completed tasks. A hybrid agent uses messages to negotiate scope and tasks to track execution. The Analyst is a hybrid, and I think most useful agents will be.

The point of the fork is that a task exists because the agent decided it should. A Message means “here is your answer, nothing to track.” A Task means “this will take a while, or might need you, or might produce things; here is a handle.” Everything from here on happens on the right-hand branch.

Observing a task

Before the state machine itself, one piece of vocabulary. Nothing about a task’s lifecycle depends on how your agent finds out about each transition. There are three ways, and the Agent Card determines which ones are supported by the agent:

• Polling. GetTask with the task’s id, and optionally historyLength to trim the message history. You see whatever state the task is in when you ask. You see artifacts only as part of the snapshot, so intermediate chunks are invisible.
• Streaming. SendStreamingMessage opens a stream that first returns the Task, then emits TaskStatusUpdateEvent and TaskArtifactUpdateEvent as they happen. When the task pauses in an interrupted state the stream ends; after you reply, your reply’s own stream picks up. SubscribeToTask attaches a stream to an existing task, for reconnects.
• Push. Your agent registers a webhook with CreateTaskPushNotificationConfig, and the Analyst POSTs events to it. This is how your agent finds out about auth-required without polling.

In each figure below, the “observe by” toggle changes the grey note under each event: what the client saw, and when. The states and transitions never change. If you flipped streaming or pushNotifications off in the Agent Card above, those modes are greyed out here, which is exactly what would happen to your agent.

The state machine

A task is in exactly one of these states at any moment:

• In flight: submitted, working.
• Interrupted, resumable: input-required, auth-required.
• Terminal, closed forever: completed, failed, canceled, rejected.

(The enum also has an unspecified value for unknown states. It should never appear on a healthy wire, so I’m leaving it out of the graph.)

Every figure in this section is the same machine. Solid edges are moves the agent makes; dashed edges are moves the client makes. Each scenario steps through its own path: press “next step” to send the next event, and the graph shows you where it is about to go before it goes. The event log on the right keeps the TaskStatus snapshot behind every row.

Scenario 1: Happy path

“Chart last quarter’s churn by month.”  The Analyst returns a Task in submitted, moves to working, and finishes in completed. Already one thing MCP tasks cannot do: the table arrives as one artifact chunk and the chart arrives as a second chunk appended to it, both while the task is still working. An MCP task would hand you both at completed and nothing before.

Notice TaskStatus.timestamp on every row. The status object is small on purpose: a state, a time, and optionally a message. The message is where the agent talks about the state, as opposed to producing output.

Scenario 2: The agent asks back

“Compare churn across regions.”  The Analyst has two candidate groupings and two candidate granularities, and it would rather ask than guess. It moves to input-required and puts the question in status.message.

Unlike MCP, your agent does not call a special method to reply. It calls SendMessage again with an ordinary Message whose taskId is the paused task’s id. That is the entire resumption protocol. The task goes back to working and finishes.

This is where A2A and MCP tasks are most different. MCP has input_required too, and it is answered with tasks/update, carrying inputResponses keyed to an inputRequests map the server defined, typically an elicitation form. It is a structured, server-shaped reply. A2A’s reply is a message with parts: prose, a file, structured data, or something the agent did not anticipate at all. One is a form. The other is a turn in a conversation. Neither is wrong, and the difference tells you what each protocol thinks a task is. More importantly, an A2A input-required is usually meant for the agent to resolve, while MCP elicitations are mostly meant for the operator to resolve.

Scenario 3: The agent needs your permission

“Add billing revenue to that chart.” Revenue lives in the billing system, the Analyst can’t read it as you without your consent, and so it stops in auth-required with a consent URL in status.message. You authorize out of band. Your agent sends a Message with the same taskId saying go ahead, and the task resumes.

With MCP, you would need URL-mode elicitation to support this: the task pauses in input_required, the elicitation carries a consent URL, the user authorizes out of band, and the server resumes with credentials the client never sees. The MCP spec is even stricter than A2A’s prose about that last boundary. What A2A adds is smaller: the wait for consent is a named state of the task. Your agent, a dashboard, or a policy engine can see auth-required and treat it differently from input-required (page a human, apply a longer timeout, escalate) without opening the input request to guess what kind of wait this is. MCP can express the situation; A2A can talk about it.

Scenario 4: The agent says no

“Export every customer’s email address.”  The Analyst declines, in submitted, before doing anything at all, and moves to rejected. status.message says why and offers an alternative.

rejected and failed are both terminal states and both mean you are not getting what you asked for. They differ in intent. failed is “I tried and could not.” rejected is “I refuse.” Can MCP express a refusal? Of course: an error code, or a perfectly successful result whose text says no, which agents behind tools do constantly. What MCP lacks is a standard way to handle this, so every server picks its own, and a generic client cannot tell refusal from failure without server-specific knowledge. A2A’s version is optimized for clear retry logic: failed is often worth retrying, rejected never is, and an orchestrator can only apply that rule if the protocol states which one happened.

Scenario 5: Something breaks

“Backfill churn for the last five years.”  The warehouse query hits its limit and the Analyst moves to failed, with the error and a suggestion in status.message. Nothing here is specific to A2A. Both protocols do this the same way.

Scenario 6: You change your mind

Same backfill, but partway through you don’t want it anymore. Your agent calls CancelTask. In the main path the Analyst honors it and the task ends in canceled.

The variant: the Analyst is already writing results and refuses with TaskNotCancelableError. The task stays working, and it finishes on its own.

Cancellation is cooperative in both protocols. The client asks, and the agent (or server) decides. A2A is explicit about the refusal with a named error; MCP acknowledges the request and may still finish in a state other than cancelled.

The rule of terminal states

This last figure is not scripted. Click submitted to start, then click any shaded state to walk the graph. Walk it to completed, and then try to click working. The graph won’t let you: once a task reaches a terminal state it cannot restart. Not for a refinement, not for a retry, not because the user said “actually, make it red.” Whatever comes next is a new task. Which raises the question of how new tasks relate to old ones. Let’s have a look!

Contexts, follow-ups, parallel tasks

Back to the rule. Task 1 charted churn by month and is completed. You want the same chart split by signup cohort. You cannot reopen task 1. What you do instead is send a new Message in the same contextId, with referenceTaskIds: ["task-01"] so the Analyst knows what you are refining, and the Analyst creates task 2.

// send a follow-up

{
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-10",
      "role": "ROLE_USER",
      "contextId": "ctx-3e8a",
      "referenceTaskIds": [
        "task-01"
      ],
      "parts": [
        {
          "text": "Now split it by signup cohort."
        }
      ]
    }
  }
}

{
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-11",
      "role": "ROLE_USER",
      "contextId": "ctx-3e8a",
      "referenceTaskIds": [],
      "parts": [
        {
          "text": "Also compute LTV per region."
        }
      ]
    }
  }
}

{
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-12",
      "role": "ROLE_USER",
      "contextId": "ctx-3e8a",
      "referenceTaskIds": [
        "task-02"
      ],
      "parts": [
        {
          "text": "Make the cohort chart a heatmap."
        }
      ]
    }
  }
}

Three things to notice while you click:

1. The old task never changes. It is completed, its artifacts are final, and it stays in the tree as a record of what was done.
2. Refinements keep the artifact name and mint a new id. The spec’s position is that the client is best placed to manage artifact versions, so the agent’s job is to keep name stable (churn-q2) and give each version its own artifactId. Your agent decides which version is current.
3. Parallel work is just two follow-ups. “Also compute LTV per region” has nothing to do with the churn chart, so it references nothing, and it can run while task 2 is still working. The context is what holds them together.

Let’s compare this to what MCP’s task handle does in similar scenarios. The handle relates every operation on one unit of work. Polling, mid-flight input, cancellation and the final result all reference the same taskId, and that is the point of the handle. It does not relate one unit of work to the next. A refinement is a fresh tools/call producing a fresh task, and its connection to the previous one lives in the prompt your agent wrote, invisible to the protocol. A2A’s contextId and referenceTaskIds are the layer above the handle that MCP can’t see. In my opinion, agents that require this kind of context tracking are the strongest argument for A2A.

Artifacts

If you’ve paid attention above, you’ve noticed multiple references to artifacts, and how I use “artifact” and “result” interchangeably. Artifacts arrive as TaskArtifactUpdateEvents, each carrying a chunk and two flags. append says whether this chunk extends the artifact or replaces it. lastChunk says whether the artifact is now complete.

// nothing yet

// press next

month,churn
2026-04,3.1%
2026-05,2.8%
2026-06,2.4%

[chart: churn-q2.svg]

The agent chooses per event. A streaming text response is a run of append: true chunks with a final lastChunk: true. A progress table that keeps getting redrawn is a run of append: false chunks. Both are legal, and the client has to handle both. This is also the mechanism behind “the chart arrived before the task completed” in scenario 1, and it has no equivalent in MCP tasks.

Back to MCP

Seven scenarios. For each, would an MCP task have done the job?

Two yes, four with a caveat, one no. Read down the caveats and a pattern falls out: almost everything A2A’s task does, MCP can express by convention. Pausing for consent is input_required plus a URL elicitation. Refusing is an error code or a polite no in the result. The problem with soft conventions is that you cannot guarantee that every server and client implements them correctly.

These patterns should also tell you what to choose. If your agent needs one result from another agent, with no back-and-forth, no permission it doesn’t already have, and no relationship to the last thing it asked, then an MCP tool in front of that agent is simpler and you should use it. MCP tasks make that true even when the result takes a while. A2A earns its place the moment the work becomes a thread: when the other side might ask, might need your permission, might decline, might send drafts, and when what you ask next depends on what it did last.

If you can only learn one, I’d pick MCP. In any case, if you’re serious about agentic patterns I encourage you to learn A2A as well, even if you don’t end up adding support for it to your agents.

Where the spec is going

A2A is at v1.0 with the proto file as the normative source, which is a recent shift and the reason the enum names in this post look the way they do. The discovery story still has an open item (there is no standard registry API yet).

If you spot a place where I’ve misread the spec, tell me. The state machine on this page is generated from one data file, and I’d rather fix the file than argue.