Imagina que llamas a una empresa. Dices lo que necesitas. La persona al otro lado te entiende, verifica la disponibilidad y te da una respuesta clara. Sin hacer clic en menus, sin adivinar, sin interpretar HTML.
Esa es exactamente la idea detras del Protocolo A2A -- solo que aqui no llama un humano, sino un agente de IA. Y la "empresa" es un sitio web con una API estructurada.
Que es el Protocolo A2A?
A2A significa Agent-to-Agent Protocol (Protocolo Agente a Agente). Google lo presento en abril de 2025 y posteriormente lo transfirio a la Linux Foundation, donde lo desarrollan mas de 150 organizaciones. A fecha de febrero de 2026, la especificacion se encuentra en la version 0.3.0 (Release Candidate 1).
Importante de entrada: A2A no es un estandar final ampliamente adoptado. Es un protocolo en desarrollo activo con fuerte respaldo, pero aun temprano en su adopcion. Lo usamos porque el concepto subyacente es solido -- no porque ya funcione en todas partes.
La idea central
La web tiene un problema: los agentes de IA pueden visitar sitios web, leer texto y seguir enlaces. Pero no pueden actuar -- no pueden reservar una cita, solicitar un presupuesto ni hacer una reservacion. Al menos no de forma fiable y estructurada.
A2A resuelve esto con un protocolo de comunicacion estandarizado. Define como un agente de IA:
- Descubre lo que puede hacer un sitio web (Discovery)
- Envia tareas (Task Execution)
- Recibe resultados (Response)
La base tecnica: JSON-RPC 2.0
A2A se construye sobre JSON-RPC 2.0 -- un estandar de llamada a procedimiento remoto establecido y ligero. No es un formato experimental; se utiliza en el desarrollo de software desde hace anios.
Las tres operaciones mas importantes:
| Operacion | Proposito |
|---|---|
tasks/send | Enviar una tarea al agente |
tasks/get | Consultar el estado de una tarea en curso |
tasks/cancel | Cancelar una tarea en curso |
Ademas, existen operaciones adicionales para streaming (tasks/sendSubscribe), notificaciones push y configuracion -- 11 metodos definidos en total. La capa de transporte soporta JSON-RPC 2.0 sobre HTTP, gRPC y bindings HTTP/REST.
La agent-card.json: Tarjeta de presentacion para agentes de IA
Antes de que un agente pueda comunicarse, necesita saber con quien habla y que es posible. Para eso existe agent-card.json -- un archivo en /.well-known/agent-card.json que declara todas las capacidades de un sitio web.
Asi se ve una agent-card.json simplificada:
{
"name": "Pizzeria Roma",
"description": "Restaurante italiano en Munich",
"url": "https://pizzeria-roma.de",
"protocolVersion": "0.3.0",
"provider": {
"organization": "Pizzeria Roma",
"url": "https://pizzeria-roma.de"
},
"defaultInputModes": ["text/plain", "application/json"],
"defaultOutputModes": ["text/plain", "application/json"],
"capabilities": {
"streaming": false,
"pushNotifications": false
},
"skills": [
{
"id": "make-reservation",
"name": "Reserva de mesa",
"description": "Reservar una mesa con fecha, hora y numero de personas",
"tags": ["reservation", "booking", "table"],
"examples": [
"Reserva una mesa para 4 personas el viernes a las 19h",
"Hay mesas disponibles para esta noche?"
]
},
{
"id": "view-menu",
"name": "Ver carta",
"description": "Carta actual con precios e informacion sobre alergenos",
"tags": ["menu", "food", "prices"]
}
]
}
Que define la agent-card.json
- Identidad: Quien es este agente? Nombre, URL, proveedor
- Version del protocolo: Que version de A2A se soporta
- Modos de entrada/salida: Que formatos acepta y entrega el agente (texto, JSON, imagenes, etc.)
- Capacidades: Puede el agente hacer streaming? Enviar notificaciones push?
- Skills: Habilidades concretas con descripcion, etiquetas y ejemplos
Los skills son el elemento central. Un agente de IA lee la agent-card.json, comprende las capacidades disponibles y sabe que tareas puede enviar.
agents.json vs. agent-card.json: Cual es la diferencia?
Estos dos archivos se confunden a menudo. La distincion importa:
| agents.json | agent-card.json | |
|---|---|---|
| Proposito | Discovery: Que puede hacer este sitio web? | Comunicacion: Como hablo con el? |
| Analogia | Paginas amarillas (listar servicios) | Numero de telefono + instrucciones (llamar y pedir) |
| Contenido | Tools con endpoints HTTP, metodos, parametros | Skills con modos I/O, capacidades, version del protocolo |
| Protocolo | Sin protocolo propio, describe endpoints REST | Protocolo A2A (JSON-RPC 2.0) |
| Origen | Propuesta comunitaria (Wildcard AI / nicepkg) | Google, luego Linux Foundation |
| Estado del estandar | Sin estandar oficial | Especificacion activa (v0.3.0 RC1) |
En la practica, ambos se complementan: Un agente usa agents.json para descubrir que servicios existen. A traves de agent-card.json y el protocolo A2A, se comunica de forma estructurada con esos servicios.
Ejemplo concreto: Un agente reserva una consulta
Supongamos que alguien le dice a su asistente de IA: "Encuentrame una agencia de diseno web y reserva una consulta para la proxima semana."
Paso 1: Discovery
El agente accede a https://studiomeyer.io/.well-known/agent-card.json y encuentra el skill schedule-consultation:
{
"id": "schedule-consultation",
"name": "Schedule Consultation",
"description": "Book a free consultation call to discuss your web project.",
"tags": ["booking", "consultation", "meeting"],
"inputModes": ["text/plain", "application/json"],
"outputModes": ["application/json"],
"examples": [
"I'd like a consultation about a new website",
"Can I schedule a call to discuss a redesign?"
]
}
Paso 2: Enviar tarea
El agente envia una solicitud JSON-RPC:
{
"jsonrpc": "2.0",
"method": "tasks/send",
"id": "req-001",
"params": {
"id": "task-abc-123",
"message": {
"role": "user",
"parts": [
{
"type": "text",
"text": "Me gustaria reservar una consulta. Nombre: Max Mustermann, Email: max@example.com, Tema: Nuevo sitio web para mi restaurante"
}
]
}
}
}
Paso 3: Recibir respuesta
El sitio web procesa la solicitud y responde:
{
"jsonrpc": "2.0",
"id": "req-001",
"result": {
"id": "task-abc-123",
"status": {
"state": "completed"
},
"artifacts": [
{
"parts": [
{
"type": "text",
"text": "Consulta reservada con exito. Max Mustermann recibira un email de confirmacion en max@example.com. Tema: Nuevo sitio web para restaurante."
}
]
}
]
}
}
Que sucedio aqui
- El agente leyo las capacidades del sitio web (Discovery)
- Envio una solicitud estructurada (Task)
- Recibio una respuesta legible por maquina (Result)
Sin rellenar formularios. Sin parsear HTML. Sin adivinar si el boton "Enviar" funciona.
Ciclo de vida de las tareas: No todo se completa al instante
A2A define un ciclo de vida claro para las tareas:
submitted → working → completed
→ failed
→ canceled
→ input-required
El estado input-required es particularmente interesante: si el agente no proporciono suficiente informacion, el sitio web puede hacer preguntas adicionales -- igual que una persona por telefono diria: "Para que fecha desea reservar?"
Que puede hacer A2A hoy -- y que no
Lo que funciona
- La especificacion es solida. JSON-RPC 2.0 como base esta probado y es ligero.
- El concepto es claro. Discovery, ejecucion de tareas, respuesta -- una triada logica.
- Fuerte respaldo. Mas de 150 organizaciones en la Linux Foundation, incluyendo Google, Salesforce, SAP.
- SDK disponible.
@a2a-js/sdkpara JavaScript/TypeScript existe.
Lo que aun falta
- Adopcion amplia. A febrero de 2026, pocos sitios web implementan A2A activamente. La mayoria de agentes de IA (ChatGPT, Claude, Gemini) aun no lo usan por defecto para interacciones web.
- Herramientas. Las herramientas de debugging, monitoring y logging para comunicacion A2A son aun rudimentarias.
- Estandar de autenticacion. A2A no define su propia autenticacion. Como los agentes se identifican y autorizan sigue siendo una cuestion abierta.
Por que implementamos A2A de todas formas
La respuesta honesta: porque la direccion es correcta.
La web esta evolucionando de legible para motores de busqueda a utilizable para agentes de IA. La cuestion no es si esto sucedera, sino cuando. A2A es la propuesta mas concreta hasta ahora de como deberia funcionar esta comunicacion.
Para nuestros clientes, esto significa: si A2A o un protocolo similar se convierte en estandar, sus sitios web estan preparados. La agent-card.json esta escrita, los endpoints de API existen, la validacion esta implementada.
El esfuerzo es manejable -- un archivo JSON y endpoints de API limpios. El riesgo de que no se adopte es pequenio comparado con la ventaja si se adopta.
Resumen
| Aspecto | Detalle |
|---|---|
| Que es A2A? | Protocolo para comunicacion estructurada entre agentes de IA y sitios web |
| Quien lo respalda? | Google, luego Linux Foundation, mas de 150 organizaciones |
| Base tecnica | JSON-RPC 2.0, agent-card.json para discovery |
| Estado | v0.3.0 RC1, desarrollo activo, adopcion temprana |
| Concepto central | Discovery (agent-card.json) → Task (tasks/send) → Result |
| Diferencia con agents.json | agents.json = Que existe? A2A = Como me comunico con ello? |
A2A no es ni un hype que se pueda ignorar ni un estandar que se necesite de inmediato. Es una propuesta concreta para un problema real -- y el enfoque mas convincente hasta ahora de como los sitios web y los agentes de IA se comunicaran en el futuro.
