The Provenance Paradox in Multi-Agent LLM Routing: Delegation Contracts and Attested Identity in LDP

1. O Problema: O Paradoxo da Proveniência

O artigo identifica uma falha crítica em sistemas multi-agente de LLM (Large Language Models) que delegam tarefas com base em métricas de qualidade auto-relatadas.

• Contexto: Protocolos existentes (como A2A e MCP) permitem que agentes descubram e se comuniquem, mas não governam a delegação sob alegações de qualidade não verificáveis.
• O Paradoxo: Quando os delegados podem inflar suas próprias pontuações de qualidade para atrair trabalho, o roteamento baseado nesses sinais torna-se contraproducente. O sistema passa a selecionar sistematicamente os piores delegados (os mais desonestos), performando pior do que uma seleção aleatória.
• Deficiências Atuais:
  1. Autoridade não limitada: Não há mecanismos para especificar orçamentos, prazos ou critérios de sucesso.
  2. Identidade não verificada: As pontuações de qualidade são apenas auto-relatadas, criando incentivos para manipulação.
  3. Tratamento de falhas não estruturado: Erros são comunicados como strings não estruturadas, impedindo recuperação automatizada.

2. Metodologia e Proposta Técnica

O autor propõe extensões ao LLM Delegate Protocol (LDP) para transformar a delegação de um problema de comunicação em um problema de governança. As extensões são retrocompatíveis (campos opcionais).

A. Contratos de Delegação (Delegation Contracts)

Introduz um campo opcional no envio de tarefas (TASK_SUBMIT) que define expectativas explícitas:

• Objetivos e Critérios de Sucesso: Definição clara do que constitui uma tarefa bem-sucedida.
• Políticas de Restrição: Limites de tokens, custos em USD, restrições de segurança e profundidade máxima de delegação.
• Políticas de Falha:
  • fail_closed: Rejeita a tarefa e retorna um erro tipado se o contrato for violado (preservando a saída parcial).
  • fail_open: Aceita a tarefa mas registra a violação.
• Validação: Ocorre no lado do cliente (delegador) ao receber o resultado, garantindo auditoria sem necessidade de enforcement adversarial no protocolo.

B. Modelo de Identidade: Reivindicado vs. Atestado (Claimed vs. Attested Identity)

Para resolver o paradoxo, o protocolo adiciona um campo claim_type às métricas de qualidade, criando uma hierarquia de confiança:

1. self_claimed: Relatado pelo próprio delegado (Baixa confiança).
2. runtime_observed: Medido pelo runtime do LDP baseado em desempenho real (Média confiança).
3. issuer_attested: Verificado por um terceiro confiável (Alta confiança).
4. externally_benchmarked: Validado por serviços de benchmark externos (Máxima confiança).

• Impacto: Roteadores podem filtrar ou ponderar delegados baseando-se no nível de atestação, eliminando o viés de auto-relato inflado.

C. Semântica de Falhas Tipadas (Typed Failure Semantics)

Substitui strings de erro genéricas por uma estrutura LdpError padronizada contendo:

• Categoria: runtime, transport, policy, capability, quality, identity, session.
• Severidade: Warning, Error, Fatal.
• Retryable: Indicador booleano se a falha é recuperável.
• Saída Parcial: Preservação do output do delegado mesmo em falhas de contrato.
• Benefício: Permite estratégias de recuperação automatizada (ex: reenviar para outro delegado se a falha for de capability, ou escalar se for de policy).

D. Status de Verificação e Linhagem

Adiciona um enum verification_status (não verificado, auto-verificado, verificado por pares, etc.) e uma cadeia de linhagem para rastrear quem processou a tarefa e como foi verificada.

3. Resultados Experimentais

A. Simulação (O Paradoxo)

• Configuração: 10 delegados simulados (7 honestos, 3 desonestos que inflam suas pontuações em 0.35–0.45).
• Resultados:
  • Roteamento por Auto-reivindicação: Qualidade média de 0.55 (pior que o aleatório).
  • Roteamento Cego (Aleatório): Qualidade média de 0.68.
  • Roteamento Atestado (Baseado em qualidade real): Qualidade média de 0.95.
• Conclusão: O roteamento por auto-reivindicação falha catastróficamente, selecionando 100% das vezes os delegados desonestos.

B. Análise de Sensibilidade

Testado em 36 configurações variando a fração de delegados desonestos e a magnitude da inflação.

• O paradoxo ocorre consistentemente quando há uma fração significativa de agentes desonestos (≥30%) com inflação alta.
• O roteamento atestado mantém-se robusto em todas as configurações.

C. Validação com Modelos Reais (Claude)

• Setup: Uso de três modelos da Anthropic (Sonnet, Haiku e uma versão degradada do Haiku). A versão degradada foi configurada para reivindicar a maior pontuação de qualidade (0.95).
• Resultado:
  • Auto-reivindicação: Pontuação média de 8.90 (o modelo degradado foi selecionado 100% das vezes).
  • Cego: Pontuação média de 9.30.
  • Atestado: Pontuação média de 9.30 (selecionou o Sonnet corretamente).
• Conclusão: O paradoxo foi confirmado em modelos reais; a metadados de qualidade não verificada degrada o roteamento.

D. Overhead de Desempenho

• Tamanho da Mensagem: Aumento de ~54% (de 972 para 1.497 bytes) ao incluir contratos. Considerado insignificante frente ao payload de tokens de LLM.
• Processamento: Validação de contrato custa ~0.45 µs. A latência de inferência de LLM (500ms–5s) torna esse overhead imperceptível.

4. Contribuições Principais

1. Governança de Delegação: Introdução de contratos para limitar autoridade e definir expectativas explícitas.
2. Solução para o Paradoxo: O modelo de identidade "Reivindicado vs. Atestado" que impede a manipulação de roteamento.
3. Recuperação Automatizada: Semântica de falhas tipadas que permite ao sistema reagir a erros sem intervenção humana.
4. Prova Empírica: Demonstração de que a falta de governança em metadados de qualidade pode levar a resultados piores que o acaso.

5. Significado e Impacto

O artigo estabelece que a delegação confiável exige mais do que apenas roteamento consciente de identidade. Uma vez que as alegações de qualidade influenciam a alocação de trabalho, a delegação torna-se um problema de governança.

• Implicação Prática: Sistemas multi-agente que dependem de auto-relatos de qualidade estão fadados a falhar em ambientes competitivos ou maliciosos.
• Futuro: O trabalho aponta para a necessidade de infraestruturas de atestação (issuers), linguagens de especificação formal para critérios de sucesso e enforcement de recursos em tempo de execução.
• Disponibilidade: As extensões foram implementadas em SDKs (Python e Rust) e são retrocompatíveis, permitindo adoção imediata sem quebrar sistemas existentes.

Em resumo, o artigo fornece a base teórica e prática para transformar a delegação de agentes de IA de um processo "envie e torça" para um sistema governado, auditável e resiliente.