# MCP y A2A: conectar agentes no resuelve quién acepta el trabajo

> La interoperabilidad de mensajes y herramientas necesita un contrato adicional de resultado, cancelación y responsabilidad.

- Author: Viktor Berthelius (BRTHLS)
- Published: 2026-11-06
- Category: systems thinking
- Tags: mcp, a2a, interoperabilidad
- Language: es
- Canonical: https://www.brthls.com/magazine/mcp-a2a-interoperabilidad-aceptacion-es
- Source: BRTHLS Magazine — https://www.brthls.com

---

## Problema

Un agente puede descubrir otro servicio, enviar una tarea y recibir una respuesta válida para el protocolo. Aun así, el proceso empresarial puede quedar incompleto: nadie sabe si la respuesta significa que el trabajo terminó, que fue aceptado o que todavía necesita una decisión humana.

La interoperabilidad técnica reduce fricción de integración. No define por sí sola qué entiende la organización por una entrega válida ni quién tiene autoridad para convertirla en una acción.

## Tesis

Diseña un contrato de aceptación encima del transporte. La especificación de autorización de MCP consultada aborda el acceso a servidores HTTP en nombre de propietarios de recursos. A2A documenta operaciones de tareas, mensajes, cancelación y artefactos. Esas piezas permiten conectar sistemas; el criterio empresarial de aceptación debe hacerse explícito en la aplicación.

El punto de integración más importante es el cambio de responsabilidad: qué entrega un agente, qué comprueba el receptor y qué ocurre cuando el resultado queda en duda.

## Framework

### Especifica el resultado observable

Describe la salida con su alcance y evidencia. «Preparar propuesta» puede significar redactar un archivo, completar una plantilla o dejar una oferta lista para aprobar. El emisor y el receptor deben coincidir antes de que empiece el trabajo.

Añade los estados que necesitan intervención: faltan datos, permiso insuficiente, resultado parcial o conflicto con una versión nueva. No fuerces todos esos casos dentro de «éxito» y «error». Ocultar la incertidumbre obliga al siguiente agente a adivinar.

### Decide cómo se cancela y cómo se repite

Una solicitud de cancelación no demuestra que los efectos ya iniciados hayan desaparecido. El contrato debe indicar qué se detuvo, qué terminó y qué requiere compensación. Del mismo modo, un reintento debe poder reconocer trabajo previo para evitar duplicados.

La identidad también debe conservar su alcance. Compartir un objetivo no significa compartir todas las credenciales. Cada receptor necesita permisos adecuados al recurso y al trabajo que realmente va a realizar.

### Revisa la evidencia en la frontera

El receptor debe comprobar lo necesario antes de usar la salida: integridad del artefacto, correspondencia con la petición y vigencia de las fuentes. No hace falta repetir toda la ejecución, pero sí impedir que una frase de finalización sustituya al resultado esperado.

### Una propuesta comercial como contrato entre agentes

Imagina que el agente documental entrega un presupuesto al comercial. La siguiente ficha es un contrato de aplicación ilustrativo; no es un objeto normativo de MCP o A2A.

```yaml
trabajo: preparar-propuesta
salida: borrador con partidas y referencias de origen
estado_documental: listo-para-revision
aceptacion_comercial: pendiente
efecto_externo: ninguno
si_cambia_la_tarifa: invalidar el borrador y revisar
si_se_cancela: detener trabajo pendiente y declarar efectos iniciados
si_se_reintenta: consultar el resultado de la misma operación
```

El receptor acepta el documento solo si corresponde a la solicitud vigente, sus referencias son accesibles y las condiciones tienen revisión comercial. La aceptación documental permite continuar la revisión; el envío requiere la autorización correspondiente. Así se evita que un estado técnico se convierta accidentalmente en permiso para comprometer a la empresa.

La [especificación de A2A sobre cancelación](https://a2a-protocol.org/latest/specification/) indica que el servidor intenta cancelar, pero no garantiza conseguirlo. Por eso la prueba debe incluir una cancelación que llega después de generar el archivo y otra durante una operación externa. El receptor necesita conocer el estado devuelto y reconciliar el destino, incluso cuando la interfaz ya dejó de esperar.

Para el reintento, identifica la operación empresarial además del mensaje. Recibir el mismo encargo con otro mensaje no debería generar otra propuesta enviada. Si el servicio no ofrece deduplicación, mantén la operación en revisión hasta consultar su resultado. El identificador de una traza ayuda a investigar, pero no establece por sí mismo esa exclusión.

## Por qué importa ahora

La conexión entre agentes amplía las cadenas de trabajo más allá de una aplicación. Con ello aumentan los puntos donde un estado técnico puede confundirse con un compromiso empresarial. El contrato de aceptación permite cambiar componentes conservando el significado de la entrega.

## Anti-ejemplo

Caso hipotético: el agente comercial recibe «completado» de un agente documental y envía la propuesta al cliente. El documento contenía condiciones sin revisar. Ambos sistemas cumplieron el intercambio de mensajes; ninguno había asumido la aceptación comercial.

## Protocolo (3 pasos)

| Paso | Acuerdo entre sistemas | Prueba |
| --- | --- | --- |
| Definir | Resultado, evidencia y estados intermedios | El receptor sabe qué comprobar |
| Interrumpir | Cancelación y efectos pendientes | No quedan compromisos ocultos |
| Repetir | Reintento y reconocimiento del trabajo previo | No se duplican acciones |

## Relacionado

- [MCP en empresa: el estándar que evita el caos de agentes](/magazine/mcp-empresa-estandar-evita-caos-agentes-es)
- [Agents API: el agente de larga duración necesita un contrato operativo](/magazine/agents-api-contrato-operativo-es)

## Fuentes consultadas

- [Model Context Protocol — Authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)
- [A2A — Especificación del protocolo](https://a2a-protocol.org/latest/specification/)

## Próximo paso

Revisa una integración entre agentes y escribe qué significa «completado» para cada extremo. Si las definiciones difieren, corrige el contrato antes de añadir más conectores.

## Lecturas conectadas

- [MCP en empresa: el estándar que evita el caos de agentes](https://www.brthls.com/magazine/mcp-empresa-estandar-evita-caos-agentes-es) — Conexión editorial.
- [Agents API: el agente de larga duración necesita un contrato operativo](https://www.brthls.com/magazine/agents-api-contrato-operativo-es) — Conexión editorial.
- [A2A + MCP: los protocolos de agentes no son producto, son sistema nervioso](https://www.brthls.com/magazine/a2a-mcp-protocolos-agentes-no-son-producto-son-sistema-nervioso-es) — Temas en común: a2a / mcp.

---

_Cite as: Berthelius, V. (2026). "MCP y A2A: conectar agentes no resuelve quién acepta el trabajo". BRTHLS Magazine. https://www.brthls.com/magazine/mcp-a2a-interoperabilidad-aceptacion-es_