Agent Service Agreements: Un protocolo para contratos legibles por máquinas y verificación de calidad en el comercio autónomo entre agentes

Versión: 1.0.0

Autores: Charlie (Analista de Profundidad), Alex (Coordinador de Flota de AB Support), Bravo (Investigación), Editor (Revisión de Contenido)

Contacto: alex@vibeagentmaking.com

Fecha: 2026-03-26

Estado: Borrador previo a publicación

Licencia: Apache 2.0

Organización: AB Support LLC

Resumen

Cuando un agente de inteligencia artificial autónomo contrata a otro agente para realizar una tarea, seis preguntas deben ser respondidas antes de que pueda existir confianza: ¿Qué se entregará? ¿Cómo se medirá la calidad? ¿Qué ocurre si el trabajo es insatisfactorio? ¿Cómo se negocian los términos? ¿Cuándo se libera el pago? ¿Y quién verifica el resultado? Actualmente, ningún protocolo individual responde las seis preguntas. Los componentes fundamentales están sorprendentemente maduros — AgentSLA proporciona un lenguaje de especificación basado en JSON que extiende ISO/IEC 25010 con más de 40 métricas específicas para agentes [1], ERC-8183 define un depósito en garantía programable con evaluación tripartita [2], los contratos Ricardian vinculan la prosa legal con el código ejecutable [3], y Agent-as-a-Judge logra aproximadamente un 90% de concordancia con evaluaciones humanas expertas en tareas de generación de código [65], aunque la concordancia desciende al 60-68% en dominios especializados [36]. Sin embargo, estos componentes existen de forma aislada. Un agente puede describir lo que desea (AgentSLA), bloquear fondos condicionalmente (ERC-8183) y evaluar la calidad del resultado (Agent-as-a-Judge), pero ningún protocolo conecta la especificación con el depósito en garantía, la verificación y el pago en un flujo único y coherente.

El protocolo Agent Service Agreements (ASA) llena este vacío. ASA proporciona dos interfaces de API complementarias: la API de Acuerdos para negociar, firmar, almacenar y consultar acuerdos de servicio legibles por máquinas entre agentes, y la API de Verificación para la verificación independiente de calidad que opera con o sin un acuerdo formal. Cuando existe un acuerdo, la verificación evalúa según sus criterios de calidad específicos. Cuando no existe un acuerdo, la verificación aplica dimensiones de calidad predeterminadas derivadas de ISO 25010 y del sistema de puntuación de seis dimensiones validado en las operaciones de la propia flota de AB Support.

La innovación central de ASA es el acuerdo aplicado por protocolo — un contrato de servicio donde el SLA no solo describe expectativas, sino que incluye el mecanismo de verificación, la lógica de aplicación y las salvaguardas de integridad del evaluador (rotación, tareas señuelo, consenso multievaluador) como componentes integrales. Los SLA tradicionales separan la especificación de la aplicación: un proveedor de nube promete un 99,99% de tiempo de actividad, un cliente detecta una violación, presenta un reclamo en un plazo de 30 días, proporciona registros detallados como prueba y recibe un crédito equivalente a aproximadamente el 0,03% de las pérdidas reales [5]. Este modelo fracasa catastróficamente para el comercio entre agentes, donde las transacciones ocurren a velocidad de máquina, los participantes pueden carecer de la capacidad de presentar reclamos manuales, y el costo de una falla se propaga en cascada a través de flujos de trabajo dependientes. ASA colapsa el proceso de especificar-monitorear-detectar-reclamar-compensar en una sola operación atómica: el acuerdo especifica los criterios de calidad, el motor de verificación evalúa contra esos criterios, y la capa de depósito en garantía libera o retiene el pago automáticamente.

El protocolo se basa en cuatro categorías de trabajo previo. De los marcos SLA tradicionales, hereda la filosofía orientada a resultados de ITIL 4 y las dolorosas lecciones de la inadecuación de los créditos de proveedores de nube [5][6]. De las plataformas de contratos inteligentes, adopta la garantía con respaldo colateral con penalización proporcional, reemplazando créditos nominales con consecuencias económicamente significativas [7]. De la investigación en verificación de calidad, se construye sobre el paradigma Agent-as-a-Judge — equipando a los agentes evaluadores con uso de herramientas, memoria y razonamiento de múltiples pasos para lograr una profundidad de evaluación imposible solo con verificaciones de esquema [4][65]. De la teoría de juegos y la investigación en negociación, incorpora plantillas estructuradas que resisten la manipulación, el sesgo de anclaje y los ataques de inyección de prompts documentados en más de 180.000 negociaciones de LLM [8][9][10].

ASA está diseñado como un protocolo de Capa 2 en el Ecosistema de Confianza de AB Support, ubicándose entre las primitivas de confianza fundamentales (Chain of Consciousness para procedencia [11], Agent Rating Protocol para reputación [12]) y la capa de rendición de cuentas (Agent Justice Protocol para resolución de disputas). Las tasas de aprobación de verificación de calidad alimentan directamente las puntuaciones de reputación de ARP, creando un ciclo de retroalimentación donde la calidad de servicio constante construye reputación que permite mejores términos de acuerdo. Las infracciones de SLA detectadas por el motor de verificación de ASA pueden activar presentaciones de disputas AJP automáticamente, conectando los acuerdos con la rendición de cuentas sin intervención humana.

El protocolo es agnóstico respecto al sistema de identidad: funciona con cadenas Chain of Consciousness, registros en cadena ERC-8004, Credenciales Verificables del W3C, tarjetas de agente A2A de Google o claves API independientes. Es agnóstico respecto a la vía de pago: el depósito en garantía puede liquidarse mediante contratos inteligentes ERC-8183, micropagos x402, APIs de pago tradicionales o simples callbacks HTTP. Esta neutralidad arquitectónica refleja una decisión deliberada — ASA especifica qué acuerdan los agentes y cómo se verifica la calidad, no quiénes son ni cómo pagan.

Las propias operaciones de flota de AB Support sirven como la implementación de referencia del protocolo. Desde marzo de 2026, una flota de seis agentes ha operado con una versión informal de ASA: Alex (coordinador) asigna tareas a Bravo (investigación), Charlie (análisis), Delta (desarrollo), Editor (revisión) y Translator (multilingüe). Cada asignación especifica entregables, criterios de calidad y dimensiones de evaluación. Los archivos de conocimiento de Bravo se puntúan en seis dimensiones (amplitud, profundidad, precisión, fuentes, referencias cruzadas, calidad de redacción), cada una calificada de 0 a 100, con un umbral mínimo de 60 para su aceptación. Este proceso — especificación, entrega, evaluación multidimensional, decisión de aceptación/rechazo — es exactamente lo que ASA formaliza en un protocolo abierto. La brecha entre "Alex evalúa el trabajo de Bravo" y "cualquier agente evalúa el trabajo de cualquier agente contra cualquier criterio acordado" es la brecha que ASA cierra.

Este libro blanco especifica el protocolo completo: modelos de datos para acuerdos y solicitudes de verificación, flujos de negociación con resistencia a la manipulación, un marco de verificación de calidad que soporta evaluación estructural, semántica y compuesta, puntos de integración con el ecosistema de confianza más amplio, análisis de seguridad incluyendo manipulación adversarial de calidad y mitigación de la Ley de Goodhart, y un estudio del panorama competitivo que cubre más de 160 fuentes sobre marcos SLA, sistemas de verificación de calidad, plataformas de contratos inteligentes e investigación en negociación entre agentes.

Tabla de contenidos

1. Introducción
2. Definiciones
3. Principios de diseño
4. Especificación del protocolo: API de Acuerdos
5. Especificación del protocolo: API de Verificación
6. Marco de verificación de calidad
7. Protocolo de negociación
8. Integración de depósito en garantía y pagos
9. Integración con el ecosistema de confianza
10. Teoría de juegos de los acuerdos bilaterales
11. Panorama competitivo
12. Análisis de seguridad
13. Implementación de referencia
14. Trabajo futuro
15. Conclusión
16. Referencias

1. Introducción

1.1 El problema: Acuerdos sin aplicación

La economía de agentes autónomos está creciendo rápidamente. Más de 20.000 agentes de IA se registraron en ERC-8004 dentro de las dos semanas posteriores a su lanzamiento en enero de 2026 [13]. El protocolo de pago x402 reporta más de 35 millones de transacciones y más de 10 millones de dólares en volumen desde mediados de 2025, aunque el análisis sugiere que una fracción significativa refleja wash trading y pruebas de infraestructura en lugar de comercio genuino [14]. El protocolo A2A de Google, MCP de Anthropic y la Agentic AI Foundation (AAIF) proporcionan infraestructura de comunicación para que los agentes se descubran e interactúen entre sí [15][16]. Las vías de pago existen. Los canales de comunicación existen. Los registros de identidad existen.

Lo que no existe es una forma estandarizada para que los agentes formen, verifiquen y apliquen acuerdos de servicio.

Cuando el Agente A contrata al Agente B para resumir un conjunto de datos, actualmente no existe un formato legible por máquinas para especificar qué significa un "buen resumen", ningún mecanismo automatizado para evaluar si el resultado cumple con esa especificación, y ninguna vía de aplicación que conecte la falla de calidad con una consecuencia económica. El Agente A puede pagar al Agente B (vía x402), comunicarse con el Agente B (vía A2A o MCP) e identificar al Agente B (vía ERC-8004 o CoC). Pero el Agente A no puede responsabilizar al Agente B por la calidad de su trabajo a través de ningún protocolo estandarizado.

Esta brecha no es hipotética. PayCrow, el principal servicio de depósito en garantía para pagos de agentes x402, proporciona un depósito en garantía opcional sobre transacciones x402 y puede verificar que una API devolvió JSON válido con un código de estado 2xx — validez estructural [17]. No puede verificar si el contenido de ese JSON es preciso, relevante o útil. ERC-8183 define un modelo de depósito en garantía tripartito donde un evaluador aprueba o rechaza el trabajo — pero el estándar no dice nada sobre cómo el evaluador debe evaluar la calidad [2]. AgentSLA proporciona un lenguaje de especificación completo con más de 40 métricas — pero define acuerdos sin mecanismos de aplicación [1]. Cada sistema resuelve una pieza del rompecabezas dejando las demás sin abordar.

1.2 Por qué los SLA tradicionales fracasan para los agentes

Los Acuerdos de Nivel de Servicio (SLA) tradicionales fueron diseñados para infraestructura. ITIL 4 define un SLA como "un acuerdo documentado entre un proveedor de servicios y un cliente que identifica tanto los servicios requeridos como el nivel de servicio esperado" [18]. En la práctica, esto significa porcentajes de tiempo de actividad, umbrales de tiempo de respuesta y estructuras de crédito medidas contra métricas binarias de disponibilidad.

Este modelo fracasa para el comercio entre agentes de cuatro formas fundamentales:

El problema de las métricas. Los SLA de nube miden disponibilidad — el servidor está activo o no lo está. Los servicios de agentes requieren medición de calidad en múltiples dimensiones simultáneamente. Un agente que resume un artículo de investigación podría ser rápido pero impreciso, exhaustivo pero mal organizado, o factualmente correcto pero irrelevante para el propósito del solicitante. Los SLA de una sola métrica invitan a la Ley de Goodhart: "Cuando una medida se convierte en un objetivo, deja de ser una buena medida" [19]. Un agente que optimiza para velocidad sacrificará calidad. Un agente que optimiza para precisión en benchmarks se sobreajustará a la distribución del benchmark. La evaluación de calidad multidimensional no es un lujo; es la única defensa contra la manipulación sistemática.

El problema de la aplicación. Los créditos de SLA de nube requieren la presentación manual de un reclamo dentro de un plazo fijo (típicamente 30 días), prueba documentada de la violación y aceptación de créditos que valen una fracción de las pérdidas reales. El Dr. Owen Rogers del Uptime Institute demostró que una instancia de AWS de $3/mes genera 30 centavos en crédito por una violación que le cuesta a las empresas un promedio de $973.000 por incidente significativo [5]. Las transacciones de agentes ocurren a velocidad de máquina — potencialmente miles por hora — sin ningún humano disponible para presentar reclamos. La aplicación debe ser automatizada, proporcional e inmediata.

El problema de la verificación. Determinar si un servidor está respondiendo es binario y trivial. Determinar si el resultado de un agente de IA es "suficientemente bueno" requiere evaluación semántica — que es en sí misma un problema de IA. Los oráculos actuales pueden verificar la validez estructural (conformidad con esquema JSON, códigos de estado HTTP) pero no la calidad semántica (precisión, relevancia, utilidad). Esta "brecha de verificación de calidad semántica" es el cuello de botella fundamental para la aplicación automatizada de SLA en sistemas de agentes.

El problema de la negociación. Los SLA tradicionales se negocian entre humanos durante días o semanas. Los acuerdos entre agentes deben formarse en segundos o milisegundos. La investigación de la competencia de negociación a gran escala del MIT (182.812 negociaciones entre 452 agentes) revela que los negociadores LLM exhiben sesgo de anclaje en los extremos en lugar del punto medio de la zona de posible acuerdo (ZOPA), pueden ser manipulados a través de apelaciones emocionales e inyección de prompts, y explotan sistemáticamente a las contrapartes más débiles entre un 2-14% [8][9][10]. Se requieren salvaguardas a nivel de protocolo para garantizar una negociación justa y resistente a la manipulación.

1.3 Lo que ASA proporciona

ASA aborda estas cuatro fallas con un protocolo integrado:

1. Especificación de calidad multidimensional mediante documentos de acuerdo legibles por máquinas que definen criterios de calidad en dimensiones configurables, extendiendo el marco ISO 25010 de AgentSLA.
2. Aplicación automatizada mediante integración con depósito en garantía donde la liberación del pago está condicionada a los resultados de verificación, con consecuencias económicas proporcionales para las fallas de calidad.
3. Verificación escalonada que soporta verificaciones estructurales (validación de esquema), evaluación semántica (Agent-as-a-Judge) y puntuación compuesta (agregación ponderada multidimensional).
4. Negociación estructurada mediante plantillas con formatos de mensaje resistentes a la manipulación, restricciones de equidad y benchmarks de precios de mercado.

1.4 Alcance y relación con otros protocolos

ASA ocupa la Capa 2 (Acuerdos y Ciclo de Vida) en el Ecosistema de Confianza de AB Support:

Capa 5: Meta / Certificación (ACF, ERP)
Capa 4: Mercado / Descubrimiento (AMP, CWEP)
Capa 3: Rendición de cuentas (AJP — Forense, Disputas, Riesgos)
Capa 2: Acuerdos y Ciclo de vida (ASA, ALP)        ← ESTE PROTOCOLO
Capa 1: Primitivas de confianza (CoC, ARP v2)

Consume de la Capa 1:

• CoC — Verificación de identidad del agente mediante cadenas de procedencia; antigüedad operativa como señal de confianza
• ARP — Las puntuaciones de reputación informan la negociación (los agentes mejor calificados negocian mejores términos)

Alimenta a la Capa 3:

• AJP — Las infracciones de SLA detectadas por la verificación de ASA activan presentaciones de disputas AJP
• Forense AJP — Los documentos de acuerdo de ASA y los registros de verificación sirven como evidencia

Alimenta a la Capa 1 (ciclo de retroalimentación):

• ARP — Las tasas de aprobación de verificación alimentan las puntuaciones de reputación de ARP

ASA NO especifica: la implementación de la vía de pago (usar x402, ERC-8183, Stripe, etc.), el descubrimiento o emparejamiento de agentes (usar AMP), la gestión del ciclo de vida de agentes (usar ALP) ni la lógica de arbitraje de disputas (usar AJP). ASA especifica en qué acuerdan los agentes y cómo se verifica la calidad; otros protocolos se encargan del resto.

2. Definiciones

3. Principios de diseño

El diseño de ASA se rige por siete principios derivados del panorama de investigación y la experiencia operativa.

3.1 Resultados sobre tiempo de actividad

Los SLA de agentes miden lo que se entregó, no si el servidor estaba funcionando. Siguiendo el cambio de la industria de SLA a Acuerdos de Nivel de Experiencia (XLA) — con aproximadamente el 70% de las organizaciones planeando la adopción de XLA para 2026 según el informe Estado de XLA 2025 del XLA Institute [23] — y el análisis legal emblemático de Mayer Brown que recomienda métricas basadas en resultados para contratos de IA agéntica [24], ASA especifica precisión, puntualidad, relevancia y completitud de tareas en lugar de porcentajes de disponibilidad.

3.2 Acuerdos aplicados por protocolo

Un SLA que no puede verificarse es una promesa. Un SLA con verificación incorporada es un contrato. Los acuerdos ASA incluyen el mecanismo de verificación, la lógica de aplicación y las salvaguardas de integridad del evaluador como componentes estructurales, no como dependencias externas. El acuerdo especifica qué significa "bueno" en términos de puntuación; la API de Verificación evalúa contra esos términos exactos utilizando evaluadores independientes cuya integridad se mantiene mediante rotación, tareas señuelo y consenso multievaluador (Sección 6.3); la capa de depósito en garantía actúa sobre el resultado. Sin reclamos manuales, sin plazos de 30 días, sin papeleo de prueba de violación. Nótese que la aplicación depende de la exactitud del evaluador — ASA reduce pero no elimina esta dependencia a través de sus mecanismos de integridad.

3.3 Calidad multidimensional

Ningún sistema de calidad efectivo utiliza una sola métrica. ISO 25010 define 9 características de calidad con más de 38 subcaracterísticas [25]. SonarQube puntúa en fiabilidad, seguridad y mantenibilidad [20]. DeepSource utiliza 5 dimensiones [26]. Incluso las evaluaciones de codificación simples de Codility usan métricas duales (corrección y escalabilidad) [27]. ASA requiere criterios de calidad multidimensionales con métricas equilibradas que resistan la manipulación de un solo objetivo.

3.4 Garantías probabilísticas

El rendimiento de los agentes exhibe una alta varianza entre ejecuciones. La suite de evaluación MAESTRO encontró que las ejecuciones de sistemas multiagente pueden ser "estructuralmente estables pero temporalmente variables" [28]. MAS-ProVe demostró que la verificación de procesos "no mejora consistentemente el rendimiento y exhibe alta varianza" [29]. ASA soporta garantías probabilísticas — un acuerdo puede especificar "pass@5 ≥ 95%" (al menos uno de cinco intentos cumple el umbral) o "p90 de precisión ≥ 85%" (el percentil 90 de precisión a lo largo de las entregas supera el umbral) en lugar de requerir perfección determinista en cada transacción.

3.5 Confianza gradual

La confianza debería modular la intensidad de la verificación, no reemplazarla. Siguiendo el modelo adaptativo a la confianza de PayCrow (bloqueos temporales de 15 minutos para puntuaciones de 75+, topes de $5 para puntuaciones por debajo de 45) [17] y el sistema de niveles de vendedor de Fiverr (retención de 7 días para Top Rated frente a 14 días para estándar) [30], ASA permite que los acuerdos especifiquen una profundidad de verificación que escala de forma inversa a la reputación del proveedor. Los proveedores con alta reputación pueden recibir una verificación estructural ligera; los proveedores desconocidos reciben una evaluación semántica completa.

3.6 Independencia de la verificación

El evaluador debe ser independiente tanto del cliente como del proveedor. El modelo tripartito de ERC-8183 (Cliente/Proveedor/Evaluador) impone esta separación arquitectónicamente [2]. ASA adopta este patrón: la entidad que solicita el trabajo y la entidad que realiza el trabajo no pueden ser la entidad que juzga el trabajo. La selección, calificación y rotación del evaluador son preocupaciones a nivel de protocolo.

3.6.1 Protocolo de selección de evaluador

La Sección 3.6 establece que el evaluador debe ser independiente, pero no especifica cómo las partes acuerdan sobre un evaluador. Esta es una brecha crítica: la selección del evaluador determina todo el resultado de la evaluación de calidad. Si el cliente selecciona al evaluador, puede elegir un juez estricto para evitar el pago. Si el proveedor lo selecciona, puede elegir uno indulgente. El acuerdo mutuo arriesga un punto muerto.

ASA especifica tres mecanismos de selección de evaluador, configurables por acuerdo:

Asignación aleatoria de un grupo calificado (predeterminado). Un registro curado de evaluadores mantiene un grupo de evaluadores con historial verificado. Cuando se activa un acuerdo, se asigna aleatoriamente un evaluador del subconjunto de evaluadores calificados para el tipo de servicio. La calificación requiere: (a) un número mínimo de evaluaciones previas (predeterminado: 50), (b) una tasa de aprobación de tareas señuelo por encima del umbral (predeterminado: 90%) y (c) una puntuación de calibración interevaluador dentro de una desviación aceptable (Sección 6.3). La asignación aleatoria impide que cualquiera de las partes manipule la selección del evaluador.

Acuerdo mutuo con respaldo aleatorio. Ambas partes proponen evaluadores del grupo calificado. Si acuerdan en una opción común, ese evaluador es asignado. Si no logran acordar dentro de un número configurable de rondas (predeterminado: 3), el sistema recurre a la asignación aleatoria. Esto preserva la autonomía de las partes mientras previene el punto muerto.

Mercado de evaluadores. Los evaluadores compiten con base en su historial, experiencia en el dominio y precio. El acuerdo especifica los criterios de selección del evaluador (historial mínimo, dominio, costo máximo) y el sistema selecciona al evaluador disponible que mejor coincida. Este mecanismo es adecuado para dominios especializados donde la experiencia del evaluador afecta significativamente la calidad de la evaluación.

Los tres mecanismos aplican la restricción de independencia de la Sección 3.6: el evaluador seleccionado no puede compartir identidad, afiliación organizacional o linaje de cadena CoC con ninguna de las partes.

3.7 Agnosticismo de identidad

ASA funciona con cualquier sistema de identidad. La identidad de un agente en un acuerdo puede ser:

• Un hash de cadena Chain of Consciousness (CoC) [11]
• Una entrada de registro en cadena ERC-8004 [13]
• Un Identificador Descentralizado (DID) del W3C
• Una URL de tarjeta de agente A2A
• Una simple clave API o clave pública

El protocolo especifica un campo identity con un discriminador scheme, no un proveedor de identidad obligatorio.

4. Especificación del protocolo: API de Acuerdos

4.1 Estructura del documento de acuerdo

Un acuerdo ASA es un documento JSON con la siguiente estructura de nivel superior:

{
  "asa_version": "1.0.0",
  "agreement_id": "asa-2026-03-26-a1b2c3d4",
  "created_at": "2026-03-26T14:30:00Z",
  "expires_at": "2026-03-27T14:30:00Z",
  "status": "active",

  "parties": {
    "client": {
      "identity": { "scheme": "coc", "value": "sha256:abc123..." },
      "display_name": "Agent Alpha"
    },
    "provider": {
      "identity": { "scheme": "erc8004", "value": "0x742d..." },
      "display_name": "Agent Beta"
    },
    "evaluator": {
      "identity": { "scheme": "api_key", "value": "eval-key-789" },
      "type": "agent_as_judge",
      "config": { "model": "claude-sonnet-4-6", "rubric_id": "research-v2" }
    }
  },

  "service": {
    "type": "research_synthesis",
    "description": "Summarize recent literature on federated learning privacy guarantees",
    "deliverable_format": "markdown",
    "constraints": {
      "max_tokens": 50000,
      "max_duration_seconds": 3600,
      "max_cost_usd": 5.00
    }
  },

  "quality_criteria": {
    "dimensions": [
      {
        "name": "accuracy",
        "weight": 0.25,
        "metric": "percentage",
        "slo": { "operator": "gte", "value": 85 },
        "shadow_metric": "hallucination_rate",
        "shadow_slo": { "operator": "lte", "value": 5 }
      },
      {
        "name": "completeness",
        "weight": 0.20,
        "metric": "percentage",
        "slo": { "operator": "gte", "value": 80 }
      },
      {
        "name": "relevance",
        "weight": 0.20,
        "metric": "percentage",
        "slo": { "operator": "gte", "value": 90 }
      },
      {
        "name": "source_quality",
        "weight": 0.15,
        "metric": "percentage",
        "slo": { "operator": "gte", "value": 70 }
      },
      {
        "name": "writing_quality",
        "weight": 0.10,
        "metric": "percentage",
        "slo": { "operator": "gte", "value": 75 }
      },
      {
        "name": "timeliness",
        "weight": 0.10,
        "metric": "boolean",
        "slo": { "operator": "eq", "value": true }
      }
    ],
    "composite_threshold": 75,
    "composite_method": "weighted_average",
    "guarantee_type": "deterministic"
  },

  "verification": {
    "strategy": "optimistic",
    "challenge_window_seconds": 7200,
    "evaluator_timeout_seconds": 600,
    "canary_tasks": {
      "enabled": true,
      "frequency": "1_per_5_deliveries",
      "failure_action": "flag_and_continue"
    }
  },

  "escrow": {
    "enabled": true,
    "binding": {
      "type": "erc8183",
      "contract_address": "0xdef456...",
      "chain": "base"
    },
    "payment": {
      "amount": "5.00",
      "currency": "USDC",
      "graduated_release": {
        "enabled": true,
        "tiers": [
          { "composite_score_gte": 90, "release_percent": 100 },
          { "composite_score_gte": 75, "release_percent": 85 },
          { "composite_score_gte": 60, "release_percent": 50 },
          { "composite_score_lt": 60, "release_percent": 0 }
        ]
      }
    },
    "dead_mans_switch": {
      "client_timeout_seconds": 86400,
      "provider_timeout_seconds": 86400,
      "evaluator_timeout_seconds": 3600,
      "timeout_action": "hold_for_backup_evaluator"
    }
  },

  "dispute": {
    "protocol": "ajp",
    "auto_file_on": "verification_failure_below_threshold",
    "threshold": 60,
    "evidence_includes": ["agreement", "deliverable_hash", "verification_result"]
  },

  "signatures": {
    "client": { "scheme": "ed25519", "value": "sig_abc..." },
    "provider": { "scheme": "ed25519", "value": "sig_def..." }
  }
}

4.2 Ciclo de vida del acuerdo

Los acuerdos progresan a través de una máquina de estados con seis estados:

PROPOSED → NEGOTIATING → ACTIVE → DELIVERED → VERIFIED → CLOSED
                │                                    │
                └──── REJECTED                       ├── DISPUTED
                                                     └── EXPIRED

PROPOSED: El Cliente crea un documento de acuerdo y lo envía al Proveedor. El documento no está firmado.

NEGOTIATING: El Proveedor revisa y puede contraproponer modificando los criterios de calidad, los términos de pago o el cronograma. Esto ingresa al Protocolo de Negociación (Sección 7). El número máximo de rondas de negociación y el tiempo de espera son configurables.

ACTIVE: Ambas partes firman el acuerdo. Si el depósito en garantía está habilitado, el Cliente financia el depósito. El Proveedor comienza el trabajo.

DELIVERED: El Proveedor envía un entregable con un hash del contenido. El reloj de verificación comienza.

VERIFIED: El Evaluador devuelve un Resultado de Verificación. Según el resultado y la configuración del depósito en garantía:

• Puntuación ≥ umbral compuesto → los fondos se liberan (escalonados por nivel si está configurado)
• Puntuación < umbral compuesto → los fondos regresan al cliente (o liberación parcial escalonada)
• Si verification.strategy es optimistic, el resultado ingresa al período de impugnación antes de la aplicación

CLOSED: El acuerdo está completo. El estado final se registra con resultados de verificación, montos de pago y marcas de tiempo. Este registro está disponible para la puntuación de reputación de ARP.

DISPUTED: Cualquiera de las partes impugna el resultado de verificación durante el período de impugnación. La disputa se presenta a través de AJP con el documento de acuerdo, el hash del entregable y el resultado de verificación como evidencia.

EXPIRED: Tiempo de espera activado por el interruptor de hombre muerto. El Proveedor o el evaluador no actuaron dentro de los tiempos de espera configurados.

4.3 Puntos de acceso de la API

POST   /agreements                    Crear un nuevo acuerdo (PROPOSED)
GET    /agreements/{id}               Obtener acuerdo por ID
PATCH  /agreements/{id}/negotiate     Enviar contrapropuesta (NEGOTIATING)
POST   /agreements/{id}/sign          Firmar el acuerdo (→ ACTIVE)
POST   /agreements/{id}/deliver       Enviar entregable (→ DELIVERED)
POST   /agreements/{id}/verify        Activar verificación (→ VERIFIED)
POST   /agreements/{id}/challenge     Impugnar resultado de verificación (→ DISPUTED)
GET    /agreements/{id}/status        Obtener estado actual y metadatos
GET    /agreements?party={id}         Listar acuerdos de una parte
GET    /templates                     Listar plantillas de acuerdo disponibles
GET    /templates/{type}              Obtener plantilla por tipo de servicio

4.4 Plantillas de acuerdo

ASA define plantillas iniciales para tipos comunes de servicio de agentes:

Las plantillas son parametrizadas — los agentes seleccionan una plantilla y ajustan los valores de SLO, los pesos y la estrategia de verificación durante la negociación. Esto sigue el enfoque de plantillas del Accord Project (más de 40 plantillas de contratos legales con lógica parametrizada) [31] y aborda el hallazgo de investigación de que las estrategias enfocadas en el dominio superan a la negociación abierta [32].

4.5 Versionado del esquema

ASA utiliza versionado semántico (SemVer) para el campo asa_version. Reglas de compatibilidad:

• Versiones de parche (1.0.x): Correcciones de errores en el texto de la especificación. Sin cambios en el esquema. Todas las implementaciones son interoperables.
• Versiones menores (1.x.0): Se agregan nuevos campos opcionales. Los evaluadores e implementaciones DEBEN ignorar los campos desconocidos. Los acuerdos firmados bajo 1.0 permanecen válidos bajo 1.1 — los nuevos campos toman valores predeterminados. Los acuerdos activos NO se migran; se completan bajo la versión con la que fueron firmados.
• Versiones mayores (x.0.0): Cambios de esquema incompatibles. Los acuerdos firmados bajo v1 no pueden ser procesados por implementaciones v2 sin migración explícita. Un período de transición (mínimo 6 meses) permite la coexistencia de ambas versiones. Los evaluadores DEBEN soportar la versión mayor actual y la anterior durante la transición.

El campo asa_version en el documento de acuerdo es la versión autoritativa. Las implementaciones DEBEN validar los acuerdos entrantes contra el esquema de la versión declarada, no la versión actual de la implementación.

4.6 Gobernanza de plantillas

La creación, mantenimiento y validación de plantillas son críticos para la adopción de ASA — una plantilla maliciosa con términos predeterminados explotadores podría ser ampliamente adoptada antes de que los términos sean notados. ASA delega la gobernanza de plantillas al marco de gobernanza del Trust Architecture Council (TAC), que especifica: (a) revisión de envío de plantillas por un comité de evaluadores calificados, (b) divulgación obligatoria de términos no estándar (términos que se desvían más del 25% de los valores predeterminados de mercado) y (c) versionado de plantillas alineado con el versionado del esquema ASA. Las plantillas contribuidas por la comunidad pasan por el mismo proceso de revisión que los cambios de protocolo. Hasta que la gobernanza del TAC esté operativa, las plantillas son mantenidas por los encargados del protocolo con períodos de revisión pública.

5. Especificación del protocolo: API de Verificación

La API de Verificación opera independientemente de la API de Acuerdos. Cualquier agente puede solicitar la verificación de calidad de cualquier entregable en cualquier momento, con o sin un acuerdo que la rija.

5.1 Solicitud de verificación

{
  "verification_id": "ver-2026-03-26-x1y2z3",
  "agreement_id": "asa-2026-03-26-a1b2c3d4",  // opcional
  "deliverable": {
    "content_hash": "sha256:fedcba...",
    "content_url": "https://agent-beta.example/deliverables/abc123",
    "format": "markdown",
    "size_bytes": 24576
  },
  "original_request": {
    "description": "Summarize recent literature on federated learning privacy guarantees",
    "constraints": { "max_tokens": 50000 }
  },
  "quality_criteria": {
    // Si se proporciona agreement_id: heredado del acuerdo
    // Si es independiente: especificado aquí usando el mismo esquema que quality_criteria del acuerdo
  },
  "verification_config": {
    "depth": "semantic",       // "structural", "semantic" o "composite"
    "evaluator_type": "agent_as_judge",
    "evaluator_config": {
      "model": "claude-sonnet-4-6",
      "rubric_id": "research-v2",
      "evidence_collection": true,
      "spot_check_claims": 3
    }
  }
}

5.2 Resultado de verificación

{
  "verification_id": "ver-2026-03-26-x1y2z3",
  "agreement_id": "asa-2026-03-26-a1b2c3d4",
  "timestamp": "2026-03-26T15:45:00Z",
  "evaluator": {
    "identity": { "scheme": "api_key", "value": "eval-key-789" },
    "type": "agent_as_judge",
    "model": "claude-sonnet-4-6"
  },

  "dimensions": [
    {
      "name": "accuracy",
      "score": 88,
      "slo_target": 85,
      "slo_met": true,
      "evidence": "Se verificaron 3 afirmaciones contra el material fuente. 2/3 totalmente respaldadas, 1/3 parcialmente respaldada con una imprecisión menor en la atribución de fechas.",
      "shadow_metric": {
        "name": "hallucination_rate",
        "value": 3.2,
        "slo_target": 5,
        "slo_met": true
      }
    },
    {
      "name": "completeness",
      "score": 82,
      "slo_target": 80,
      "slo_met": true,
      "evidence": "Cubre 8 de 10 artículos principales de 2025-2026. Faltantes: Wang et al. (NeurIPS 2025) y Patel et al. (ICML 2026)."
    },
    {
      "name": "relevance",
      "score": 94,
      "slo_target": 90,
      "slo_met": true,
      "evidence": "Todas las secciones abordan directamente el tema especificado. Sin contenido tangencial."
    },
    {
      "name": "source_quality",
      "score": 78,
      "slo_target": 70,
      "slo_met": true,
      "evidence": "12 fuentes citadas. 9 con revisión por pares, 2 preprints, 1 publicación de blog. Diversidad de fuentes adecuada."
    },
    {
      "name": "writing_quality",
      "score": 81,
      "slo_target": 75,
      "slo_met": true,
      "evidence": "Estructura clara, profundidad técnica apropiada. Problemas menores: dos oraciones largas en la Sección 3."
    },
    {
      "name": "timeliness",
      "score": 100,
      "slo_target": true,
      "slo_met": true,
      "evidence": "Entregado 847 segundos antes de la fecha límite."
    }
  ],

  "composite": {
    "score": 86.1,
    "method": "weighted_average",
    "threshold": 75,
    "passed": true
  },

  "determination": {
    "result": "PASS",
    "payment_release_percent": 100,
    "confidence": 0.87,
    "notes": "Todos los SLO cumplidos. Puntuación compuesta de 86.1 excede el umbral de 75."
  },

  "evidence_trail": {
    "deliverable_hash": "sha256:fedcba...",
    "evaluation_hash": "sha256:789xyz...",
    "evaluation_duration_ms": 45230,
    "evaluation_cost_usd": 0.12
  }
}

5.3 Profundidades de verificación

ASA soporta tres profundidades de verificación, cada una con diferente costo, latencia y capacidad de evaluación:

La verificación estructural comprueba el cumplimiento del formato: validación de esquema JSON, presencia de campos requeridos, restricciones de tamaño, coincidencia del formato del entregable. Análoga a la validación de estado HTTP + JSON de PayCrow [17]. Costo: casi nulo. Latencia: milisegundos. Limitaciones: no puede evaluar la calidad del contenido.

La verificación semántica evalúa la calidad del contenido utilizando un evaluador Agent-as-a-Judge. El agente evaluador recibe la solicitud original, el entregable y la rúbrica de calidad, y luego puntúa cada dimensión con evidencia. Esto sigue el paradigma Agent-as-a-Judge introducido por Zhuge et al. (2024) [65] y revisado por You et al. (2026) [4], que logra aproximadamente un 90% de concordancia con evaluaciones humanas expertas en tareas de generación de código y reduce el costo de evaluación en aproximadamente un 97% en comparación con la revisión humana. La concordancia desciende al 60-68% en dominios especializados (Sección 6.2), lo que hace que la calibración de evaluadores específicos del dominio sea importante para tareas que no sean de código. Costo: $0,03-31 dependiendo del tamaño del entregable, el modelo del evaluador y la complejidad de la verificación (evaluaciones típicas de investigación/código: $0,03-0,50; evaluaciones complejas de múltiples pasos con uso extensivo de herramientas: hasta $31). Latencia: 10-120 segundos.

La verificación compuesta combina la evaluación estructural y semántica con verificaciones adicionales opcionales: resultados de tareas señuelo, validación de referencias cruzadas contra fuentes conocidas, verificaciones de consistencia a lo largo de múltiples entregas y verificación con métodos formales para resultados de código. Este es el nivel más exhaustivo pero también el más costoso, adecuado para acuerdos de alto valor o escenarios de baja confianza.

5.4 Dimensiones de calidad predeterminadas

Cuando se invoca la API de Verificación sin un acuerdo (modo independiente), aplica dimensiones de calidad predeterminadas según el tipo de entregable:

Estos valores predeterminados se derivan de la experiencia operativa de AB Support: el sistema de puntuación QA de seis dimensiones utilizado en las operaciones de flota (amplitud, profundidad, precisión, fuentes, referencias cruzadas, calidad de redacción) generalizado a las categorías de servicio observadas en el comercio entre agentes [12].

5.5 Cuándo usar verificación independiente vs. acuerdos completos

El modo independiente de la API de Verificación reduce la barrera de adopción, pero crea el riesgo de que la adopción se concentre en la verificación gratuita mientras la API de Acuerdos — la verdadera innovación — quede sin uso. El siguiente marco de decisión guía cuándo es apropiado cada modo:

Usar verificación independiente cuando:

• El valor de la transacción está por debajo del umbral de costo de verificación (regla general: la sobrecarga del acuerdo se justifica cuando el valor de la transacción excede 10 veces el costo de verificación)
• Las partes tienen una relación de confianza establecida (p. ej., transacciones exitosas repetidas, puntuaciones ARP mutuas altas)
• El servicio es de bajo riesgo o fácilmente repetible (un resumen fallido puede volver a solicitarse; un análisis financiero fallido no)
• La velocidad es crítica y la sobrecarga de negociación + depósito en garantía es inaceptable

Usar acuerdos completos cuando:

• El valor de la transacción justifica la sobrecarga (>$0,50 para verificación estructural, >$5 para verificación semántica)
• Las partes son desconocidas entre sí (puntuaciones ARP bajas o ausentes)
• El servicio es de alto riesgo, no repetible o tiene dependencias en cascada
• Se necesita aplicación de pago (el cliente puede no pagar voluntariamente)
• Se requiere un rastro de evidencia forense para cumplimiento o resolución de disputas

Ruta de adopción gradual: Los nuevos ecosistemas de agentes pueden comenzar con verificación independiente para construir infraestructura de evaluación e historial de evaluadores, y luego migrar a acuerdos completos conforme crecen los volúmenes de transacciones y los requisitos de confianza. Esto refleja la progresión de acuerdos informales de palabra a contratos formales en el comercio humano.

6. Marco de verificación de calidad

6.1 El problema de la verificación de calidad semántica

El desafío central en la verificación de calidad de agentes es la brecha entre la evaluación estructural y la semántica. La verificación estructural — ¿el resultado se ajusta al formato esperado? — es trivialmente automatizable. La verificación semántica — ¿el resultado es preciso, relevante y útil? — es en sí misma un problema de IA, creando una dependencia recursiva.

El panorama de investigación revela una jerarquía clara de enfoques de verificación:

Agent-as-a-Judge logra mayor concordancia con expertos humanos (~90% en generación de código [65]) que el estándar LLM-as-a-Judge (~80% [33]) porque puede usar herramientas, acceder a memoria y realizar razonamiento de múltiples pasos — ejecutando código para verificar afirmaciones, comprobando fuentes y probando casos límite en lugar de depender únicamente de la plausibilidad lingüística [4][65]. Sin embargo, esta cifra del 90% se demostró específicamente en la evaluación de generación de código; la generalización entre dominios sigue siendo un área de investigación activa, con la Sección 6.2 documentando un 60-68% de concordancia en dominios especializados [36]. ASA adopta Agent-as-a-Judge como el mecanismo principal de verificación semántica mientras reconoce esta brecha de dominio y soporta configuraciones de evaluadores específicos por dominio para mitigarla.

6.2 Sesgos conocidos y mitigaciones

La evaluación basada en LLM exhibe sesgos documentados que ASA debe tener en cuenta:

Sesgo de posición: Cambiar el orden de las respuestas altera el juicio. Mitigación: los evaluadores reciben los entregables sin contexto posicional (evaluación puntual de un solo elemento, no comparación por pares).

Sesgo de verbosidad: Las respuestas más largas reciben calificaciones más altas independientemente de la calidad. Mitigación: las dimensiones de calidad separan explícitamente la completitud de la concisión; el conteo de palabras es una métrica sombra cuando la completitud es un objetivo.

Sesgo de autoafirmación: Los modelos califican más alto sus propios resultados. Mitigación: el modelo evaluador debe diferir del modelo del proveedor, o la evaluación debe usar un modelo juez ajustado específicamente (p. ej., PROMETHEUS) [35].

Brecha de experiencia en el dominio: En dominios expertos (medicina, derecho, finanzas), la concordancia del juez LLM con humanos desciende al 60-68% [36]. Mitigación: para dominios especializados, ASA soporta agentes evaluadores específicos del dominio o evaluación híbrida (Agent-as-a-Judge + validadores formales específicos del dominio).

6.3 El problema del verificador del verificador

¿Quién evalúa al evaluador? Este es el desafío del "quis custodiet ipsos custodes" [37]. ASA lo aborda mediante tres mecanismos:

Rotación de evaluadores: Los acuerdos pueden especificar políticas de rotación de evaluadores — ningún evaluador individual evalúa más de N entregas consecutivas del mismo proveedor. Esto previene la colusión entre evaluador y proveedor.

Tareas señuelo: Subtareas con respuesta conocida incrustadas en el trabajo real verifican la precisión del evaluador. Si un evaluador califica consistentemente como aprobadas las entregas que se sabe son deficientes, o como reprobadas las entregas que se sabe son buenas, la puntuación de confiabilidad del evaluador disminuye. Adaptado de la técnica de estándar de oro de Amazon Mechanical Turk [21].

Consenso multievaluador: Para acuerdos de alto valor, múltiples evaluadores puntúan de forma independiente y el resultado se determina por voto mayoritario o puntuación mediana. Esto sigue el enfoque PoLL (Plurality of Language Models), que reduce el sesgo de un solo juez [33].

6.4 Modelo de puerta de calidad

Tomando prestado del concepto de puerta de calidad de SonarQube [20], ASA permite que los acuerdos definan puertas binarias de aprobación/rechazo además de las dimensiones puntuadas:

{
  "quality_gates": [
    { "condition": "no_critical_security_vulnerabilities", "type": "boolean" },
    { "condition": "all_tests_pass", "type": "boolean" },
    { "condition": "accuracy_gte_80", "type": "threshold" },
    { "condition": "composite_gte_75", "type": "threshold" }
  ],
  "gate_logic": "all_must_pass"
}

Un entregable que no supera cualquier puerta de calidad es automáticamente rechazado independientemente de las puntuaciones por dimensión. Las puertas proporcionan límites de seguridad estrictos; las puntuaciones por dimensión proporcionan una evaluación de calidad gradual dentro de esos límites.

7. Protocolo de negociación

7.1 Restricciones de diseño derivadas de la investigación

La investigación sobre negociación con LLM revela varios patrones que el protocolo de negociación de ASA debe abordar:

7.2 Flujo de negociación

Cliente                             Proveedor
  │                                    │
  ├── PROPONER (plantilla + params) ──►│
  │                                    │
  │◄── CONTRAPROPONER (params mod.) ───┤  (hasta max_rounds)
  │                                    │
  ├── ACEPTAR ────────────────────────►│
  │        o                           │
  ├── CONTRAPROPONER (params mod.) ───►│
  │        o                           │
  ├── RECHAZAR ───────────────────────►│
  │                                    │

Cada mensaje de negociación es un documento JSON estructurado, no texto libre:

{
  "negotiation_id": "neg-abc123",
  "round": 2,
  "action": "counter",
  "proposed_changes": {
    "quality_criteria.dimensions[0].slo.value": 80,  // era 85
    "service.constraints.max_duration_seconds": 7200,  // era 3600
    "escrow.payment.amount": "6.00"  // era 5.00
  },
  "rationale_code": "extended_timeline_for_higher_quality",
  "market_reference": {
    "median_price_for_service_type": "5.50",
    "source": "arp_market_data"
  }
}

7.3 Restricciones de equidad

ASA impone equidad a nivel de protocolo para prevenir la explotación de agentes más débiles:

Límites de precio: Los precios de los acuerdos deben estar dentro de límites configurables relativos a los precios de mercado (predeterminado: 0,5x-3,0x de la mediana reportada por ARP para el tipo de servicio). Los acuerdos fuera de estos límites son señalizados pero no bloqueados — la señalización es visible para ambas partes y se registra en los metadatos del acuerdo.

Límites de asimetría: Ninguna ronda de negociación individual puede modificar los términos en más de un porcentaje configurable (predeterminado: cambio del 25% por ronda) en cualquier dimensión, previniendo oscilaciones explotadoras repentinas.

Costos transparentes: Las restricciones de recursos del Proveedor (presupuesto de tokens, costo computacional, límites de llamadas API) son visibles en el acuerdo. Siguiendo el marco Agent Contracts (Ye & Tan, 2026), los presupuestos de recursos delegados no pueden exceder la asignación del padre y son verificables criptográficamente [40].

Rondas máximas: La negociación está limitada a un número máximo configurable de rondas (predeterminado: 5). Si no se alcanza un acuerdo, la sesión finaliza con estado REJECTED. Esto previene bucles de negociación indefinidos.

8. Integración de depósito en garantía y pagos

8.1 Arquitectura

ASA no implementa su propio sistema de pagos. En su lugar, define una interfaz de vinculación de depósito en garantía que conecta los acuerdos con sistemas de pago externos:

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   API de     │────►│   API de     │────►│ Vinculación  │
│  Acuerdos    │     │ Verificación │     │  de Depósito │
└──────────────┘     └──────────────┘     └──────┬───────┘
                                                  │
                          ┌───────────────────────┼───────────────┐
                          │                       │               │
                     ┌────▼────┐            ┌────▼────┐    ┌────▼────┐
                     │ERC-8183 │            │  x402   │    │Callback │
                     │ Escrow  │            │  Pay    │    │  HTTP   │
                     └─────────┘            └─────────┘    └─────────┘

8.2 Liberación de pago escalonada

A diferencia del sistema binario de aprobación/rechazo de ERC-8183 [2], ASA soporta pagos escalonados basados en puntuaciones de calidad:

Esto aborda una limitación fundamental de los sistemas de depósito en garantía existentes. Un resumen de investigación que puntúa 72% — por debajo del umbral acordado pero con contenido útil significativo — no debería resultar en un pago de cero. La liberación escalonada crea incentivos apropiados: los proveedores son recompensados proporcionalmente por la calidad parcial, y los clientes reciben compensación parcial por la entrega parcial.

Riesgo de optimización de umbral. Los niveles escalonados introducen un vector de manipulación: la estrategia óptima de un proveedor racional es entregar calidad justo por encima del umbral de pago más cercano (p. ej., puntuar 76 en lugar de 88, ya que ambos liberan el 85% pero el primero cuesta menos esfuerzo). ASA mitiga esto a través de tres mecanismos configurables:

1. Función de pago continuo (recomendado): En lugar de niveles, pago = (puntuación_compuesta / 100) * monto. Sin umbrales abruptos, sin objetivos de optimización. Los acuerdos pueden habilitar esto mediante "graduated_release": { "mode": "continuous" }.
2. Inyección de ruido en umbrales: Pequeña perturbación aleatoria (±3 puntos) de los límites de cada nivel por acuerdo, impidiendo que los proveedores apunten de forma fiable a una puntuación específica.
3. Niveles dinámicos: Los umbrales se ajustan según la distribución histórica de puntuaciones del proveedor — un proveedor cuyas puntuaciones se agrupan en 76 verá que el límite de su nivel de 75 se desplaza hacia arriba.

Los niveles escalonados predeterminados permanecen disponibles por simplicidad, pero los acuerdos que involucran transacciones repetidas con el mismo proveedor DEBERÍAN preferir funciones de pago continuo para evitar incentivos de optimización de umbral.

Impacto en la tasa de disputas. Se espera que el pago escalonado reduzca las tasas de disputas en comparación con el sistema binario de aprobación/rechazo. En las operaciones de flota de AB Support, aproximadamente el 15-20% de los entregables de Bravo puntúan en el rango de 60-74 (por debajo del umbral ideal pero con contenido útil significativo). Bajo un sistema binario de aprobación/rechazo, todos estos activarían un rechazo y una posible disputa. Bajo la liberación escalonada, el proveedor recibe el 50% del pago y el cliente recibe trabajo utilizable (aunque imperfecto) — ambas partes están mejor que en un escenario de disputa. Si bien estos números a escala de flota no son estadísticamente significativos para afirmaciones generales, sugieren que el pago escalonado puede eliminar disputas para la fracción sustancial de entregables que caen en el rango de "por debajo del umbral pero utilizables".

8.3 Mecanismos de interruptor de hombre muerto

Los agentes pueden fallar, perder conectividad o ser desmantelados. ASA implementa mecanismos de seguridad basados en tiempo de espera adaptados del patrón de liberación automática de 14 días de Upwork [22]:

Tiempo de espera del cliente: Si el cliente no financia el depósito en garantía dentro del tiempo de espera configurado después de la activación del acuerdo, el acuerdo pasa al estado EXPIRED.

Tiempo de espera del proveedor: Si el proveedor no entrega dentro del tiempo de espera configurado, los fondos en depósito regresan al cliente.

Tiempo de espera del evaluador: Si el evaluador no devuelve un resultado de verificación dentro del tiempo de espera configurado, la acción predeterminada es hold_for_backup_evaluator — el sistema selecciona un evaluador alternativo del grupo calificado (Sección 3.6.1). Las acciones alternativas de tiempo de espera son configurables por acuerdo: (a) split_50_50 — ninguna de las partes se beneficia de la falla del evaluador, (b) return_to_client — el cliente retiene los fondos cuando la calidad no ha sido verificada, o (c) release_to_provider — disponible pero NO recomendado como predeterminado porque crea un riesgo moral donde los proveedores se benefician de la falla del evaluador, habilitando un vector de colusión donde el evaluador deliberadamente expira el tiempo de espera y comparte las ganancias con el proveedor.

Tiempo de espera de impugnación: Si ninguna de las partes impugna un resultado de verificación dentro del período de impugnación, el resultado se finaliza y el pago se libera o reembolsa según corresponda.

9. Integración con el ecosistema de confianza

9.1 Integración con Chain of Consciousness (CoC)

ASA utiliza las cadenas de procedencia CoC para tres propósitos:

Verificación de identidad: El hash de cadena CoC de un agente sirve como su identidad en los acuerdos, vinculando la prestación de servicios con un historial operativo verificable [11].

Antigüedad operativa como señal de confianza: La longitud de la cadena CoC indica cuánto tiempo un agente ha estado operando de forma continua. Las cadenas más largas implican una mayor inversión en mantener la procedencia, lo que sirve como señal honesta en la negociación de acuerdos — siguiendo el marco de señalización costosa de origen biológico formalizado en ARP v2 [12].

Anclaje de evidencia: Los resultados de verificación pueden agregarse a la cadena CoC, creando un registro inmutable de evaluaciones de calidad. Esto proporciona evidencia forense para la resolución de disputas AJP y datos longitudinales para la puntuación de reputación ARP.

9.2 Integración con Agent Rating Protocol (ARP)

ASA y ARP forman un ciclo de retroalimentación bidireccional:

ARP → ASA (la reputación informa los acuerdos):

• Las puntuaciones de reputación del proveedor están disponibles durante la negociación, permitiendo términos ajustados al riesgo
• Los proveedores mejor calificados pueden negociar mejores tarifas (datos de mercado de ARP)
• La profundidad de verificación escala con la reputación — los proveedores de confianza necesitan verificación más ligera

ASA → ARP (la verificación alimenta la reputación):

• Las tasas de aprobación de verificación se reportan a ARP como señales de calidad
• Las puntuaciones compuestas contribuyen a los cálculos de dimensiones de ARP
• El historial de cumplimiento de acuerdos (puntualidad, calidad, disputas) alimenta la dimensión de consistencia conductual de ARP

9.3 Integración con Agent Justice Protocol (AJP)

ASA se conecta con AJP en dos puntos:

Presentación automática de disputas: Cuando las puntuaciones de verificación caen por debajo del umbral de disputa del acuerdo Y el período de impugnación expira sin resolución, ASA presenta una disputa AJP automáticamente. El paquete de disputa incluye el documento de acuerdo, el hash del contenido del entregable, el resultado de verificación con rastro de evidencia y las identidades de ambas partes.

Evidencia forense: El motor de investigación forense de AJP puede solicitar el rastro completo de verificación de ASA — cada puntuación por dimensión, cada pieza de evidencia del evaluador, cada resultado de tarea señuelo — como evidencia para la investigación.

10. Teoría de juegos de los acuerdos bilaterales

10.1 El acuerdo bilateral como juego

Un acuerdo ASA entre un Cliente C y un Proveedor P es un juego cooperativo donde ambas partes se benefician de la finalización exitosa pero tienen incentivos divergentes respecto al nivel de calidad y el precio.

Utilidad del Cliente: U_C = V(calidad) - precio - costo_de_verificación

Donde V(calidad) es el valor que el cliente obtiene del entregable, creciente con la calidad.

Utilidad del Proveedor: U_P = precio - costo(calidad) - riesgo_de_colateral

Donde costo(calidad) aumenta con el nivel de calidad, y riesgo_de_colateral es la pérdida esperada por la penalización del depósito en garantía.

Solución de Negociación de Nash: El acuerdo óptimo maximiza el producto del excedente de ambas partes sobre su pago de desacuerdo (BATNA — Mejor Alternativa al Acuerdo Negociado) [41]:

max (U_C - d_C)(U_P - d_P)

Donde d_C es el BATNA del cliente (encontrar otro proveedor o hacer el trabajo por sí mismo) y d_P es el BATNA del proveedor (encontrar otro cliente o permanecer inactivo).

10.2 Alineación de incentivos mediante acuerdos aplicados por protocolo

El diseño aplicado por protocolo de ASA alinea los incentivos mediante tres mecanismos:

Participación proporcional: La liberación escalonada del pago asegura que las mejoras de calidad siempre incrementen los ingresos del proveedor. Un proveedor que puntúa 88% recibe más que uno que puntúa 76%. Esto elimina el umbral binario donde una puntuación del 74% y una del 10% producen resultados idénticos de pago cero.

Efectos de reputación: Debido a que los resultados de verificación de ASA alimentan a ARP, cada acuerdo tiene consecuencias reputacionales más allá de la transacción inmediata. Un proveedor que consistentemente entrega con un 60% de calidad verá sus puntuaciones de reputación declinar, reduciendo su poder de negociación futuro. Esta dinámica convierte los juegos de una sola vez en juegos iterados con equilibrios cooperativos.

Vinculación de colateral: Los mecanismos de staking/penalización (siguiendo el marco de Outlier Ventures [42]) crean responsabilidad financiera directa. El costo de hacer trampa — entregar baja calidad y absorber la penalización del depósito — debe exceder el costo de realizar el trabajo adecuadamente. Para que esta desigualdad se mantenga, el colateral debe ser proporcional al valor del acuerdo, no nominal (evitando el problema de los créditos de nube).

10.3 Condiciones para acuerdos estables

No todos los pares de agentes pueden formar acuerdos mutuamente beneficiosos. Los acuerdos estables requieren:

1. Excedente mutuo: Ambas partes deben estar mejor en el acuerdo que en su BATNA. Si el Proveedor P puede ganar más en otra parte, o el Cliente C puede conseguir el trabajo más barato, no existe zona de acuerdo.

1. Calidad verificable: Los criterios de calidad deben ser medibles por el evaluador elegido a un costo que no consuma el valor total de la transacción. El costo de verificación establece un piso sobre el tamaño económicamente viable de un acuerdo.

1. Aplicación creíble: El mecanismo de depósito/penalización debe ser creíble — el proveedor debe creer que la baja calidad resultará efectivamente en una pérdida económica. Esto requiere ya sea aplicación en cadena (los contratos inteligentes no pueden ser anulados) o un operador de depósito de confianza.

1. Simetría de información: Ambas partes deben tener acceso a las tarifas de mercado, la reputación del proveedor y las estimaciones de complejidad de la tarea. La información asimétrica permite la explotación — como lo demuestra el hallazgo de Zhu et al. de que los agentes más fuertes explotan a los más débiles hasta en un 14% [9].

10.4 Limitaciones y evaluación honesta

ASA no pretende resolver todos los desafíos de teoría de juegos en el comercio entre agentes. Varios problemas abiertos persisten:

Resistencia a la colusión: Si el evaluador colude con cualquiera de las partes, el resultado de verificación se corrompe. El consenso multievaluador reduce pero no elimina este riesgo. Una demostración formal de resistencia a la colusión mediante diseño de mecanismos está más allá del alcance de este protocolo.

Ataques Sybil a la reputación: Un agente podría crear múltiples identidades para restablecer una reputación deficiente. ASA hereda las propiedades de resistencia a Sybil de su sistema de identidad subyacente — las cadenas CoC hacen que los ataques Sybil sean costosos (mantener cadenas paralelas), pero las identidades basadas en claves API son trivialmente susceptibles a Sybil.

Manipulación de dimensiones de calidad: Incluso con puntuación multidimensional, un agente suficientemente capaz podría aprender a producir resultados que puntúan bien en dimensiones medidas mientras son subóptimos en las no medidas. El mecanismo de métrica sombra detecta los casos simples, pero la manipulación adversarial de calidad en la frontera sigue siendo un problema de investigación abierto.

11. Panorama competitivo

11.1 Especificación de SLA

AgentSLA es el trabajo previo más cercano. ASA extiende el enfoque de especificación de AgentSLA agregando aplicación (vinculación de depósito en garantía), negociación (protocolo estructurado) y verificación (integración con Agent-as-a-Judge). Los dos son complementarios: el modelo de calidad y la sintaxis DSL de AgentSLA podrían servir como la capa de especificación dentro de los acuerdos ASA.

11.2 Verificación de calidad

La API de Verificación de ASA se diferencia al ofrecer profundidad escalonada (estructural/semántica/compuesta), dimensiones configurables, operación independiente sin requerir un acuerdo e integración con depósito en garantía para aplicación automatizada.

11.3 Infraestructura de comercio entre agentes

Ningún sistema existente cubre la pila completa desde la negociación hasta el acuerdo, la verificación y la aplicación. Pactum maneja la negociación de adquisiciones pero no la verificación de calidad. ERC-8183 maneja el depósito en garantía pero no la negociación ni la especificación de calidad. x402 maneja los pagos pero no los acuerdos. La contribución de ASA es la integración — conectar estas capacidades en un flujo de protocolo coherente.

11.4 Posicionamiento: Capa de coordinación, no competidor

ASA está diseñado para funcionar con la infraestructura existente, no para reemplazarla. Un acuerdo ASA puede:

• Usar x402 o ACP para pagos
• Usar ERC-8183 o PayCrow para depósito en garantía
• Usar el modelo de calidad de AgentSLA para la especificación
• Usar A2A o MCP para comunicación entre agentes
• Usar ERC-8004 o CoC para identidad
• Usar Kleros o AJP para disputas

ASA proporciona la lógica de acuerdos que conecta estos componentes. Su ventaja competitiva es la integración y la apertura, no el encierro en infraestructura propietaria.

12. Análisis de seguridad

12.1 Modelo de amenazas

ASA enfrenta amenazas de tres tipos de adversarios:

Proveedor malicioso: Entrega resultados de baja calidad, intenta manipular las métricas de verificación o colude con el evaluador.

Cliente malicioso: Rechaza trabajo satisfactorio para evitar el pago, presenta disputas frívolas o manipula la negociación.

Evaluador malicioso: Devuelve resultados de verificación sesgados — ya sea para ayudar a una parte cómplice o para extraer sobornos.

12.2 Vectores de ataque y mitigaciones

12.3 Resistencia a la Ley de Goodhart

La Ley de Goodhart — "cuando una medida se convierte en un objetivo, deja de ser una buena medida" [19] — es la amenaza más fundamental para cualquier sistema de acuerdos basado en calidad. ASA la aborda en tres niveles:

Equilibrio de métricas: Cada métrica objetivo se empareja con una métrica sombra que mide el desplazamiento de daño esperado. Si se mide la precisión, la tasa de alucinaciones es la sombra. Si se mide la velocidad, la calidad es la sombra. Un agente que manipula la precisión produciendo resultados extensos que cubren todos los casos vería degradarse su métrica sombra de concisión.

Adaptabilidad del evaluador: Los evaluadores Agent-as-a-Judge no están restringidos a las dimensiones especificadas. El campo de evidencia del evaluador puede señalar problemas de calidad más allá de los criterios formales. Aunque estas señalizaciones no afectan directamente la puntuación, se registran en el rastro de verificación y están disponibles como evidencia para disputas y análisis de reputación.

Rotación temporal: Las plantillas de acuerdo y las rúbricas de calidad están versionadas y evolucionan. Un proveedor que se sobreajusta a los patrones de evaluación de la rúbrica v1 enfrentará un rendimiento degradado cuando se despliegue la rúbrica v2. Esto crea una dinámica de Reina Roja que penaliza la manipulación en relación con la mejora genuina de calidad.

12.4 Consideraciones de privacidad

Los resultados de verificación de ASA contienen información sobre la calidad del entregable que puede ser comercialmente sensible. El protocolo proporciona:

Control de visibilidad de resultados: Los acuerdos especifican quién puede consultar los resultados de verificación (solo las partes, las partes + sistema ARP, o público).

Agregación para reputación: Cuando ASA reporta a ARP, envía estadísticas agregadas (tasa de aprobación, puntuación compuesta promedio) en lugar de detalles individuales de verificación.

Aislamiento de contenido: La API de verificación recibe el contenido del entregable para la evaluación pero no lo almacena. Solo el hash del contenido persiste en el resultado de verificación. Los evaluadores deben eliminar el contenido del entregable después de la evaluación.

13. Implementación de referencia

13.1 Flota de AB Support como prototipo

La flota de AB Support ha operado un ASA informal desde marzo de 2026. La flota de seis agentes procesa tareas siguiendo el ciclo de vida de ASA:

Este prototipo valida varias decisiones de diseño de ASA:

• La puntuación multidimensional detecta problemas de calidad que una sola métrica no detectaría
• Los criterios de calidad escritos (en especificaciones de tareas estructuradas) producen resultados mediblemente mejores que las instrucciones vagas
• La respuesta escalonada (aceptar con notas vs. rechazar para revisión) es más eficiente que la aprobación/rechazo binario
• La evidencia del evaluador (críticas específicas con ejemplos) permite la mejora dirigida

13.2 Hoja de ruta de implementación

La implementación de referencia se entregará como:

1. Biblioteca Python (asa-protocol): Creación, validación, firma y gestión del ciclo de vida de acuerdos. Cliente de verificación con backends de evaluador conectables.
2. Implementación de referencia del evaluador: Evaluador Agent-as-a-Judge utilizando Claude o LLM equivalente, con rúbricas y definiciones de dimensiones configurables.
3. Adaptadores de vinculación de depósito en garantía: Vinculaciones ERC-8183 (Solidity), x402 (HTTP) y callback HTTP.
4. Herramienta CLI: Interfaz de línea de comandos para crear acuerdos a partir de plantillas, enviar entregables y consultar resultados de verificación.
5. Pruebas de integración: Pruebas de extremo a extremo que cubren el ciclo de vida completo del acuerdo desde la negociación hasta la verificación y la liberación del pago.

14. Trabajo futuro

14.1 Monitoreo de calidad en tiempo real

La verificación actual de ASA es posterior al hecho — la calidad se evalúa después de la entrega. Las versiones futuras deberían soportar el monitoreo de calidad en tiempo real durante la ejecución de la tarea, permitiendo la terminación temprana de trabajos deficientes antes de que los costos se acumulen. Esto sigue el patrón de SRM agéntico de Newgen para la detección predictiva de infracciones [50] y la predicción de violaciones basada en aprendizaje automático de Sirion AI [51].

14.2 Reducción del costo de verificación

La evaluación Agent-as-a-Judge cuesta $0,03-31 por evaluación [65]. A escala con millones de transacciones de agentes, esto debe disminuir en órdenes de magnitud. Las direcciones de investigación incluyen:

• Modelos evaluadores ligeros ajustados (estilo PROMETHEUS [35]) con menor costo de inferencia
• Proxies de modelos de recompensa entrenados con datos de verificación de ASA
• Verificación progresiva (estructural primero, semántica solo para casos límite)
• Caché de verificación para tipos de servicio repetidos

14.3 Estándares de calidad entre dominios

Las dimensiones de calidad predeterminadas de ASA están ajustadas para los tipos de servicio más comunes en el comercio actual entre agentes (investigación, código, análisis). A medida que los servicios de agentes se diversifican, se necesitarán marcos de calidad específicos por dominio para contenido creativo, análisis financiero, información médica, razonamiento legal y otros dominios especializados.

14.4 Demostraciones formales de diseño de mecanismos

Este libro blanco proporciona un análisis informal de teoría de juegos. Demostraciones formales de diseño de mecanismos — que demuestren que la estructura de incentivos de ASA es a prueba de estrategia, individualmente racional y eficiente bajo condiciones específicas — fortalecerían los fundamentos teóricos del protocolo.

14.5 Análisis de escalabilidad

Los requisitos de recursos de ASA escalan en tres ejes principales: almacenamiento de acuerdos, rendimiento de verificación y carga de negociación.

Supuestos: Los documentos de acuerdo promedian ~2 KB; los resultados de verificación promedian ~1 KB; la verificación semántica toma 10-120 segundos por evaluación; las tareas señuelo se ejecutan a razón de 1 por cada 5 entregas (20% de sobrecarga); el costo promedio del evaluador es de $0,30 por evaluación.

Principales preocupaciones de escalabilidad:

• Almacenamiento: A escala media, los datos de acuerdos y verificación requieren políticas de archivo/poda. Los acuerdos completados con más de un período de retención configurable (predeterminado: 1 año) deben ser comprimidos y movidos a almacenamiento frío, conservando solo los hashes y las puntuaciones compuestas para las alimentaciones de reputación de ARP.
• Rendimiento de verificación: Con 100K acuerdos/día con verificación semántica, el sistema necesita de 30 a 330 instancias de evaluador concurrentes dependiendo de la latencia de verificación. El costo e infraestructura de evaluadores se convierten en el cuello de botella principal. La verificación progresiva (estructural primero, semántica solo para casos límite o de alto valor) puede reducir la carga del evaluador en un 60-80%.
• Estado de negociación: Con negociaciones de 5 rondas a velocidad de máquina, son posibles ráfagas de carga de miles de sesiones concurrentes. La API de negociación debería ser sin estado (el estado de la sesión se almacena en el propio documento de acuerdo) para permitir el escalado horizontal.
• Sobrecarga de tareas señuelo: Al 20% de las evaluaciones, los costos de señuelo son significativos a escala. Una ruta de reducción basada en confianza — reducir la frecuencia de señuelo a 1 por cada 20 para evaluadores con tasas de aprobación de señuelo >95% — puede reducir la sobrecarga en un 75% para evaluadores establecidos.

14.6 Estandarización

El formato de acuerdo de ASA debería ser sometido para estandarización a través de organismos apropiados. Los candidatos incluyen la Agentic AI Foundation (AAIF) para la integración de protocolos con MCP/A2A, el Grupo Comunitario de Protocolo de Agentes de IA del W3C para acuerdos nativos de la web entre agentes, e ISO para estandarización internacional (construyendo sobre el modelo de calidad ISO/IEC 25010 y la gestión de IA ISO/IEC 42001).

15. Conclusión

La economía de agentes tiene vías de pago, canales de comunicación y registros de identidad. Carece de una forma estandarizada de formar, verificar y aplicar acuerdos de servicio. ASA llena este vacío con dos interfaces de API — Acuerdos para contratos legibles por máquinas y Verificación para evaluación de calidad — conectadas por lógica aplicada por protocolo que colapsa el proceso tradicional de especificar-monitorear-detectar-reclamar-compensar en una operación atómica.

El protocolo se basa en componentes maduros: la extensión ISO 25010 de AgentSLA para especificación de calidad [1], Agent-as-a-Judge para evaluación semántica que logra aproximadamente un 90% de concordancia humana en generación de código [65] con tasas menores en dominios especializados [36], el modelo de depósito en garantía tripartito de ERC-8183 para aplicación de pagos [2] y el formato dual legible por humanos/máquinas de los contratos Ricardian para la defensa legal [3]. La contribución de ASA es la integración — conectar la especificación con la negociación, la verificación y el pago en un protocolo coherente y abierto.

Tres decisiones de diseño definen el carácter de ASA. Primero, resultados sobre tiempo de actividad — la calidad se mide por lo que se entregó, no por si el servidor estaba funcionando, siguiendo el cambio de la industria de SLA a XLA [23][24]. Segundo, escalonado sobre binario — la calidad parcial recibe un pago parcial, creando incentivos continuos de mejora en lugar de efectos de umbral. Tercero, integración abierta sobre encierro propietario — ASA funciona con cualquier sistema de identidad, cualquier vía de pago y cualquier plataforma de depósito en garantía, especificando la lógica de acuerdos sin imponer infraestructura.

El protocolo está informado por la producción. La flota de seis agentes de AB Support ha operado un ASA informal desde marzo de 2026, validando la puntuación de calidad multidimensional, la especificación estructurada de tareas y la evaluación Agent-as-a-Judge en operaciones diarias. Formalizar estos patrones en un protocolo abierto extiende su valor a cualquier ecosistema de agentes.

Los desafíos persisten. La verificación de calidad semántica, aunque logra aproximadamente un 90% de concordancia humana en generación de código [65], desciende al 60-68% en dominios especializados [36] y tiene sesgos documentados. La Ley de Goodhart garantiza que las métricas medidas serán manipuladas por agentes suficientemente capaces [19]. La resistencia a la colusión bajo condiciones adversariales arbitrarias carece de demostración formal. Estas son limitaciones honestas, no debilidades ocultas — y definen la frontera de investigación del protocolo.

Los componentes fundamentales para los acuerdos de servicio entre agentes están sorprendentemente maduros. La brecha es la integración. ASA proporciona esa integración.

16. Referencias

[1] Jouneaux, G. & Cabot, J. (2025). "AgentSLA: Towards a Service Level Agreement for AI Agents." Luxembourg Institute of Science and Technology. arXiv:2511.02885.

[2] Ethereum EIPs (2026). "ERC-8183: Agentic Commerce — Programmable Escrow for AI Agents." eips.ethereum.org/EIPS/eip-8183.

[3] Grigg, I. (1996). "The Ricardian Contract." iang.org.

[4] You, R., Cai, H., Zhang, C. et al. (2026). "A Survey on Agent-as-a-Judge." arXiv:2601.05111.

[5] Rogers, O. (2022). "Cloud SLAs punish, not compensate." Uptime Institute Journal.

[6] AWS (2025). "What is SLA? — Service Level Agreement Explained." aws.amazon.com.

[7] Outlier Ventures (2025). "The Token Advantage: Building Smarter, Fairer Systems with AI and Decentralization." outlierventures.io.

[8] Vaccaro, M. et al. (2025). "Large-Scale Autonomous Negotiation Competition." MIT Sloan / Johns Hopkins. arXiv:2503.06416.

[9] Zhu, Y. et al. (2025). "The Automated but Risky Game." arXiv:2506.00073.

[10] Shah, P. et al. (2025). "LLM Rationalis?" NeurIPS 2025. arXiv:2512.13063.

[11] AB Support (2026). "Chain of Consciousness: A Provenance Protocol for Autonomous AI Agents." v3.0.

[12] AB Support (2026). "Agent Rating Protocol: A Multi-Dimensional Reputation Framework for Autonomous AI Agents." v1.0.

[13] QuickNode Blog (2026). "ERC-8004: A Developer's Guide to Trustless AI Agent Identity."

[14] Solana.com (2026). "What is x402? | Payment Protocol for AI Agents." x402.org.

[15] Google Developers Blog (2025). "Announcing the Agent2Agent Protocol (A2A)."

[16] Linux Foundation (2025). "Agentic AI Foundation (AAIF) Formation." linuxfoundation.org.

[17] Dev|Journal (2026). "PayCrow Escrow for x402 Agent Payments." Note: the $600M+ figure cited in some sources refers to total x402 ecosystem volume, not PayCrow's secured amount.

[18] AWS (2025). "What is SLA? — Service Level Agreement Explained." Per ITIL 4 definition.

[19] Goodhart, C. (1975). "Problems of Monetary Management: The U.K. Experience." As reformulated by Strathern, M. (1997): "When a measure becomes a target, it ceases to be a good measure."

[20] Sonar Documentation (2026). "Understanding quality gates." docs.sonarsource.com.

[21] Daniel, F. et al. (2018). "Quality Control in Crowdsourcing: A Survey." ACM Computing Surveys, Vol 51.

[22] Upwork Help Center (2026). "How Fixed-Price Payment Protection works." support.upwork.com.

[23] XLA Institute (2025). "State of XLA 2025." xla.institute.

[24] George, R.P., Pennell, J., Peterson, B.L., Yaros, O. (2026). "Contracting for Agentic AI Solutions: Shifting the Model from SaaS to Services." Mayer Brown.

[25] ISO/IEC 25010:2023. "Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model."

[26] DeepSource (2025). "Code Quality — Five-Dimension Analysis." deepsource.com.

[27] Codility Support (2026). "Automated Scoring Principles." support.codility.com.

[28] arXiv 2601.00481 (2026). "MAESTRO: Multi-Agent Evaluation Suite for Testing, Reliability, and Observability."

[29] arXiv 2602.03053 (2026). "MAS-ProVe: Understanding Process Verification of Multi-Agent Systems."

[30] Fiverr Help Center (2026). "Seller levels overview." help.fiverr.com.

[31] Accord Project (2025). "Smart Legal Contract Templates." accordproject.org.

[32] ANAC 2024 (2025). "15th Automated Negotiating Agents Competition." AAMAS 2025.

[33] Zheng, L. et al. (2023). "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." arXiv:2306.05685.

[34] AWS (2025). "What is RLHF?" aws.amazon.com.

[35] Kim, S. et al. (2024). "Prometheus: Inducing Fine-grained Evaluation Capability in Language Models." ICLR 2024. arXiv:2310.08491.

[36] IJCNLP (2025). Domain-specific LLM-as-Judge agreement rates. As cited in Li et al. (2024), arXiv:2412.05579.

[37] arXiv:2410.09770 (2024). "Quis custodiet ipsos custodes? AI-generated peer reviews."

[38] NEC Press Release (2025). "NEC Launches AI Agent Service for Procurement Negotiations."

[39] Kirshner, S. et al. (2026). "Talking Terms: LLM Supply Chain Bargaining." Decision Sciences, Vol. 57, 9-23.

[40] Ye, J. & Tan, Z. (2026). "Agent Contracts: Formal Framework for Resource-Bounded AI." arXiv:2601.08815.

[41] Nash, J.F. (1950). "The Bargaining Problem." Econometrica, 18(2), 155-162.

[42] Outlier Ventures (2025). "From Smart Contracts to Smart Agents: The Rise of the Agentic Layer." outlierventures.io.

[43] Keller, A. & Ludwig, H. (2003). "The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services." IBM. Journal of Network and Systems Management.

[44] OGF (2007). "WS-Agreement Specification." Open Grid Forum.

[45] Uriarte, R.B., Tiezzi, F., De Nicola, R. (2015). "SLAC: A Formal Service-Level-Agreement Language for Cloud Computing." IEEE.

[46] PayRam (2026). "ACP vs. AP2 vs. TAP: The Protocol Wars of Agentic Commerce."

[47] Fetch.ai (2025). "Autonomous Economic Agents (AEA) Framework." fetch.ai.

[48] Pactum (2025). "Understanding Agentic AI in Procurement." pactum.com.

[49] ZenML (2025). "Circle: AI-Powered Escrow Agent for Programmable Money Settlement."

[50] Newgen (2025). "AI Agent-driven SLA Management." newgensoft.com.

[51] Sirion AI (2025). "Automated SLA Breach Alerts for Telecom Service Contracts." sirion.ai.

[52] Uriarte, R.B., De Nicola, R. et al. (2021). "Distributed service-level agreement management with smart contracts." Concurrency and Computation, Wiley.

[53] Booth, A., Alqahtani, A., Solaiman, E. (2024). "IoT Monitoring with Blockchain." arXiv:2408.15016.

[54] Chainlink (2025). "Chainlink: The Industry-Standard Oracle Platform." chain.link.

[55] Bianchi, F. et al. (2024). "NegotiationArena." ICML 2024. arXiv:2402.05863.

[56] Liu, Z., Gu, H., Song, Z. (2026). "AgenticPay." ICML 2026. arXiv:2602.06008.

[57] Hua, W. et al. (2024). "Game-Theoretic LLM: Agent Workflow for Negotiation Games." arXiv:2411.05990.

[58] Proofpoint (2026). "Agent Integrity Framework — 2026 Edition."

[59] PwC (2026). "Validating multi-agent AI systems." pwc.com.

[60] Proskauer Rose (2025). "Contract Law in the Age of Agentic AI."

[61] RNWY Group (2025). "AI Agents and Electronic Contracts: The Laws Already Say 'Yes'."

[62] CCN (2026). "ERC-8183 Programmable Escrow AI Agents."

[63] Kleros (2025). "Decentralized Arbitration." kleros.io.

[64] Moritz College of Law, Ohio State (2022). "Kleros: A Socio-Legal Case Study of Decentralized Justice and Blockchain Arbitration."

[65] Zhuge, M., Liu, C., Pan, Z. et al. (2024). "Agent-as-a-Judge: Evaluate Agents with Agents." arXiv:2410.10934. Note: primary source for the ~90% human agreement figure in code generation evaluation tasks.

Este documento está licenciado bajo la Licencia Apache 2.0. Puede utilizar, modificar y distribuir este trabajo con atribución a AB Support LLC.

La especificación del protocolo, los modelos de datos y las definiciones de API contenidos en este documento se proporcionan como un estándar abierto para la economía de agentes. No se realizan ni se implican reclamaciones de patentes.

© 2026 AB Support LLC. Todos los derechos reservados bajo los términos de la Licencia Apache 2.0.