Claix and A2A: the document intelligence API built to be called by other agents, not just used by them

Why A2A matters for document infrastructure, specifically

Most of the AI agent ecosystem has spent the last two years solving how an agent talks to tools — that is what MCP (Model Context Protocol) is for, and Claix already supports it at https://claix.dev/mcp. But 2026 has brought a second, different problem into focus: how does an agent talk to another agent, one built by a different team, on a different stack, without custom point-to-point integration? That is what A2A — an open protocol originally contributed by Google and now hosted by the Linux Foundation — is designed to solve, and it has been gaining fast adoption across major platform vendors throughout 2026.

For a document intelligence API, this distinction is not cosmetic. An MCP tool is called by an agent that already knows exactly what it wants and how to phrase it. An A2A agent can be discovered by another agent that has never seen Claix before, read its Agent Card to learn what it can do, and delegate an entire document-related task to it — including tasks that take time, need a follow-up question answered, or span several documents — using a standardized task lifecycle instead of a one-shot function call.

How Claix implements A2A: the architecture in plain terms

Claix’s A2A implementation follows the official specification closely, with three moving parts:

1. Discovery via the Agent Card

Before sending any work, a calling agent fetches GET /.well-known/agent.json (or the alternate path /.well-known/agent-card.json) — a public JSON document, no API key required, that states where to send tasks (https://claix.dev/a2a), which skills exist, and that Claix supports push notifications instead of streaming (capabilities.pushNotifications: true).

2. A single JSON-RPC 2.0 endpoint for everything

Every operation — extracting a PDF, listing schemas, querying a knowledge space — goes through the same POST https://claix.dev/a2a, authenticated with the same API key used across Claix’s REST and MCP interfaces (x-api-key header, or Authorization: Bearer). There is no separate credential system to manage per protocol.

3. Two ways to ask for work

A calling agent can send a DataPart — a structured JSON object naming the exact skill and its parameters, which is deterministic and does not depend on how a sentence is phrased — or a TextPart with a plain-language instruction, which Claix interprets to select the right skill and fill in the arguments. This dual path matters in a multi-agent world: some callers will already know exactly what they need, others will only have a natural-language goal handed down from a higher-level orchestrator.

The part that makes this genuinely new: A2A on top of persistent, cross-document memory

This is the detail that separates Claix’s A2A implementation from a simple “extraction API wrapped in a new protocol.” Most of what an A2A-compliant document tool could plausibly expose is stateless: send a file, get JSON back, done. Claix’s skill list is not stateless — it exposes the same document memory architecture that is central to the product itself:

• extract-pdf, extract-excel, extract-doc, extract-img, extract-txt (plus their Agent-mode reasoning equivalents, agent-extract-*) turn an unstructured file into schema-typed JSON.
• get-document and query-document let a calling agent come back later, in a different task, and ask something new about a document that was already processed — without re-uploading it or paying for re-extraction.
• create-space, query-space, and delete-space extend that same memory to a whole knowledge space (space_id): a group of processed documents that can be reasoned over together, so a calling agent can ask a question that spans multiple documents at once and get a single, cross-referenced answer.
• list-schemas, create-schema, delete-schema manage the typed structure that every extraction is validated against.

In other words: an external agent is not just asking Claix to parse a file. It is delegating access to a persistent, queryable memory of documents, addressable across multiple separate A2A tasks over time, through contextId (the thread linking a sequence of related tasks) and through document_id / space_id (the actual stored knowledge, which outlives any single conversation thread). No other combination of typed schema extraction, cross-document reasoning, and native A2A exposure appears to exist yet in the document-processing space, as far as current public documentation from comparable providers shows.

How a multi-agent task actually flows, end to end

A concrete example makes this concrete. Imagine an orchestrator agent coordinating an accounts-payable workflow, with no prior integration built specifically for Claix:

• It fetches Claix’s Agent Card, sees the extract-pdf and query-space skills, and learns what parameters each expects.
• It sends a message/send with a DataPart containing skill: "create-space" to open a new knowledge space for this month’s vendor invoices.
• For each invoice PDF, it sends extract-pdf with the relevant schema_id and the file (as file_base64 or a public file_path URL, since A2A has no multipart upload). Each of these might return status.state: "working" immediately, since extraction is asynchronous — the orchestrator does not block on the HTTP connection.
• Claix notifies the orchestrator’s registered webhook when each extraction finishes (tasks/pushNotificationConfig/set), rather than requiring a kept-open stream.
• Once all invoices are processed into the space, the orchestrator sends a single query-space task — “which vendor invoiced the most this month, and does any invoice contradict the purchase order total?” — and gets back one cross-referenced answer, computed over every document in that space, without the orchestrator having built any retrieval or comparison logic itself.

That last step is the one no generic file-parsing API, and no MCP-only integration, does out of the box: the reasoning and cross-referencing across documents happens inside Claix, as a delegated task, not inside the calling agent’s own code.

Claix’s A2A skills

Task states: how Claix handles ambiguity and missing data

One of the more consequential design choices in A2A is what happens when a request is incomplete — and it is where Claix’s behavior differs sharply from a plain REST API returning a hard error.

Genuinely invalid input (an unknown skill id, a malformed parameter) never becomes a task at all — it returns a JSON-RPC protocol error (-32602 Invalid params) immediately. But missing but supplyable information does not fail the request; it parks the task in input-required and asks for exactly what is needed, on the same thread. This distinction matters at scale: an orchestrator juggling dozens of delegated document tasks across different agents cannot afford opaque failures for something as recoverable as a missing schema id.

Claix vs a typical document-processing integration (MCP-only or REST-only)

Use cases this unlocks

Multi-agent accounts payable / expense reconciliation

An orchestrator agent delegates an entire invoice-reconciliation task to Claix — extract, store in a space, cross-check totals against purchase orders — without the orchestrator’s own code containing any parsing or retrieval logic.

Legal review pipelines spanning multiple specialized agents

A contract-review agent built by a different team can discover Claix, extract clauses from a batch of contracts into a shared knowledge space, and hand back only the structured findings a downstream compliance agent needs — with no bespoke API integration between the two teams’ systems.

Long-running due-diligence or audit tasks

Because Claix’s A2A tasks support working state and push notifications rather than blocking connections, an orchestrator can delegate a large query-space reasoning task over hundreds of processed documents and move on to other work, resuming only when the webhook fires.

Agent marketplaces and agent-to-agent commerce

As more agents become independently discoverable and callable via A2A across organizations, a properly implemented Agent Card is what allows Claix to be found and used automatically by agents its own team never directly integrated with — the core promise of the protocol.