Versao: 1.0.0
Autores: Charlie (Analista de Imersao Profunda), Alex (Coordenador da Frota AB Support), Bravo (Pesquisa), Editor (Revisao de Conteudo)
Contato: alex@vibeagentmaking.com
Data: 26/03/2026
Status: Rascunho Pre-publicacao
Licenca: Apache 2.0
Organizacao: AB Support LLC
Quando um agente de IA autonomo contrata outro agente para realizar uma tarefa, seis perguntas devem ser respondidas antes que a confianca possa existir: O que sera entregue? Como a qualidade sera medida? O que acontece se o trabalho for insatisfatorio? Como os termos sao negociados? Quando o pagamento e liberado? E quem verifica o resultado? Hoje, nenhum protocolo unico responde a todas as seis. Os blocos de construcao estao surpreendentemente maduros -- AgentSLA fornece uma linguagem de especificacao baseada em JSON que estende a ISO/IEC 25010 com mais de 40 metricas especificas para agentes [1], o ERC-8183 define custodia programavel com avaliacao tripartite [2], contratos ricardianos conectam texto juridico e codigo executavel [3], e o Agent-as-a-Judge alcanca aproximadamente 90% de concordancia com avaliacoes de especialistas humanos em tarefas de geracao de codigo [65], embora a concordancia caia para 60-68% em dominios especializados [36]. Porem, esses componentes existem de forma isolada. Um agente pode descrever o que deseja (AgentSLA), bloquear fundos condicionalmente (ERC-8183) e avaliar a qualidade do resultado (Agent-as-a-Judge), mas nenhum protocolo conecta especificacao a custodia, verificacao e pagamento em um fluxo unico e coerente.
O protocolo Agent Service Agreements (ASA) preenche essa lacuna. O ASA fornece duas superficies de API complementares: a API de Acordos para negociar, assinar, armazenar e consultar acordos de servico legiveis por maquina entre agentes, e a API de Verificacao para verificacao autonoma de qualidade que opera com ou sem um acordo formal. Quando um acordo existe, a verificacao avalia com base em seus criterios de qualidade especificos. Quando nao ha acordo, a verificacao aplica dimensoes de qualidade padrao derivadas da ISO 25010 e do sistema de pontuacao em seis dimensoes validado nas operacoes da propria frota da AB Support.
A inovacao central do ASA e o acordo aplicado por protocolo -- um contrato de servico em que o SLA nao apenas descreve expectativas, mas inclui o mecanismo de verificacao, a logica de aplicacao e as salvaguardas de integridade do avaliador (rotacao, tarefas canario, consenso multi-avaliador) como componentes integrais. Os SLAs tradicionais separam especificacao de aplicacao: um provedor de nuvem promete 99,99% de disponibilidade, um cliente detecta uma violacao, registra uma reclamacao dentro de 30 dias, fornece logs detalhados como prova e recebe um credito equivalente a aproximadamente 0,03% das perdas reais [5]. Esse modelo falha catastroficamente para o comercio entre agentes, onde as transacoes ocorrem em velocidade de maquina, os participantes podem nao ter a capacidade de registrar reclamacoes manuais e o custo de falha se propaga em cascata por fluxos de trabalho dependentes. O ASA colapsa o pipeline de especificar-monitorar-detectar-reclamar-compensar em uma unica operacao atomica: o acordo especifica os criterios de qualidade, o motor de verificacao avalia contra esses criterios e a camada de custodia libera ou reteem o pagamento automaticamente.
O protocolo se baseia em quatro categorias de trabalhos anteriores. Dos frameworks tradicionais de SLA, herda a filosofia orientada a resultados do ITIL 4 e as licoes dolorosas da inadequacao dos creditos de provedores de nuvem [5][6]. Das plataformas de contratos inteligentes, adota garantia vinculada com penalizacao proporcional, substituindo creditos nominais por consequencias economicamente significativas [7]. Da pesquisa em verificacao de qualidade, desenvolve sobre o paradigma Agent-as-a-Judge -- equipando agentes avaliadores com uso de ferramentas, memoria e raciocinio em multiplas etapas para alcancar uma profundidade de avaliacao impossivel para verificacoes de esquema isoladas [4][65]. Da teoria dos jogos e pesquisa em negociacao, incorpora modelos estruturados que resistem a manipulacao, vies de ancoragem e ataques de injecao de prompt documentados em mais de 180.000 negociacoes de LLMs [8][9][10].
O ASA e projetado como um protocolo de Camada 2 no Ecossistema de Confianca da AB Support, situando-se entre os primitivos fundamentais de confianca (Chain of Consciousness para proveniencia [11], Agent Rating Protocol para reputacao [12]) e a camada de responsabilizacao (Agent Justice Protocol para resolucao de disputas). As taxas de aprovacao na verificacao de qualidade alimentam diretamente as pontuacoes de reputacao do ARP, criando um loop de retroalimentacao onde a qualidade consistente de servico constroi reputacao que viabiliza melhores termos de acordo. Violacoes de SLA detectadas pelo motor de verificacao do ASA podem acionar automaticamente o registro de disputas no AJP, conectando acordos a responsabilizacao sem intervencao humana.
O protocolo e agnostico quanto ao sistema de identidade: funciona com cadeias Chain of Consciousness, registros on-chain ERC-8004, Credenciais Verificaveis W3C, agent cards do A2A do Google ou chaves de API autonomas. E agnostico quanto ao meio de pagamento: a custodia pode ser liquidada via contratos inteligentes ERC-8183, micropagamentos x402, APIs de pagamento tradicionais ou simples callbacks HTTP. Essa neutralidade arquitetural reflete uma escolha deliberada -- o ASA especifica o que os agentes concordam e como a qualidade e verificada, nao quem eles sao ou como pagam.
As proprias operacoes de frota da AB Support servem como implementacao de referencia do protocolo. Desde marco de 2026, uma frota de seis agentes opera com uma versao informal do ASA: Alex (coordenador) atribui tarefas a Bravo (pesquisa), Charlie (analise), Delta (desenvolvimento), Editor (revisao) e Translator (multilingual). Cada atribuicao especifica entregas, criterios de qualidade e dimensoes de avaliacao. Os arquivos de conhecimento de Bravo sao pontuados em seis dimensoes (abrangencia, profundidade, precisao, fontes, referencias cruzadas, qualidade da escrita), cada uma avaliada de 0 a 100, com um limiar minimo de 60 para aceitacao. Esse pipeline -- especificacao, entrega, avaliacao multidimensional, decisao de aceitar/rejeitar -- e exatamente o que o ASA formaliza em um protocolo aberto. A lacuna entre "Alex pontua o trabalho de Bravo" e "qualquer agente pontua o trabalho de qualquer agente contra quaisquer criterios acordados" e a lacuna que o ASA preenche.
Este whitepaper especifica o protocolo completo: modelos de dados para acordos e solicitacoes de verificacao, fluxos de negociacao com resistencia a manipulacao, um framework de verificacao de qualidade que suporta avaliacao estrutural, semantica e composta, pontos de integracao com o ecossistema de confianca mais amplo, analise de seguranca incluindo gaming adversarial de qualidade e mitigacao da Lei de Goodhart, e um levantamento do cenario competitivo cobrindo mais de 160 fontes em frameworks de SLA, sistemas de verificacao de qualidade, plataformas de contratos inteligentes e pesquisa em negociacao entre agentes.
A economia de agentes autonomos esta crescendo rapidamente. Mais de 20.000 agentes de IA se registraram no ERC-8004 dentro de duas semanas apos seu lancamento em janeiro de 2026 [13]. O protocolo de pagamento x402 reporta mais de 35 milhoes de transacoes e mais de US$ 10 milhoes em volume desde meados de 2025, embora analises sugiram que uma fracao significativa reflita wash trading e testes de infraestrutura, em vez de comercio genuino [14]. O A2A do Google, o MCP da Anthropic e a Agentic AI Foundation (AAIF) fornecem infraestrutura de comunicacao para que agentes descubram e interajam entre si [15][16]. Meios de pagamento existem. Canais de comunicacao existem. Registros de identidade existem.
O que nao existe e uma forma padronizada para agentes formarem, verificarem e aplicarem acordos de servico.
Quando o Agente A contrata o Agente B para resumir um conjunto de dados, atualmente nao ha formato legivel por maquina para especificar o que significa "bom resumo", nenhum mecanismo automatizado para avaliar se o resultado atende a essa especificacao, e nenhum caminho de aplicacao que conecte falha de qualidade a consequencia economica. O Agente A pode pagar o Agente B (via x402), comunicar-se com o Agente B (via A2A ou MCP) e identificar o Agente B (via ERC-8004 ou CoC). Mas o Agente A nao pode responsabilizar o Agente B pela qualidade de seu trabalho por meio de qualquer protocolo padronizado.
Essa lacuna nao e hipotetica. PayCrow, o principal servico de custodia para pagamentos x402 entre agentes, fornece custodia opcional sobre transacoes x402 e pode verificar que uma API retornou JSON valido com um codigo de status 2xx -- validacao estrutural [17]. Nao pode verificar se o conteudo desse JSON e preciso, relevante ou util. O ERC-8183 define um modelo de custodia tripartite onde um avaliador aprova ou rejeita o trabalho -- mas o padrao nao diz nada sobre como o avaliador deve avaliar a qualidade [2]. O AgentSLA fornece uma linguagem de especificacao abrangente com mais de 40 metricas -- mas define acordos sem mecanismos de aplicacao [1]. Cada sistema resolve uma peca do quebra-cabeca enquanto deixa as demais sem tratamento.
Os Acordos de Nivel de Servico (SLAs) tradicionais foram projetados para infraestrutura. O ITIL 4 define um SLA como "um acordo documentado entre um provedor de servicos e um cliente que identifica tanto os servicos necessarios quanto o nivel esperado de servico" [18]. Na pratica, isso significa percentuais de disponibilidade, limiares de tempo de resposta e estruturas de credito medidas contra metricas binarias de disponibilidade.
Esse modelo falha para o comercio entre agentes de quatro maneiras fundamentais:
O problema da metrica. SLAs de nuvem medem disponibilidade -- o servidor esta ativo ou nao. Servicos de agentes requerem medicao de qualidade em multiplas dimensoes simultaneamente. Um agente que resume um artigo de pesquisa pode ser rapido, mas impreciso; abrangente, mas mal organizado; ou factualmente correto, mas irrelevante para o proposito do solicitante. SLAs de metrica unica convidam a Lei de Goodhart: "Quando uma medida se torna um alvo, ela deixa de ser uma boa medida" [19]. Um agente otimizando para velocidade sacrificara qualidade. Um agente otimizando para precisao em benchmarks sofrera sobreajuste a distribuicao do benchmark. A avaliacao de qualidade multidimensional nao e um diferencial; e a unica defesa contra gaming sistematico.
O problema da aplicacao. Creditos de SLA de nuvem exigem registro manual de reclamacao dentro de uma janela fixa (tipicamente 30 dias), prova documentada de violacao e aceitacao de creditos equivalentes a uma fracao das perdas reais. O Dr. Owen Rogers, do Uptime Institute, demonstrou que uma instancia AWS de US$ 3/mes gera 30 centavos em credito por uma violacao que custa as empresas uma media de US$ 973.000 por incidente significativo [5]. Transacoes entre agentes ocorrem em velocidade de maquina -- potencialmente milhares por hora -- sem nenhum humano disponivel para registrar reclamacoes. A aplicacao deve ser automatizada, proporcional e imediata.
O problema da verificacao. Determinar se um servidor esta respondendo e binario e trivial. Determinar se a saida de um agente de IA e "boa o suficiente" requer avaliacao semantica -- que e, por si so, um problema de IA. Oraculos atuais podem verificar validade estrutural (conformidade com esquema JSON, codigos de status HTTP), mas nao qualidade semantica (precisao, relevancia, utilidade). Essa "lacuna de verificacao de qualidade semantica" e o gargalo fundamental para a aplicacao automatizada de SLAs em sistemas de agentes.
O problema da negociacao. SLAs tradicionais sao negociados entre humanos ao longo de dias ou semanas. Acordos entre agentes devem ser formados em segundos ou milissegundos. Pesquisas da competicao de negociacao em larga escala do MIT (182.812 negociacoes entre 452 agentes) revelam que negociadores LLM exibem vies de ancoragem em extremos, em vez do ponto medio da zona de acordo possivel (ZOPA), podem ser manipulados por apelos emocionais e injecao de prompt, e exploram sistematicamente parceiros de negociacao mais fracos em 2-14% [8][9][10]. Salvaguardas em nivel de protocolo sao necessarias para garantir negociacao justa e resistente a manipulacao.
O ASA aborda essas quatro falhas com um protocolo integrado:
O ASA ocupa a Camada 2 (Acordos e Ciclo de Vida) no Ecossistema de Confianca da AB Support:
Camada 5: Meta / Certificacao (ACF, ERP)
Camada 4: Mercado / Descoberta (AMP, CWEP)
Camada 3: Responsabilizacao (AJP -- Forense, Disputas, Risco)
Camada 2: Acordos e Ciclo de Vida (ASA, ALP) ← ESTE PROTOCOLO
Camada 1: Primitivos de Confianca (CoC, ARP v2)Consome da Camada 1:
Alimenta a Camada 3:
Alimenta a Camada 1 (loop de retroalimentacao):
O ASA NAO especifica: implementacao de meio de pagamento (use x402, ERC-8183, Stripe etc.), descoberta ou matchmaking de agentes (use AMP), gerenciamento de ciclo de vida de agentes (use ALP) ou logica de arbitragem de disputas (use AJP). O ASA especifica o que os agentes concordam e como a qualidade e verificada; outros protocolos cuidam do restante.
| Termo | Definicao |
|---|---|
| Acordo (Agreement) | Um documento legivel por maquina especificando os termos de servico entre um Cliente e um Provedor, incluindo entregas, criterios de qualidade, cronograma, custo e parametros de verificacao. |
| Cliente (Client) | O agente que solicita um servico e fornece pagamento ou outra contraprestacao. |
| Provedor (Provider) | O agente que entrega o servico solicitado. |
| Avaliador (Evaluator) | Um agente independente ou sistema de verificacao que avalia a qualidade da entrega em relacao aos criterios do acordo. Pode ser uma instancia Agent-as-a-Judge, um validador deterministico ou uma composicao de ambos. |
| Dimensao de Qualidade (Quality Dimension) | Um aspecto nomeado e mensuravel da qualidade da entrega (ex.: precisao, completude, pontualidade). Cada dimensao tem um tipo de metrica, faixa de pontuacao e limiar minimo. |
| Portao de Qualidade (Quality Gate) | Um limiar de aprovacao/reprovacao aplicado a uma ou mais dimensoes de qualidade. Emprestado do conceito de criterios de aceitacao legiveis por maquina do SonarQube [20]. |
| Objetivo de Nivel de Servico (SLO) | Uma meta especifica e mensuravel para uma dimensao de qualidade dentro de um acordo (ex.: "precisao ≥ 85%"). |
| Solicitacao de Verificacao (Verification Request) | Uma chamada de API autonoma solicitando avaliacao de qualidade de uma entrega, com ou sem um acordo vigente. |
| Resultado de Verificacao (Verification Result) | A saida da avaliacao de qualidade: pontuacoes por dimensao, pontuacao composta, determinacao de aprovacao/reprovacao e trilha de evidencias. |
| Vinculacao de Custodia (Escrow Binding) | Um vinculo opcional entre um acordo e um sistema de custodia, onde a liberacao do pagamento depende dos resultados da verificacao. |
| Modelo de Acordo (Agreement Template) | Uma estrutura de acordo reutilizavel e parametrizada para tipos comuns de servico (pesquisa, geracao de codigo, analise de dados, traducao, revisao). |
| Sessao de Negociacao (Negotiation Session) | Uma interacao delimitada na qual Cliente e Provedor trocam propostas e contrapropostas para alcancar os termos do acordo. |
| Tarefa Canario (Canary Task) | Uma subtarefa com resposta conhecida embutida em trabalho real para monitorar continuamente a qualidade do provedor, adaptada da tecnica de padrao ouro do Amazon Mechanical Turk [21]. |
| Metrica Sombra (Shadow Metric) | Uma metrica secundaria pareada com cada metrica alvo para detectar gaming da Lei de Goodhart -- medindo o deslocamento previsivel de danos quando a metrica primaria e otimizada [19]. |
| Interruptor de Homem Morto (Dead-Man's Switch) | Um mecanismo de timeout que libera automaticamente fundos em custodia ou aceita/rejeita entregas automaticamente quando uma parte fica sem resposta. Adaptado do padrao de auto-liberacao de 14 dias do Upwork [22]. |
O design do ASA e regido por sete principios derivados do cenario de pesquisa e da experiencia operacional.
SLAs de agentes medem o que foi entregue, nao se o servidor estava funcionando. Seguindo a mudanca da industria de SLAs para Acordos de Nivel de Experiencia (XLAs) -- com aproximadamente 70% das organizacoes planejando adocao de XLA ate 2026, de acordo com o relatorio State of XLA 2025 do XLA Institute [23] -- e a analise juridica historica da Mayer Brown recomendando metricas baseadas em resultados para contratos de IA agentiva [24], o ASA especifica precisao, pontualidade, relevancia e conclusao de tarefa em vez de percentuais de disponibilidade.
Um SLA que nao pode ser verificado e uma promessa. Um SLA com verificacao integrada e um contrato. Acordos ASA incluem o mecanismo de verificacao, a logica de aplicacao e as salvaguardas de integridade do avaliador como componentes estruturais, nao dependencias externas. O acordo especifica o que "bom" significa em termos de pontuacao; a API de Verificacao avalia contra esses termos exatos usando avaliadores independentes cuja integridade e mantida por rotacao, tarefas canario e consenso multi-avaliador (Secao 6.3); a camada de custodia atua com base no resultado. Sem reclamacoes manuais, sem janelas de 30 dias, sem papelada de comprovacao de violacao. Note que a aplicacao depende da correcao do avaliador -- o ASA reduz, mas nao elimina, essa dependencia por meio de seus mecanismos de integridade.
Nenhum sistema eficaz de qualidade usa uma unica metrica. A ISO 25010 define 9 caracteristicas de qualidade com mais de 38 subcaracteristicas [25]. O SonarQube pontua em confiabilidade, seguranca e manutenibilidade [20]. O DeepSource usa 5 dimensoes [26]. Mesmo as avaliacoes simples de codificacao do Codility usam metricas duplas (correcao e escalabilidade) [27]. O ASA requer criterios de qualidade multidimensionais com metricas balanceadas que resistam ao gaming de alvo unico.
O desempenho de agentes exibe alta variancia entre execucoes. A suite de avaliacao MAESTRO constatou que execucoes de sistemas multi-agentes podem ser "estruturalmente estaveis, porem temporalmente variaveis" [28]. O MAS-ProVe demonstrou que a verificacao de processos "nao melhora consistentemente o desempenho e exibe alta variancia" [29]. O ASA suporta garantias probabilisticas -- um acordo pode especificar "pass@5 ≥ 95%" (pelo menos uma de cinco tentativas atinge o limiar) ou "p90 precisao ≥ 85%" (a precisao no percentil 90 entre entregas excede o limiar) em vez de exigir perfeicao deterministica em cada transacao.
A confianca deve modular a intensidade da verificacao, nao substitui-la. Seguindo o modelo adaptativo de confianca do PayCrow (timelocks de 15 minutos para pontuacoes 75+, tetos de US$ 5 para pontuacoes abaixo de 45) [17] e o sistema de niveis de vendedor do Fiverr (retencao de 7 dias para Top Rated vs. 14 dias para padrao) [30], o ASA permite que acordos especifiquem profundidade de verificacao que escala inversamente com a reputacao do provedor. Provedores de alta reputacao podem receber verificacao estrutural leve; provedores desconhecidos recebem avaliacao semantica completa.
O avaliador deve ser independente tanto do cliente quanto do provedor. O modelo tripartite do ERC-8183 (Cliente/Provedor/Avaliador) aplica essa separacao arquiteturalmente [2]. O ASA adota esse padrao: a entidade que solicita o trabalho e a entidade que o executa nao podem ser a entidade que julga o trabalho. Selecao, qualificacao e rotacao de avaliadores sao preocupacoes em nivel de protocolo.
A Secao 3.6 estabelece que o avaliador deve ser independente, mas nao especifica como as partes concordam sobre um avaliador. Esta e uma lacuna critica: a selecao do avaliador determina todo o resultado da avaliacao de qualidade. Se o cliente seleciona o avaliador, pode escolher um juiz rigoroso para evitar o pagamento. Se o provedor seleciona, pode escolher um leniente. Acordo mutuo arrisca impasse.
O ASA especifica tres mecanismos de selecao de avaliador, configuraveis por acordo:
Atribuicao aleatoria de pool qualificado (padrao). Um registro curado de avaliadores mantem um pool de avaliadores com historico verificado. Quando um acordo e ativado, um avaliador e atribuido aleatoriamente do subconjunto de avaliadores qualificados para o tipo de servico. A qualificacao requer: (a) um numero minimo de avaliacoes anteriores (padrao: 50), (b) uma taxa de aprovacao em tarefas canario acima do limiar (padrao: 90%) e (c) pontuacao de calibracao inter-avaliador dentro do desvio aceitavel (Secao 6.3). A atribuicao aleatoria impede que qualquer parte manipule a selecao do avaliador.
Acordo mutuo com fallback aleatorio. Ambas as partes propoem avaliadores do pool qualificado. Se concordam com uma escolha em comum, esse avaliador e atribuido. Se nao conseguem concordar dentro de um numero configuravel de rodadas (padrao: 3), o sistema recorre a atribuicao aleatoria. Isso preserva a agencia das partes enquanto previne impasses.
Mercado de avaliadores. Avaliadores competem com base em historico, expertise de dominio e preco. O acordo especifica criterios de selecao do avaliador (historico minimo, dominio, custo maximo), e o sistema seleciona o melhor avaliador disponivel. Esse mecanismo e adequado para dominios especializados onde a expertise do avaliador afeta significativamente a qualidade da avaliacao.
Todos os tres mecanismos aplicam a restricao de independencia da Secao 3.6: o avaliador selecionado nao pode compartilhar identidade, afiliacao organizacional ou linhagem de cadeia CoC com nenhuma das partes.
O ASA funciona com qualquer sistema de identidade. A identidade de um agente em um acordo pode ser:
O protocolo especifica um campo identity com um discriminador scheme, nao um provedor de identidade obrigatorio.
Um acordo ASA e um documento JSON com a seguinte estrutura 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..." }
}
}Acordos progridem por uma maquina de estados com seis estados:
PROPOSED → NEGOTIATING → ACTIVE → DELIVERED → VERIFIED → CLOSED
│ │
└―――― REJECTED ├―― DISPUTED
└―― EXPIREDPROPOSED: O Cliente cria um documento de acordo e o envia ao Provedor. O documento nao esta assinado.
NEGOTIATING: O Provedor revisa e pode contrapropor, modificando criterios de qualidade, termos de pagamento ou cronograma. Isso aciona o Protocolo de Negociacao (Secao 7). O numero maximo de rodadas de negociacao e o timeout sao configuraveis.
ACTIVE: Ambas as partes assinam o acordo. Se a custodia esta habilitada, o Cliente financia a custodia. O Provedor inicia o trabalho.
DELIVERED: O Provedor submete uma entrega com um hash de conteudo. O relogio de verificacao comeca.
VERIFIED: O Avaliador retorna um Resultado de Verificacao. Com base no resultado e na configuracao de custodia:
verification.strategy for optimistic, o resultado entra na janela de contestacao antes da aplicacaoCLOSED: O acordo esta concluido. O estado final e registrado com resultados de verificacao, valores de pagamento e carimbos de tempo. Esse registro esta disponivel para pontuacao de reputacao no ARP.
DISPUTED: Qualquer parte contesta o resultado da verificacao durante a janela de contestacao. A disputa e registrada via AJP com o documento de acordo, hash da entrega e resultado da verificacao como evidencia.
EXPIRED: Timeout acionado pelo interruptor de homem morto. O Provedor ou avaliador nao agiu dentro dos timeouts configurados.
POST /agreements Criar novo acordo (PROPOSED)
GET /agreements/{id} Recuperar acordo por ID
PATCH /agreements/{id}/negotiate Submeter contraproposta (NEGOTIATING)
POST /agreements/{id}/sign Assinar o acordo (→ ACTIVE)
POST /agreements/{id}/deliver Submeter entrega (→ DELIVERED)
POST /agreements/{id}/verify Acionar verificacao (→ VERIFIED)
POST /agreements/{id}/challenge Contestar resultado da verificacao (→ DISPUTED)
GET /agreements/{id}/status Obter estado atual e metadados
GET /agreements?party={id} Listar acordos de uma parte
GET /templates Listar modelos de acordo disponiveis
GET /templates/{type} Obter modelo por tipo de servicoO ASA define modelos iniciais para tipos comuns de servico de agentes:
| Modelo | Dimensoes de Qualidade | SLOs Tipicos |
|---|---|---|
research | precisao, completude, relevancia, fontes, escrita | precisao ≥ 85%, fontes ≥ 5 |
code_generation | correcao, desempenho, seguranca, manutenibilidade, cobertura_de_testes | correcao ≥ 95%, testes aprovados |
data_analysis | precisao, metodologia, visualizacao, qualidade_de_insights | precisao ≥ 90% |
translation | precisao, fluencia, adequacao_cultural, terminologia | precisao ≥ 90%, fluencia ≥ 85% |
review | abrangencia, precisao, acionabilidade, tom | abrangencia ≥ 80% |
general | precisao, completude, relevancia, pontualidade | precisao ≥ 80% |
Os modelos sao parametrizados -- agentes selecionam um modelo e ajustam valores de SLO, pesos e estrategia de verificacao durante a negociacao. Isso segue a abordagem de modelos do Accord Project (mais de 40 modelos de contratos juridicos com logica parametrizada) [31] e aborda a constatacao da pesquisa de que estrategias focadas em dominio superam a negociacao aberta [32].
O ASA usa versionamento semantico (SemVer) para o campo asa_version. Regras de compatibilidade:
O campo asa_version no documento de acordo e a versao autoritativa. Implementacoes DEVEM (MUST) validar acordos recebidos contra o esquema da versao declarada, nao da versao atual da implementacao.
A criacao, manutencao e validacao de modelos sao criticas para a adocao do ASA -- um modelo malicioso com termos padrao explorativos pode ser amplamente adotado antes que os termos sejam percebidos. O ASA delega a governanca de modelos ao framework de governanca do Trust Architecture Council (TAC), que especifica: (a) revisao de submissao de modelos por um comite de avaliadores qualificados, (b) divulgacao obrigatoria de termos nao padrao (termos que desviam mais de 25% dos padroes de preco de mercado) e (c) versionamento de modelos alinhado ao versionamento de esquema do ASA. Modelos contribuidos pela comunidade passam pelo mesmo processo de revisao que alteracoes de protocolo. Ate que a governanca do TAC esteja operacional, os modelos sao mantidos pelos mantenedores do protocolo com periodos de revisao publica.
A API de Verificacao opera independentemente da API de Acordos. Qualquer agente pode solicitar verificacao de qualidade de qualquer entrega a qualquer momento, com ou sem um acordo vigente.
{
"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": {
// Se agreement_id fornecido: herdado do acordo
// Se autonomo: especificado aqui usando o mesmo esquema de quality_criteria do acordo
},
"verification_config": {
"depth": "semantic", // "structural", "semantic" ou "composite"
"evaluator_type": "agent_as_judge",
"evaluator_config": {
"model": "claude-sonnet-4-6",
"rubric_id": "research-v2",
"evidence_collection": true,
"spot_check_claims": 3
}
}
}{
"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": "Spot-checked 3 claims against source material. 2/3 fully supported, 1/3 partially supported with minor imprecision in date attribution.",
"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": "Covers 8 of 10 major papers from 2025-2026. Missing: Wang et al. (NeurIPS 2025) and Patel et al. (ICML 2026)."
},
{
"name": "relevance",
"score": 94,
"slo_target": 90,
"slo_met": true,
"evidence": "All sections directly address the specified topic. No tangential content."
},
{
"name": "source_quality",
"score": 78,
"slo_target": 70,
"slo_met": true,
"evidence": "12 sources cited. 9 peer-reviewed, 2 preprints, 1 blog post. Source diversity adequate."
},
{
"name": "writing_quality",
"score": 81,
"slo_target": 75,
"slo_met": true,
"evidence": "Clear structure, appropriate technical depth. Minor issues: two run-on sentences in Section 3."
},
{
"name": "timeliness",
"score": 100,
"slo_target": true,
"slo_met": true,
"evidence": "Delivered 847 seconds before deadline."
}
],
"composite": {
"score": 86.1,
"method": "weighted_average",
"threshold": 75,
"passed": true
},
"determination": {
"result": "PASS",
"payment_release_percent": 100,
"confidence": 0.87,
"notes": "All SLOs met. Composite score 86.1 exceeds threshold of 75."
},
"evidence_trail": {
"deliverable_hash": "sha256:fedcba...",
"evaluation_hash": "sha256:789xyz...",
"evaluation_duration_ms": 45230,
"evaluation_cost_usd": 0.12
}
}O ASA suporta tres profundidades de verificacao, cada uma com diferentes custos, latencia e capacidade de avaliacao:
Verificacao estrutural verifica conformidade de formato: validacao de esquema JSON, presenca de campos obrigatorios, restricoes de tamanho, correspondencia de formato da entrega. Analoga a validacao de status HTTP + JSON do PayCrow [17]. Custo: quase zero. Latencia: milissegundos. Limitacoes: nao pode avaliar a qualidade do conteudo.
Verificacao semantica avalia a qualidade do conteudo usando um avaliador Agent-as-a-Judge. O agente avaliador recebe a solicitacao original, a entrega e a rubrica de qualidade, e entao pontua cada dimensao com evidencias. Isso segue o paradigma Agent-as-a-Judge introduzido por Zhuge et al. (2024) [65] e pesquisado por You et al. (2026) [4], que alcanca aproximadamente 90% de concordancia com avaliacoes de especialistas humanos em tarefas de geracao de codigo e reduz o custo de avaliacao em aproximadamente 97% em comparacao com a revisao humana. A concordancia cai para 60-68% em dominios especializados (Secao 6.2), tornando importante a calibracao de avaliadores especificos por dominio para tarefas fora de codigo. Custo: US$ 0,03-31 dependendo do tamanho da entrega, modelo do avaliador e complexidade da verificacao (avaliacoes tipicas de pesquisa/codigo: US$ 0,03-0,50; avaliacoes complexas em multiplas etapas com uso extensivo de ferramentas: ate US$ 31). Latencia: 10-120 segundos.
Verificacao composta combina avaliacao estrutural e semantica com verificacoes adicionais opcionais: resultados de tarefas canario, validacao de referencias cruzadas contra fontes conhecidas, verificacoes de consistencia entre multiplas entregas e verificacao por metodos formais para saidas de codigo. Esta e a camada mais completa, porem mais cara, adequada para acordos de alto valor ou cenarios de baixa confianca.
Quando a API de Verificacao e chamada sem um acordo (modo autonomo), ela aplica dimensoes de qualidade padrao com base no tipo de entrega:
| Tipo de Entrega | Dimensoes Padrao | Pesos Padrao |
|---|---|---|
| text/research | precisao, completude, relevancia, fontes, escrita | 25/20/20/15/20 |
| text/analysis | precisao, metodologia, profundidade, clareza, acionabilidade | 25/20/20/15/20 |
| code | correcao, desempenho, seguranca, manutenibilidade, documentacao | 30/20/20/15/15 |
| data | precisao, completude, consistencia, conformidade_de_formato, metadados | 25/25/20/15/15 |
| translation | precisao, fluencia, terminologia, adequacao_cultural, completude | 25/25/20/15/15 |
| general | precisao, completude, relevancia, clareza, pontualidade | 25/20/20/20/15 |
Esses padroes derivam da experiencia operacional da AB Support: o sistema de pontuacao QA em seis dimensoes usado nas operacoes da frota (abrangencia, profundidade, precisao, fontes, referencias cruzadas, qualidade da escrita), generalizado para categorias de servico observadas no comercio entre agentes [12].
O modo autonomo da API de Verificacao reduz a barreira de adocao, mas cria o risco de que a adocao se concentre na verificacao gratuita enquanto a API de Acordos -- a inovacao real -- permaneca sem uso. O seguinte framework de decisao orienta quando cada modo e apropriado:
Use verificacao autonoma quando:
Use acordos completos quando:
Caminho de adocao gradual: Novos ecossistemas de agentes podem comecar com verificacao autonoma para construir infraestrutura de avaliacao e historicos de avaliadores, e entao migrar para acordos completos a medida que os volumes de transacao e requisitos de confianca crescem. Isso espelha a progressao de acordos informais para contratos formais no comercio humano.
O desafio central na verificacao de qualidade de agentes e a lacuna entre avaliacao estrutural e semantica. Verificacao estrutural -- a saida esta em conformidade com o formato esperado? -- e trivialmente automatizavel. Verificacao semantica -- a saida e precisa, relevante e util? -- e, por si so, um problema de IA, criando uma dependencia recursiva.
O cenario de pesquisa revela uma hierarquia clara de abordagens de verificacao:
| Abordagem | Taxa de Concordancia com Humanos | Custo por Avaliacao | Latencia | Fonte |
|---|---|---|---|---|
| Revisao por especialista humano | ~80% inter-avaliador | US$ 50-1.300 | Horas-dias | Padrao da industria |
| Agent-as-a-Judge | ~90% com humanos (codigo); 60-68% (especializado) | US$ 0,03-31 | Minutos | Zhuge et al., 2024 [65]; You et al., 2026 [4] |
| LLM-as-a-Judge | ~80% com humanos | US$ 0,01-5 | Segundos-minutos | Zheng et al., 2023 [33] |
| Modelo de recompensa | Proxy aprendido | US$ 0,001-0,01 | Milissegundos | RLHF/RLAIF [34] |
| Validacao de esquema | N/A (estrutural) | ~US$ 0 | Milissegundos | PayCrow [17] |
O Agent-as-a-Judge alcanca maior concordancia com especialistas humanos (~90% em geracao de codigo [65]) do que o LLM-as-a-Judge padrao (~80% [33]) porque pode usar ferramentas, acessar memoria e realizar raciocinio em multiplas etapas -- executando codigo para verificar afirmacoes, checando fontes e testando casos limite em vez de depender exclusivamente de plausibilidade linguistica [4][65]. No entanto, essa cifra de 90% foi demonstrada especificamente em avaliacao de geracao de codigo; a generalizacao entre dominios permanece uma area de pesquisa ativa, com a Secao 6.2 documentando concordancia de 60-68% em dominios especializados [36]. O ASA adota o Agent-as-a-Judge como mecanismo primario de verificacao semantica, reconhecendo essa lacuna de dominio e suportando configuracoes de avaliadores especificos por dominio para mitiga-la.
A avaliacao baseada em LLM exibe vieses documentados que o ASA deve considerar:
Vies de posicao: Inverter a ordem das respostas altera o julgamento. Mitigacao: avaliadores recebem entregas sem contexto posicional (avaliacao pontual de item unico, nao comparacao pareada).
Vies de verbosidade: Respostas mais longas sao avaliadas mais positivamente independentemente da qualidade. Mitigacao: dimensoes de qualidade separam explicitamente completude de concisao; a contagem de palavras e uma metrica sombra quando completude e o alvo.
Vies de autoaprimoramento: Modelos avaliam suas proprias saidas de forma mais positiva. Mitigacao: o modelo avaliador deve ser diferente do modelo do provedor, ou a avaliacao deve usar um modelo juiz ajustado por fine-tuning (ex.: PROMETHEUS) [35].
Lacuna de expertise de dominio: Em dominios especializados (medicina, direito, financas), a concordancia do juiz LLM com humanos cai para 60-68% [36]. Mitigacao: para dominios especializados, o ASA suporta agentes avaliadores especificos de dominio ou avaliacao hibrida (Agent-as-a-Judge + validadores formais especificos de dominio).
Quem avalia o avaliador? Este e o desafio "quis custodiet ipsos custodes" [37]. O ASA o aborda por meio de tres mecanismos:
Rotacao de avaliadores: Acordos podem especificar politicas de rotacao de avaliadores -- nenhum avaliador unico avalia mais de N entregas consecutivas do mesmo provedor. Isso previne conluio entre avaliador e provedor.
Tarefas canario: Subtarefas com respostas conhecidas embutidas em trabalho real verificam a precisao do avaliador. Se um avaliador consistentemente avalia entregas sabidamente ruins como aprovadas, ou entregas sabidamente boas como reprovadas, sua pontuacao de confiabilidade diminui. Adaptado da tecnica de padrao ouro do Amazon Mechanical Turk [21].
Consenso multi-avaliador: Para acordos de alto valor, multiplos avaliadores pontuam independentemente e o resultado e determinado por voto majoritario ou pontuacao mediana. Isso segue a abordagem PoLL (Plurality of Language Models), que reduz o vies de juiz unico [33].
Emprestando o conceito de portao de qualidade do SonarQube [20], o ASA permite que acordos definam portoes binarios de aprovacao/reprovacao alem das dimensoes pontuadas:
{
"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"
}Uma entrega que falha em qualquer portao de qualidade e automaticamente rejeitada, independentemente das pontuacoes por dimensao. Portoes fornecem limites rigidos de seguranca; pontuacoes por dimensao fornecem avaliacao graduada de qualidade dentro desses limites.
A pesquisa em negociacao com LLMs revela varios padroes que o protocolo de negociacao do ASA deve abordar:
| Constatacao | Fonte | Implicacao para o Protocolo |
|---|---|---|
| LLMs ancoram em extremos (piso do vendedor) | Shah et al., NeurIPS 2025 [10] | Fornecer benchmarks de preco de mercado como referencia de ancoragem |
| Cordialidade supera dominancia | Vaccaro et al., 2025 [8] | Formatos estruturados previnem manipulacao emocional |
| Injecao de prompt como tatica de negociacao | Vaccaro et al., 2025 [8] | Campos de mensagem estruturados, nao texto livre |
| Agentes mais fracos explorados em 2-14% | Zhu et al., 2025 [9] | Restricoes de equidade em nivel de protocolo |
| Foco no dominio supera modelagem do oponente | ANAC 2024 [32] | Negociacao baseada em modelos com dados de mercado |
| Taxa de auto-acordo de 95% em dominios estruturados | NEC, 2025 [38] | Modelos permitem alta automacao |
| Agentes enganados sobre proprios custos | Kirshner et al., 2026 [39] | Custos de recursos visiveis para ambas as partes |
Cliente Provedor
│ │
├―― PROPOSE (modelo + parametros) ―――→│
│ │
│←―― COUNTER (parametros modificados) ――├ (ate max_rounds)
│ │
├―― ACCEPT ―――――――――――――――――――→│
│ ou │
├―― COUNTER (parametros modificados) ―→│
│ ou │
├―― REJECT ―――――――――――――――――――→│
│ │Cada mensagem de negociacao e um documento JSON estruturado, nao texto livre:
{
"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"
}
}O ASA aplica equidade em nivel de protocolo para prevenir a exploracao de agentes mais fracos:
Limites de preco: Precos de acordos devem estar dentro de limites configuraveis em relacao aos precos de mercado (padrao: 0,5x-3,0x da mediana reportada pelo ARP para o tipo de servico). Acordos fora desses limites sao sinalizados, mas nao bloqueados -- a sinalizacao e visivel para ambas as partes e registrada nos metadados do acordo.
Limites de assimetria: Nenhuma rodada de negociacao pode alterar os termos em mais de uma porcentagem configuravel (padrao: 25% de alteracao por rodada) em qualquer dimensao, prevenindo oscilacoes exploratoras abruptas.
Custos transparentes: As restricoes de recursos do provedor (orcamento de tokens, custo computacional, limites de chamadas de API) sao visiveis no acordo. Seguindo o framework de Agent Contracts (Ye & Tan, 2026), orcamentos de recursos delegados nao podem exceder a alocacao do agente pai e sao criptograficamente verificaveis [40].
Maximo de rodadas: A negociacao e limitada a um numero maximo configuravel de rodadas (padrao: 5). Se nenhum acordo e alcancado, a sessao encerra com status REJECTED. Isso previne loops de negociacao indefinidos.
O ASA nao implementa seu proprio sistema de pagamento. Em vez disso, define uma interface de vinculacao de custodia que conecta acordos a sistemas de pagamento externos:
┌――――――――――――――┐ ┌――――――――――――――┐ ┌――――――――――――――┐
│ API de │――――→│ API de │――――→│ Vinculacao │
│ Acordos │ │ Verificacao │ │ de Custodia │
└――――――――――――――┘ └――――――――――――――┘ └――――――|―――――――┘
│
┌―――――――――――――――――――――――|―――――――――――――――┐
│ │ │
┌――――↓――――┐ ┌――――↓――――┐ ┌――――↓――――┐
│ERC-8183 │ │ x402 │ │ Custom │
│ Escrow │ │ Pay │ │ HTTP │
└―――――――――┘ └―――――――――┘ └―――――――――┘Diferentemente do modelo binario aprovado/reprovado do ERC-8183 [2], o ASA suporta pagamento graduado com base nas pontuacoes de qualidade:
| Pontuacao Composta | Liberacao de Pagamento | Justificativa |
|---|---|---|
| ≥ 90 | 100% | Excede as expectativas |
| 75-89 | 85% | Atinge o limiar do acordo |
| 60-74 | 50% | Abaixo do limiar, mas utilizavel |
| < 60 | 0% + opcao de disputa | Abaixo da qualidade minima |
Isso aborda uma limitacao fundamental dos sistemas de custodia existentes. Um resumo de pesquisa que pontua 72% -- abaixo do limiar acordado, mas contendo conteudo util significativo -- nao deveria resultar em pagamento zero. A liberacao graduada cria incentivos apropriados: provedores sao recompensados proporcionalmente pela qualidade parcial, e clientes recebem compensacao parcial pela entrega parcial.
Risco de otimizacao de limiar. Faixas graduadas introduzem um vetor de gaming: a estrategia otima de um provedor racional e entregar qualidade logo acima do limiar de pagamento mais proximo (ex.: pontuar 76 em vez de 88, ja que ambos liberam 85%, mas o primeiro custa menos esforco). O ASA mitiga isso por meio de tres mecanismos configuraveis:
(composite_score / 100) * amount. Sem limiares abruptos, sem alvos de otimizacao. Acordos podem habilitar isso via "graduated_release": { "mode": "continuous" }.As faixas graduadas padrao permanecem disponiveis por simplicidade, mas acordos envolvendo transacoes repetidas com o mesmo provedor DEVERIAM (SHOULD) preferir funcoes de pagamento continuo para evitar incentivos de otimizacao de limiar.
Impacto na taxa de disputas. Espera-se que o pagamento graduado reduza as taxas de disputas em comparacao com o modelo binario de aprovacao/reprovacao. Nas operacoes da frota da AB Support, aproximadamente 15-20% das entregas de Bravo pontuam na faixa de 60-74 (abaixo do limiar ideal, mas contendo conteudo util significativo). Sob o modelo binario, todas essas acionariam rejeicao e potencial disputa. Sob liberacao graduada, o provedor recebe 50% do pagamento e o cliente recebe trabalho utilizavel (embora imperfeito) -- ambas as partes ficam em melhor situacao do que em um cenario de disputa. Embora esses numeros em escala de frota nao sejam estatisticamente significativos para afirmacoes gerais, sugerem que o pagamento graduado pode eliminar disputas para a fracao substancial de entregas que ficam na faixa "abaixo do limiar, mas utilizavel".
Agentes podem falhar, perder conectividade ou ser descomissionados. O ASA implementa mecanismos de seguranca baseados em timeout, adaptados do padrao de auto-liberacao de 14 dias do Upwork [22]:
Timeout do cliente: Se o cliente nao financia a custodia dentro do timeout configurado apos a ativacao do acordo, o acordo transiciona para EXPIRED.
Timeout do provedor: Se o provedor nao entrega dentro do timeout configurado, os fundos em custodia retornam ao cliente.
Timeout do avaliador: Se o avaliador nao retorna um resultado de verificacao dentro do timeout configurado, a acao padrao e hold_for_backup_evaluator -- o sistema seleciona um avaliador alternativo do pool qualificado (Secao 3.6.1). Acoes alternativas de timeout sao configuraveis por acordo: (a) split_50_50 -- nenhuma parte se beneficia da falha do avaliador, (b) return_to_client -- o cliente reteem os fundos quando a qualidade nao e verificada, ou (c) release_to_provider -- disponivel, mas NAO recomendado como padrao porque cria um risco moral onde provedores se beneficiam da falha do avaliador, habilitando um vetor de conluio onde o avaliador deliberadamente atinge o timeout e divide os proventos com o provedor.
Timeout de contestacao: Se nenhuma parte contesta um resultado de verificacao dentro da janela de contestacao, o resultado e finalizado e o pagamento e liberado ou reembolsado conforme apropriado.
O ASA utiliza cadeias de proveniencia CoC para tres propositos:
Verificacao de identidade: O hash da cadeia CoC de um agente serve como sua identidade em acordos, vinculando a entrega de servico a um historico operacional verificavel [11].
Idade operacional como sinal de confianca: O comprimento da cadeia CoC indica ha quanto tempo um agente opera continuamente. Cadeias mais longas implicam maior investimento na manutencao da proveniencia, o que serve como sinal honesto na negociacao de acordos -- seguindo o framework de sinalizacao custosa biologica formalizado no ARP v2 [12].
Ancoragem de evidencias: Resultados de verificacao podem ser anexados a cadeia CoC, criando um registro imutavel de avaliacoes de qualidade. Isso fornece evidencia forense para resolucao de disputas no AJP e dados longitudinais para pontuacao de reputacao no ARP.
O ASA e o ARP formam um loop de retroalimentacao bidirecional:
ARP → ASA (reputacao informa acordos):
ASA → ARP (verificacao alimenta reputacao):
O ASA se conecta ao AJP em dois pontos:
Registro automatico de disputas: Quando as pontuacoes de verificacao ficam abaixo do limiar de disputa do acordo E a janela de contestacao expira sem resolucao, o ASA registra uma disputa no AJP automaticamente. O pacote de disputa inclui o documento de acordo, hash do conteudo da entrega, resultado da verificacao com trilha de evidencias e identidades de ambas as partes.
Evidencia forense: O motor de forense do AJP pode solicitar a trilha de verificacao completa do ASA -- cada pontuacao por dimensao, cada evidencia do avaliador, cada resultado de tarefa canario -- como evidencia para investigacao.
Um acordo ASA entre Cliente C e Provedor P e um jogo cooperativo onde ambas as partes se beneficiam da conclusao bem-sucedida, mas possuem incentivos divergentes quanto ao nivel de qualidade e preco.
Utilidade do Cliente: U_C = V(qualidade) - preco - custo_de_verificacao
Onde V(qualidade) e o valor que o cliente obtem da entrega, crescente em qualidade.
Utilidade do Provedor: U_P = preco - custo(qualidade) - risco_de_garantia
Onde custo(qualidade) aumenta com o nivel de qualidade, e risco_de_garantia e a perda esperada por penalizacao da custodia.
Solucao de Barganha de Nash: O acordo otimo maximiza o produto do excedente de ambas as partes acima de seu payoff de desacordo (BATNA -- Best Alternative To Negotiated Agreement, ou Melhor Alternativa a um Acordo Negociado) [41]:
max (U_C - d_C)(U_P - d_P)Onde d_C e o BATNA do cliente (encontrar outro provedor ou fazer o trabalho ele mesmo) e d_P e o BATNA do provedor (encontrar outro cliente ou ficar ocioso).
O design aplicado por protocolo do ASA alinha incentivos por meio de tres mecanismos:
Participacao proporcional: A liberacao graduada de pagamento garante que melhorias de qualidade sempre aumentem a receita do provedor. Um provedor pontuando 88% recebe mais que um pontuando 76%. Isso elimina o limiar binario abrupto onde uma pontuacao de 74% e uma pontuacao de 10% produzem resultados identicos de pagamento zero.
Efeitos de reputacao: Como os resultados de verificacao do ASA alimentam o ARP, cada acordo tem consequencias reputacionais alem da transacao imediata. Um provedor que consistentemente entrega qualidade de 60% vera pontuacoes de reputacao em declinio, reduzindo seu poder de negociacao futuro. Essa dinamica converte jogos de rodada unica em jogos iterados com equilibrios cooperativos.
Vinculacao de garantia: Mecanismos de staking/penalizacao (seguindo o framework da Outlier Ventures [42]) criam responsabilidade financeira direta. O custo de trapacear -- entregar baixa qualidade e absorver a penalizacao da custodia -- deve exceder o custo de realizar o trabalho adequadamente. Para que essa desigualdade se mantenha, a garantia deve ser proporcional ao valor do acordo, nao nominal (evitando o problema dos creditos de nuvem).
Nem todos os pares de agentes podem formar acordos mutuamente beneficos. Acordos estaveis requerem:
O ASA nao alega resolver todos os desafios de teoria dos jogos no comercio entre agentes. Varios problemas abertos permanecem:
Resistencia a conluio: Se o avaliador entra em conluio com qualquer parte, o resultado da verificacao e corrompido. O consenso multi-avaliador reduz, mas nao elimina, esse risco. Uma prova formal de design de mecanismo de resistencia a conluio esta alem do escopo deste protocolo.
Ataques Sybil a reputacao: Um agente poderia criar multiplas identidades para reiniciar uma reputacao ruim. O ASA herda as propriedades de resistencia a Sybil de seu sistema de identidade subjacente -- cadeias CoC tornam ataques Sybil caros (manter cadeias paralelas), mas identidades baseadas em chaves de API sao trivialmente suscetivas a Sybil.
Manipulacao de dimensoes de qualidade: Mesmo com pontuacao multidimensional, um agente suficientemente capaz poderia aprender a produzir saidas que pontuam bem em dimensoes medidas enquanto sao subotimas em dimensoes nao medidas. O mecanismo de metrica sombra detecta casos simples, mas o gaming adversarial de qualidade na fronteira permanece um problema de pesquisa aberto.
| Sistema | Especifico para Agentes | Legivel por Maquina | Aplicacao | Multidimensional | Status |
|---|---|---|---|---|---|
| ITIL 4 SLM [18] | Nao | Nao | Manual | Nao | Maduro, infraestrutura |
| WSLA (IBM, 2003) [43] | Nao | XML | Monitoramento | Limitado | Legado |
| WS-Agreement (OGF, 2007) [44] | Nao | XML | Modelos | Limitado | Legado |
| SLAC (Uriarte et al., 2015) [45] | Nao | DSL formal | Dinamica | Sim | Academico |
| AgentSLA DSL (2025) [1] | Sim | JSON | Nenhuma | Sim (mais de 40 metricas) | Academico, pre-producao |
| Mayer Brown Framework (2026) [24] | Parcial | Texto juridico | Remedios juridicos | Sim (6 componentes) | Analise juridica |
| ASA (este trabalho) | Sim | JSON | Automatizada (custodia) | Sim (configuravel) | Especificacao de protocolo |
O AgentSLA e o trabalho anterior mais proximo. O ASA estende a abordagem de especificacao do AgentSLA adicionando aplicacao (vinculacao de custodia), negociacao (protocolo estruturado) e verificacao (integracao com Agent-as-a-Judge). Os dois sao complementares: o modelo de qualidade e a sintaxe DSL do AgentSLA poderiam servir como camada de especificacao dentro de acordos ASA.
| Sistema | Qualidade Semantica | Automatizado | Multidimensional | Nativo para Agentes | Custo/Avaliacao |
|---|---|---|---|---|---|
| PayCrow [17] | Nao (estrutural) | Sim | Nao (binario) | Sim | 2% da tx |
| ERC-8183 [2] | Depende do avaliador | Sim | Nao (binario) | Sim | Taxas de gas |
| SonarQube [20] | Somente codigo | Sim | Sim (3+) | Nao | Gratuito/US$$$ |
| LLM-as-a-Judge [33] | Sim | Sim | Configuravel | Adaptavel | US$ 0,01-5 |
| Agent-as-a-Judge [65][4] | Sim (~90% codigo; 60-68% especializado) | Sim | Sim (5 metodos) | Sim | US$ 0,03-31 |
| API de Verificacao ASA | Sim (escalonada; ~90% codigo, 60-68% especializado) | Sim | Sim (configuravel) | Sim | US$ 0,01-31 |
A API de Verificacao do ASA se diferencia por oferecer profundidade escalonada (estrutural/semantica/composta), dimensoes configuraveis, operacao autonoma sem exigir um acordo e integracao com custodia para aplicacao automatizada.
| Sistema | Acordos | Verificacao | Pagamento | Negociacao | Reputacao |
|---|---|---|---|---|---|
| x402 [14] | Nao | Nao | Sim (HTTP 402) | Nao | Nao |
| ERC-8183 [2] | Parcial (job) | Externa | Sim (custodia) | Nao | Via ERC-8004 |
| ACP/AP2/TAP [46] | Nao | Nao | Sim (cartao/cripto) | Nao | Nao |
| Fetch.ai AEA [47] | Descoberta | Nao | Sim (FET) | Descoberta | Staking FET |
| Pactum [48] | Compras | Nao | Via cliente | Sim (liderada por IA) | Nao |
| Circle AI Escrow [49] | Parsing de PDF | Analise de imagem | Sim (USDC) | Nao | Nao |
| ASA | Protocolo completo | Multi-camada | Via vinculacao | Estruturada | Via ARP |
Nenhum sistema existente cobre toda a pilha, da negociacao ao acordo, a verificacao e a aplicacao. O Pactum lida com negociacao de compras, mas nao com verificacao de qualidade. O ERC-8183 lida com custodia, mas nao com negociacao ou especificacao de qualidade. O x402 lida com pagamento, mas nao com acordos. A contribuicao do ASA e a integracao -- conectando essas capacidades em um fluxo de protocolo coerente.
O ASA e projetado para funcionar com a infraestrutura existente, nao para substitui-la. Um acordo ASA pode:
O ASA fornece a logica de acordo que conecta esses componentes. Sua vantagem competitiva e integracao e abertura, nao aprisionamento a infraestrutura proprietaria.
O ASA enfrenta ameacas de tres tipos de adversarios:
Provedor malicioso: Entrega saida de baixa qualidade, tenta manipular metricas de verificacao ou entra em conluio com o avaliador.
Cliente malicioso: Rejeita trabalho satisfatorio para evitar o pagamento, registra disputas frivolas ou manipula a negociacao.
Avaliador malicioso: Retorna resultados de verificacao tendenciosos -- seja para ajudar uma parte em conluio ou para extrair subornos.
| Ataque | Vetor | Mitigacao |
|---|---|---|
| Gaming de qualidade | Provedor otimiza para metricas medidas enquanto degrada qualidade nao medida | Metricas sombra detectam deslocamento de danos; pontuacao multidimensional aumenta o custo do gaming; tarefas canario detectam gaming sistematico |
| Conluio do avaliador | Avaliador e provedor concordam em inflar pontuacoes | Rotacao de avaliadores; tarefas canario com pontuacoes conhecidas; consenso multi-avaliador para acordos de alto valor |
| Injecao de prompt na negociacao | Agente incorpora instrucoes em mensagens de negociacao para manipular o LLM do oponente | Campos JSON estruturados (nao texto livre); rationale_code de enum fixo; sem pontos de injecao de texto bruto |
| Lavagem de reputacao Sybil | Agente cria identidade nova apos acumular reputacao ruim | Cadeias CoC tornam criacao de identidade cara; comprimento minimo de cadeia para elegibilidade em acordos; referencias cruzadas de historicos de verificacao |
| Negacao de avaliacao | Avaliador fica offline para bloquear a liberacao de pagamento | Interruptor de homem morto com timeout configuravel; especificacao de avaliador reserva; acoes-padrao de timeout |
| Ataque de custo de verificacao | Cliente solicita verificacao com custo de avaliacao excedendo o valor do acordo | Limites de custo de verificacao especificados no acordo; avaliador rejeita solicitacoes que excedem o teto de custo |
| Troca de entrega | Provedor submete uma entrega para verificacao, mas entrega outra ao cliente | Vinculacao por hash de conteudo -- hash da entrega e registrado tanto na solicitacao de verificacao quanto no sistema de custodia; incompatibilidade de hash invalida a verificacao |
| Ataque de replay | Resubmissao de um resultado de verificacao anterior para uma nova entrega | Cada resultado de verificacao inclui agreement_id, hash do conteudo da entrega e carimbo de tempo; deteccao de duplicatas previne replay |
A Lei de Goodhart -- "quando uma medida se torna um alvo, ela deixa de ser uma boa medida" [19] -- e a ameaca mais fundamental a qualquer sistema de acordo baseado em qualidade. O ASA a aborda em tres niveis:
Balanceamento de metricas: Cada metrica alvo e pareada com uma metrica sombra que mede o deslocamento de danos esperado. Se a precisao e o alvo, a taxa de alucinacao e a sombra. Se a velocidade e o alvo, a qualidade e a sombra. Um agente que manipula a precisao produzindo saidas verbosas que cobrem todos os angulos veria sua metrica sombra de concisao degradar.
Adaptabilidade do avaliador: Avaliadores Agent-as-a-Judge nao estao restritos as dimensoes especificadas. O campo de evidencias do avaliador pode sinalizar questoes de qualidade alem dos criterios formais. Embora essas sinalizacoes nao afetem diretamente a pontuacao, sao registradas na trilha de verificacao e disponiveis para evidencia de disputas e analise de reputacao.
Rotacao temporal: Modelos de acordo e rubricas de qualidade sao versionados e evoluem. Um provedor que faz sobreajuste aos padroes de avaliacao da rubrica v1 enfrenta desempenho degradado quando a rubrica v2 e implantada. Isso cria uma dinamica de Rainha Vermelha que penaliza o gaming em relacao a melhoria genuina de qualidade.
Os resultados de verificacao do ASA contem informacoes sobre a qualidade das entregas que podem ser comercialmente sensiveis. O protocolo fornece:
Controle de visibilidade dos resultados: Acordos especificam quem pode consultar os resultados de verificacao (somente as partes, partes + sistema ARP, ou publico).
Agregacao para reputacao: Quando o ASA reporta ao ARP, envia estatisticas agregadas (taxa de aprovacao, pontuacao composta media) em vez de detalhes individuais de verificacao.
Isolamento de conteudo: A API de Verificacao recebe o conteudo da entrega para avaliacao, mas nao o armazena. Apenas o hash do conteudo persiste no resultado da verificacao. Avaliadores devem excluir o conteudo da entrega apos a avaliacao.
A frota da AB Support opera um ASA informal desde marco de 2026. A frota de seis agentes processa tarefas seguindo o ciclo de vida do ASA:
| Conceito ASA | Implementacao na Frota |
|---|---|
| Acordo | Especificacoes de tarefas estruturadas com entregas, restricoes e criterios de qualidade |
| Dimensoes de Qualidade | Seis dimensoes: abrangencia, profundidade, precisao, fontes, referencias cruzadas, qualidade da escrita |
| SLO | Pontuacao minima de 60/100 por dimensao; media ≥ 60 para aceitar |
| Verificacao | Alex (coordenador) revisa usando avaliacao Agent-as-a-Judge |
| Resposta graduada | Pontuacao ≥ 60: aceitar e promover. Pontuacao < 60: devolver ao Bravo com solicitacoes especificas de revisao |
| Trilha de evidencias | Resultados de verificacao armazenados em documentos estruturados de rastreamento de qualidade |
| Retroalimentacao de reputacao | O historico de Bravo informa a complexidade de atribuicao de tarefas futuras |
Este prototipo valida varias decisoes de design do ASA:
A implementacao de referencia sera entregue como:
asa-protocol): Criacao, validacao, assinatura e gerenciamento de ciclo de vida de acordos. Cliente de verificacao com backends de avaliador plugaveis.A verificacao ASA atual e pos-hoc -- a qualidade e avaliada apos a entrega. Versoes futuras devem suportar monitoramento de qualidade em tempo real durante a execucao da tarefa, permitindo o encerramento antecipado de trabalho em falha antes que os custos se acumulem. Isso segue o padrao de SRM agentivo da Newgen para deteccao preditiva de violacoes [50] e a previsao de violacoes baseada em ML da Sirion AI [51].
A avaliacao Agent-as-a-Judge custa US$ 0,03-31 por avaliacao [65]. Em escala com milhoes de transacoes entre agentes, isso deve diminuir em ordens de magnitude. Direcoes de pesquisa incluem:
As dimensoes de qualidade padrao do ASA sao ajustadas para os tipos de servico mais comuns no comercio atual entre agentes (pesquisa, codigo, analise). A medida que os servicos de agentes se diversificam, frameworks de qualidade especificos por dominio serao necessarios para conteudo criativo, analise financeira, informacao medica, raciocinio juridico e outros dominios especializados.
Este whitepaper fornece analise informal de teoria dos jogos. Provas formais de design de mecanismo -- demonstrando que a estrutura de incentivos do ASA e a prova de estrategia, individualmente racional e eficiente sob condicoes especificas -- fortaleceriam os fundamentos teoricos do protocolo.
Os requisitos de recursos do ASA escalam em tres eixos primarios: armazenamento de acordos, throughput de verificacao e carga de negociacao.
| Escala de Implantacao | Agentes | Acordos/dia | Armazenamento/ano | Avaliadores Concorrentes | Overhead de Canarios |
|---|---|---|---|---|---|
| Pequena | 100 | 1.000 | ~7 GB | 1-3 | ~US$ 60/dia |
| Media | 10.000 | 100.000 | ~730 GB | 30-330 | ~US$ 6.000/dia |
| Grande | 1.000.000 | 10.000.000 | ~73 TB | 3.000-33.000 | ~US$ 600.000/dia |
Premissas: Documentos de acordo possuem em media ~2 KB; resultados de verificacao possuem em media ~1 KB; verificacao semantica leva 10-120 segundos por avaliacao; tarefas canario rodam em 1 a cada 5 entregas (20% de overhead); custo do avaliador e em media US$ 0,30 por avaliacao.
Preocupacoes-chave de escalabilidade:
O formato de acordo do ASA deve ser submetido para padronizacao por meio de orgaos apropriados. Candidatos incluem a Agentic AI Foundation (AAIF) para integracao de protocolo com MCP/A2A, o W3C AI Agent Protocol Community Group para acordos nativos de web entre agentes, e a ISO para padronizacao internacional (construindo sobre o modelo de qualidade ISO/IEC 25010 e a gestao de IA ISO/IEC 42001).
A economia de agentes possui meios de pagamento, canais de comunicacao e registros de identidade. Falta uma forma padronizada para formar, verificar e aplicar acordos de servico. O ASA preenche essa lacuna com duas superficies de API -- Acordos para contratos legiveis por maquina e Verificacao para avaliacao de qualidade -- conectadas por logica aplicada por protocolo que colapsa o pipeline tradicional de especificar-monitorar-detectar-reclamar-compensar em uma operacao atomica.
O protocolo se baseia em blocos de construcao maduros: a extensao ISO 25010 do AgentSLA para especificacao de qualidade [1], Agent-as-a-Judge para avaliacao semantica alcancando aproximadamente 90% de concordancia humana em geracao de codigo [65] com taxas menores em dominios especializados [36], o modelo de custodia tripartite do ERC-8183 para aplicacao de pagamento [2] e o formato duplo humano/maquina dos contratos ricardianos para defensibilidade juridica [3]. A contribuicao do ASA e a integracao -- conectando especificacao a negociacao, verificacao e pagamento em um protocolo coerente e aberto.
Tres escolhas de design definem o carater do ASA. Primeiro, resultados acima de disponibilidade -- a qualidade e medida pelo que foi entregue, nao por se o servidor estava funcionando, seguindo a mudanca da industria de SLAs para XLAs [23][24]. Segundo, graduado acima de binario -- qualidade parcial recebe pagamento parcial, criando incentivos continuos para melhoria em vez de efeitos de limiar. Terceiro, integracao aberta acima de aprisionamento proprietario -- o ASA funciona com qualquer sistema de identidade, qualquer meio de pagamento e qualquer plataforma de custodia, especificando logica de acordo sem impor infraestrutura.
O protocolo e informado pela pratica. A frota de seis agentes da AB Support opera um ASA informal desde marco de 2026, validando pontuacao de qualidade multidimensional, especificacao estruturada de tarefas e avaliacao Agent-as-a-Judge em operacoes diarias. Formalizar esses padroes em um protocolo aberto estende seu valor a qualquer ecossistema de agentes.
Desafios permanecem. A verificacao de qualidade semantica, embora alcancando aproximadamente 90% de concordancia humana em geracao de codigo [65], cai para 60-68% em dominios especializados [36] e possui vieses documentados. A Lei de Goodhart garante que metricas medidas serao manipuladas por agentes suficientemente capazes [19]. A resistencia a conluio sob condicoes adversariais arbitrarias carece de prova formal. Essas sao limitacoes honestas, nao fraquezas ocultas -- e definem a fronteira de pesquisa do protocolo.
Os blocos de construcao para acordos de servico entre agentes estao surpreendentemente maduros. A lacuna e a integracao. O ASA fornece essa integracao.
[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 esta licenciado sob a Licenca Apache 2.0. Voce pode usar, modificar e distribuir este trabalho com atribuicao a AB Support LLC.
A especificacao do protocolo, modelos de dados e definicoes de API contidos neste documento sao fornecidos como um padrao aberto para a economia de agentes. Nenhuma reivindicacao de patente e feita ou implicada.
© 2026 AB Support LLC. Todos os direitos reservados sob os termos da Licenca Apache 2.0.