A2A vs GraphQL: who decides the shape of the answer

GraphQL is for letting a client ask a service for exactly the data it needs, in the shape it needs, from a typed schema the service publishes. A2A (Agent2Agent) is for letting one agent delegate a goal to another agent, which decides how to reach the outcome and reports back through a task.

Both have a single entry point and describe themselves, and both are hosted under the Linux Foundation. They put control in opposite places. A GraphQL client decides which fields come back and how deep the query goes. An A2A client states what it wants done, and the remote agent decides which systems to consult and what to return.

Status as of September 26, 2026. The current GraphQL specification is the September 2025 Edition, maintained by the GraphQL Foundation, a non-profit hosted by the Linux Foundation since 2019. The GraphQL over HTTP specification, which maps GraphQL onto HTTP, is a Stage 2 draft and not yet official. A2A is a Linux Foundation project at protocol version 1.0; its latest release, v1.0.1, shipped on May 28, 2026.

What GraphQL is for

A GraphQL service publishes a schema of types and fields. Clients send documents with one of three operation types:

• a query, a read-only fetch;
• a mutation, a write followed by a fetch;
• a subscription, a long-lived request that returns data in response to a sequence of events.

The client names every field it wants, and the response mirrors the query. One request can walk related objects, such as an order, its shipments and each shipment’s carrier, that a resource-style API might spread over several calls. The specification calls GraphQL self-describing: clients can introspect the schema to learn its types and fields, which is what powers typed code generation and query editors.

The specification is transport-agnostic. The GraphQL over HTTP draft covers the usual deployment: requests sent to a single endpoint, with responses in the application/graphql-response+json media type. Authentication is not part of the specification, and graphql.org’s guidance puts authorization in the business logic layer rather than in individual resolvers.

What A2A is for

A2A fixes one set of operations for every agent, such as SendMessage, GetTask and CancelTask, over JSON-RPC 2.0, gRPC or HTTP+JSON. An agent describes what it can do in its Agent Card, usually at /.well-known/agent-card.json. Each skill there has an ID, a name, a prose description, tags, examples and accepted media types. It has no typed schema.

A client sends a message with text, file or data parts. The agent creates a task that can complete, fail, be refused, or pause for input or authorization, and it returns results as artifacts. The client never sees the agent’s internal tools or data model. That opacity is a design principle of the specification.

The same question both ways

Illustrative: an agent needs to know whether order A-1001 has shipped.

With GraphQL, the caller must know the schema and asks for precise fields:

query OrderShipping {
  order(id: "A-1001") {
    status
    shipments {
      carrier
      trackingNumber
    }
  }
}

The response returns those fields and nothing else. If the order is not found, or the caller may not read it, the service reports errors in the response’s errors list in whatever terms its schema defines.

With A2A, the caller sends a message such as “Has order A-1001 shipped?” with the order ID in a data part. An illustrative reply from the retailer’s agent over the JSON-RPC binding:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "task": {
      "id": "task-4b2e",
      "contextId": "ctx-7a19",
      "status": { "state": "TASK_STATE_COMPLETED", "timestamp": "2026-09-26T14:02:11.000Z" },
      "artifacts": [
        {
          "artifactId": "shipping-status",
          "parts": [
            { "text": "Order A-1001 shipped on September 24 with one package." },
            {
              "data": { "orderId": "A-1001", "status": "SHIPPED", "carrier": "Example Freight", "trackingNumber": "EF123456789" },
              "mediaType": "application/json"
            }
          ]
        }
      ]
    }
  }
}

The agent chose what to include. It could as easily have asked a question first, for example to confirm the email on the order, by moving the task to TASK_STATE_INPUT_REQUIRED.

Side by side

	GraphQL	A2A
Purpose	Let a client fetch or change exactly the data it names, from a typed schema	Let one agent delegate a goal to another agent and track the task
Layer	Query language and execution model for an API	Application protocol with a fixed set of operations
Who talks to whom	A client application and one GraphQL service	A client agent and a remote agent, often at different organizations
Transport	Transport-agnostic; GraphQL over HTTP is a Stage 2 draft	JSON-RPC 2.0 over HTTP, gRPC, or HTTP+JSON; SSE streaming; webhook push
Discovery	Schema introspection at a known endpoint; no standard way to find the endpoint	Agent Card at /.well-known/agent-card.json, registries or direct configuration
Auth	Not defined by the specification; handled around the service	Declared in the Agent Card: API key, HTTP auth, OAuth 2.0, OpenID Connect or mutual TLS
State	Queries and mutations are single requests; subscriptions are long-lived	Tasks with a lifecycle; contextId groups related work
Governance and status	GraphQL Foundation (Linux Foundation); September 2025 Edition	Linux Foundation project; version 1.0 (v1.0.1, May 28, 2026)

When to use GraphQL

Use GraphQL when the caller is your own software, or a close partner’s, and knows the data model: a web or mobile front end that needs several related objects in one round trip, a dashboard, or a partner integration that reads many entities. It suits read-heavy work where the client, rather than the server, should decide the shape of the result, and where typed code generation from the schema saves effort.

When to use A2A

Use A2A when the caller should not need your data model at all. An outside agent asking for a refund, a quote or a booking wants an outcome. Your agent decides which queries to run, which policy applies and whether to ask a follow-up question. A2A also covers what GraphQL leaves to each deployment: a standard place to discover the agent, declared authentication schemes, and a task lifecycle for work that takes time.

Using both

GraphQL fits well behind an agent. An A2A agent can query your GraphQL API to gather what a task needs, then return an artifact with a text summary and a data part. Outside callers see skills, and your schema stays internal.

Keep the OWASP advice for GraphQL in mind when an agent, or a model acting as one, is the client. The cheat sheet recommends disabling introspection in production, limiting query depth and amount, considering query cost analysis, and checking authorization on both edges and nodes. A model that writes its own queries can produce expensive or overly broad ones, so run the same limits you would for any untrusted client.

Common misconceptions

“A2A is GraphQL for agents.” GraphQL lets the client specify the exact result. A2A lets the client state a goal and leaves the method to the remote agent. They answer different questions about who is in charge of the response.

“GraphQL introspection is equivalent to an Agent Card.” Introspection describes types and fields that can be queried. An Agent Card describes an agent’s skills in prose, its endpoints and its security requirements. Neither replaces the other.

“GraphQL subscriptions and A2A streaming do the same job.” A subscription delivers data as events occur in the service. An A2A stream reports the progress of one task: its status changes and new artifacts until it reaches a terminal state.

“Because both are hosted by the Linux Foundation, they are one effort.” They are separate projects with separate specifications and governance.