Claix y A2A: la API de inteligencia documental construida para que la llamen otros agentes, no solo para que la usen

Por qué A2A importa específicamente para la infraestructura documental

La mayor parte del ecosistema de agentes de IA ha pasado los últimos dos años resolviendo cómo un agente habla con herramientas: eso es MCP (Model Context Protocol), y Claix ya lo soporta en https://claix.dev/mcp. Pero 2026 ha puesto el foco en un segundo problema distinto: ¿cómo habla un agente con otro agente, construido por otro equipo, en otro stack, sin una integración punto a punto a medida? Eso es lo que A2A — un protocolo abierto aportado originalmente por Google y alojado ahora por la Linux Foundation — está diseñado para resolver, y a lo largo de 2026 ha ganado adopción rápida entre los grandes proveedores de plataformas.

Para una API de inteligencia documental, esta distinción no es cosmética. Una herramienta MCP la llama un agente que ya sabe exactamente qué quiere y cómo formularlo. Un agente A2A puede ser descubierto por otro agente que nunca ha visto Claix, leer su Agent Card para saber qué puede hacer y delegarle una tarea documental completa — incluidas tareas que tardan, necesitan una pregunta de seguimiento o abarcan varios documentos — usando un ciclo de vida de tareas estandarizado en lugar de una llamada a función de un solo disparo.

Cómo implementa Claix A2A: la arquitectura en términos claros

La implementación A2A de Claix sigue de cerca la especificación oficial, con tres piezas móviles:

1. Descubrimiento mediante la Agent Card

Antes de enviar trabajo, el agente llamante hace GET /.well-known/agent.json (o la ruta alternativa /.well-known/agent-card.json): un documento JSON público, sin API key, que indica dónde enviar las tareas (https://claix.dev/a2a), qué skills existen y que Claix soporta notificaciones push en lugar de streaming (capabilities.pushNotifications: true).

2. Un único endpoint JSON-RPC 2.0 para todo

Cada operación — extraer un PDF, listar schemas, consultar un espacio de conocimiento — pasa por el mismo POST https://claix.dev/a2a, autenticado con la misma API key que usan REST y MCP de Claix (cabecera x-api-key, o Authorization: Bearer). No hay un sistema de credenciales distinto por protocolo.

3. Dos formas de pedir trabajo

El agente llamante puede enviar un DataPart — un objeto JSON estructurado que nombra la skill exacta y sus parámetros, determinista y sin depender de cómo se formule la frase — o un TextPart con una instrucción en lenguaje natural, que Claix interpreta para elegir la skill correcta y rellenar los argumentos. Este doble camino importa en un mundo multi-agente: algunos llamantes ya saben exactamente qué necesitan; otros solo tienen un objetivo en lenguaje natural heredado de un orquestador de nivel superior.

Lo que hace esto realmente nuevo: A2A encima de memoria persistente multi-documento

Este es el detalle que separa la implementación A2A de Claix de un simple “API de extracción envuelta en un protocolo nuevo”. La mayor parte de lo que una herramienta documental compatible con A2A podría exponer es sin estado: envías un archivo, recibes JSON, listo. La lista de skills de Claix no es sin estado: expone la misma arquitectura de memoria documental que es central al producto:

• extract-pdf, extract-excel, extract-doc, extract-img, extract-txt (más sus equivalentes con razonamiento Modo Agente, agent-extract-*) convierten un archivo no estructurado en JSON tipado por schema.
• get-document y query-document permiten que un agente llamante vuelva más tarde, en otra tarea, y pregunte algo nuevo sobre un documento ya procesado — sin volver a subirlo ni pagar una reextracción.
• create-space, query-space y delete-space extienden esa misma memoria a un espacio de conocimiento completo (space_id): un grupo de documentos procesados sobre el que se puede razonar a la vez, de modo que el agente llamante puede formular una pregunta que abarca varios documentos y obtener una sola respuesta cruzada.
• list-schemas, create-schema y delete-schema gestionan la estructura tipada contra la que se valida cada extracción.

En otras palabras: un agente externo no solo le pide a Claix que parse un archivo. Está delegando el acceso a una memoria persistente y consultable de documentos, direccionable a lo largo de varias tareas A2A separadas en el tiempo, mediante contextId (el hilo que enlaza una secuencia de tareas relacionadas) y mediante document_id / space_id (el conocimiento almacenado de verdad, que sobrevive a cualquier hilo de conversación concreto). Ninguna otra combinación de extracción tipada por schema, razonamiento multi-documento y exposición A2A nativa parece existir aún en el espacio de procesamiento documental, según la documentación pública actual de proveedores comparables.

Cómo fluye de extremo a extremo una tarea multi-agente

Un ejemplo concreto lo deja claro. Imagina un agente orquestador que coordina un flujo de cuentas a pagar, sin ninguna integración previa construida específicamente para Claix:

• Obtiene la Agent Card de Claix, ve las skills extract-pdf y query-space y aprende qué parámetros espera cada una.
• Envía un message/send con un DataPart que contiene skill: "create-space" para abrir un nuevo espacio de conocimiento para las facturas de proveedores de este mes.
• Por cada PDF de factura, envía extract-pdf con el schema_id correspondiente y el archivo (como file_base64 o una URL pública file_path, porque A2A no tiene subida multipart). Cada una puede devolver status.state: "working" de inmediato, ya que la extracción es asíncrona: el orquestador no bloquea la conexión HTTP.
• Claix notifica el webhook registrado del orquestador cuando termina cada extracción (tasks/pushNotificationConfig/set), en lugar de exigir un stream abierto.
• Cuando todas las facturas están procesadas en el espacio, el orquestador envía una sola tarea query-space — “¿qué proveedor facturó más este mes y hay alguna factura que contradiga el total del pedido de compra?” — y recibe una respuesta cruzada, calculada sobre todos los documentos de ese espacio, sin haber construido ninguna lógica de recuperación o comparación en su propio código.

Ese último paso es el que ninguna API genérica de parseo de archivos, ni ninguna integración solo MCP, hace de fábrica: el razonamiento y el cruce entre documentos ocurre dentro de Claix, como tarea delegada, no dentro del código del agente llamante.

Skills A2A de Claix

Estados de tarea: cómo Claix gestiona la ambigüedad y los datos faltantes

Una de las decisiones de diseño más relevantes de A2A es qué ocurre cuando una petición está incompleta — y ahí el comportamiento de Claix se diferencia con claridad de una API REST que devuelve un error duro.

Una entrada realmente inválida (un id de skill desconocido, un parámetro mal formado) nunca llega a crear una tarea: devuelve de inmediato un error de protocolo JSON-RPC (-32602 Invalid params). Pero la información que falta y aún se puede suministrar no hace fallar la petición; aparca la tarea en input-required y pide exactamente lo que necesita, en el mismo hilo. Esta distinción importa a escala: un orquestador que gestiona docenas de tareas documentales delegadas entre distintos agentes no puede permitirse fallos opacos por algo tan recuperable como un schema_id ausente.

Claix frente a una integración documental típica (solo MCP o solo REST)

Casos de uso que esto desbloquea

Cuentas a pagar / conciliación de gastos multi-agente

Un agente orquestador delega en Claix toda una tarea de conciliación de facturas — extraer, guardar en un espacio, cruzar totales con pedidos de compra — sin que el código del orquestador contenga lógica de parseo ni de recuperación.

Pipelines de revisión legal entre varios agentes especializados

Un agente de revisión de contratos construido por otro equipo puede descubrir Claix, extraer cláusulas de un lote de contratos a un espacio de conocimiento compartido y devolver solo los hallazgos estructurados que necesita un agente de cumplimiento aguas abajo — sin ninguna integración API a medida entre los sistemas de ambos equipos.

Due diligence o auditorías de larga duración

Como las tareas A2A de Claix soportan el estado working y notificaciones push en lugar de conexiones bloqueantes, un orquestador puede delegar un razonamiento query-space grande sobre cientos de documentos procesados y seguir con otro trabajo, reanudando solo cuando dispara el webhook.

Marketplaces de agentes y comercio agente a agente

A medida que más agentes se vuelven descubribles e invocables de forma independiente vía A2A entre organizaciones, una Agent Card bien implementada es lo que permite que Claix sea encontrado y usado automáticamente por agentes con los que su propio equipo nunca integró directamente: la promesa central del protocolo.