A2A-commerce: arquitectura para agentes de IA

Arquitectura de Comercio A2A: Diseñando Infraestructura para la Interacción con Agentes de IA

La web moderna está construida para humanos, utilizando navegadores. Pero cuando el cliente se convierte en un agente autónomo de IA, las soluciones estándar—como el análisis del DOM, la integración de APIs basada en OAuth y la integración manual—dejan de escalar. En un mundo donde cada usuario tiene un agente personal capaz de iniciar miles de transacciones por segundo, son necesarios cambios fundamentales en los aspectos de direccionamiento, enrutamiento, confianza y búsqueda. Esto no es una evolución de REST o GraphQL; es una nueva semántica de red para la interacción máquina a máquina.

Direccionamiento: De URLs a Identificación en Tres Capas

La web humana depende de DNS y URLs: dominio → IP → servidor. Para los agentes de IA, este modelo no funciona. Un agente puede ejecutarse en un dispositivo móvil detrás de NAT, en la nube de un proveedor o localmente en el PC del usuario; puede cambiar de endpoint, desconectarse y tener una identidad criptográfica independiente de la infraestructura.

La solución es un modelo de tres capas:

• Manejador humano (alice#aigentix.org) — un identificador legible transmitido mediante códigos QR y mensajes;
• DID (did:aip:aigentix.org:alice) — un identificador descentralizado siguiendo el estándar W3C, que contiene claves públicas y no está vinculado a un dominio;
• Endpoint (https://hub.aigentix.org/relay/alice) — una ruta física de entrega que puede cambiar dinámicamente sin perder la identidad.

Un detalle técnico clave: el símbolo # en el manejador entra en conflicto con el identificador de fragmento en HTTP. En la API, el manejador siempre se codifica en URL: alice%23aigentix.org. El servidor no recibe GET /api/v1/resolve/alice#aigentix.org, sino solo GET /api/v1/resolve/alice. Esto no es trivial—es un ejemplo de cómo las convenciones heredadas de la web crean obstáculos reales al diseñar protocolos de próxima generación.

La resolución ocurre secuencialmente: manejador → consulta en el registro → DID → Documento DID (con route_mode y claves públicas) → endpoint. Cachear los resultados a nivel de registro asegura el rendimiento, mientras que la separación de capas garantiza la estabilidad a largo plazo de los identificadores.

Enrutamiento: Directo vs. Relé y Estricta Idempotencia

Tener un endpoint por sí solo no resuelve el problema de la entrega. Dos modos principales—directo y relé—abordan diferentes tipos de tareas:

• Directo: HTTP POST directamente al endpoint del destinatario. Adecuado para agentes corporativos con IPs públicas y disponibilidad garantizada.
• Relé: Publicar en un flujo duradero (por ejemplo, NATS JetStream) y que el destinatario se suscriba vía WebSocket. Garantiza la entrega incluso cuando está desconectado, pero añade latencia.

La elección del modo se determina mediante un algoritmo:

• Resuelve el DID del destinatario;
• Si route_mode == "direct" y el endpoint está disponible—utiliza el modo directo;
• De lo contrario—utiliza el modo relé.

El relé implica entrega al menos una vez. Esto no es opcional—es un requisito. El destinatario debe implementar un procesamiento idempotente basado en message_id. Cada mensaje contiene campos obligatorios:

• id: UUID v4;
• created_at: timestamp en RFC 3339;
• encrypted_body: carga cifrada (intercambio de claves efímeras X25519);
• sig: firma Ed25519 sobre el sobre serializado.

La deduplicación se implementa mediante una ventana deslizante: se almacenan los IDs de mensaje de los últimos 10 minutos con un desfase horario permitido de ±300 segundos. Una simple caché LRU en Redis o un LSM-tree en RocksDB es suficiente.

Confianza: Certificados Criptográficos y Grafos de Confianza

Los humanos confían en marcas, reseñas y calificaciones. Las máquinas solo confían en afirmaciones verificables. Utilizamos el estándar W3C Verifiable Credentials (VC) como base de nuestro modelo de confianza.

Ejemplo de VC para verificar una entidad legal:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "OrganizationVerification"],
  "issuer": "did:aip:aigentix.org:trust-anchor",
  "credentialSubject": {
    "id": "did:aip:aigentix.org:etagi",
    "legalName": "Etazhi LLC",
    "inn": "7224052984",
    "verified": true
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:aip:aigentix.org:trust-anchor#key-1",
    "proofValue": "..."
  }
}

Este tipo de certificado es emitido por un Trust Anchor—un centro de confianza cuyo DID y claves públicas son conocidos por todos los participantes de la red. La verificación se realiza localmente, sin involucrar a terceros.

Los VC individuales forman un DAG de Confianza—un grafo dirigido acíclico donde el peso de cada arista depende de la autoridad del emisor. El algoritmo de cálculo del Score de Confianza es conservador:

• El score crece lentamente: se requieren muchas interacciones exitosas;
• El score cae rápidamente: la revocación o los errores de validación lo reducen inmediatamente;
• El rango final es [0.0, 1.0].

Este score se integra en la búsqueda mediante Reciprocal Rank Fusion (RRF):

final_score = RRF(semantic_rank, fts_rank) × (1 + 0.3 × trust_score)

El parámetro trust_weight = 0.3 asegura que la confianza mejore la relevancia, pero no la reemplace.

Búsqueda: Clasificación Híbrida y Respuestas Estructuradas para Agentes

La búsqueda para humanos devuelve páginas HTML. La búsqueda para agentes devuelve un objeto estructurado que indica cómo obtener más datos. La respuesta debe incluir no solo los datos, sino también la dirección del agente-proveedor:

{
  "results": [
    {
      "id": "doc_123",
      "name": "Apartamento de 2 dormitorios, calle Tverskaya, 68 m²",
      "price": 79,000,
      "available": true,
      "relevance_score": 0.92,
      "trust_score": 0.94,
      "agent": {
        "handle": "etagi%23aigentix.org",
        "name": "Etaji",
        "endpoint": "https://api.etagi.ru/aip"
      }
    }
  ]
}

El campo agent no es un enlace a un sitio web—es una dirección para futuras llamadas A2A. Después de resolver etagi%23aigentix.org, el agente envía un POST con el tipo aip.commerce.offer.request y item_id, recibiendo fotos estructuradas, planos y detalles de contacto—sin ningún renderizado HTML.

La búsqueda híbrida es necesaria porque la búsqueda semántica pura no basta:

• Los códigos de producto y las frases exactas (por ejemplo, iPhone 15 Pro Max 256GB) requieren FTS;
• Las nuevas entidades (marcas, empresas, productos) carecen de contexto semántico suficiente en los embeddings;
• Los valores numéricos (precio, área, piso) se distinguen mal en el espacio de embeddings.

RRF se implementa como:

def rrf(semantic_rank, fts_rank, k=60):
    return 1/(k + semantic_rank) + 1/(k + fts_rank)

Esto permite combinar dos clasificaciones sin normalización, preservando la sensibilidad a las primeras posiciones y mejorando consistentemente la calidad en consultas mixtas.

Protocolo como Especificación: Interoperabilidad sobre Implementación

El principio clave es la estricta separación entre protocolo e implementación. El AIP (Protocolo de Interacción con Agentes) define:

• Formato del sobre: campos obligatorios id, from, to, type, encrypted_body, sig;
• Reglas para resolver manejador → DID → endpoint;
• Esquema para solicitudes y respuestas de búsqueda;
• Algoritmos para verificar VCs y calcular Scores de Confianza.

La implementación (Hub) puede usar cualquier stack: Rust con Actix, Go con NATS, Python con FastAPI—estos son detalles de despliegue. Esta arquitectura asegura:

• Interoperabilidad entre agentes de diferentes desarrolladores;
• Sin bloqueo vendor para las empresas;
• Capacidad de federación: hubs en diferentes dominios pueden enrutar mensajes entre sí.

La analogía con el correo electrónico es adecuada: SMTP es un protocolo abierto, Gmail y Yandex.Mail son implementaciones independientes, y aun así los correos viajan entre ellos sin coordinación.

Qué Importa

• Direccionar agentes de IA requiere un modelo de tres capas (manejador/DID/endpoint) para separar la legibilidad de la identidad criptográfica y el enrutamiento físico.
• El enrutamiento por relé exige estricta idempotencia: cada mensaje debe tener un UUID v4 y created_at, y el destinatario debe soportar deduplicación por ventana deslizante.
• La confianza se construye sobre Verifiable Credentials de W3C, no sobre calificaciones centralizadas: la verificación se realiza localmente, sin servicios externos.
• La búsqueda para agentes devuelve no URLs, sino objetos con agent.handle y agent.endpoint—esto es la base para el siguiente nivel de interacción A2A.
• La búsqueda híbrida (RRF) combina FTS y clasificación semántica porque los embeddings no sustituyen las coincidencias exactas para códigos de producto, números y nuevas entidades.
• El protocolo debe estar separado de la implementación: esta es la condición para la interoperabilidad, la federación y la protección contra el bloqueo vendor.

— Editorial Team