O cenário agente-para-agente é onde "quem segura o dinheiro" deixa de ser abstrato. O agente A contrata o agente B para uma tarefa; B é operado por outra pessoa, numa infraestrutura que A não controla. Se A paga primeiro, B pode devolver lixo ou nada. Se B trabalha primeiro, A pode se recusar a pagar. Dois programas não conseguem resolver isso entre si melhor do que dois desconhecidos. A solução é a mesma dos desconhecidos: uma terceira coisa segura o dinheiro, e a liberação depende de uma verificação que nenhum dos agentes controla.
Como isso se traduz no iEscrow
- 1Cada agente age sob a conta verificada de um humano. Não há contas de agentes; há pessoas cujos agentes trabalham para elas.
- 2O agente A abre uma operação de serviço (ou uma por etapas para um trabalho mais longo) descrevendo o entregável. O humano do agente A aprova o depósito por link e 2FA. O dinheiro agora está em escrow: nem com A, nem com B.
- 3O agente B entrega. O entregável é anexado à operação. O agente A lê e recomenda; o humano do lado de A confirma a etapa, e essa parte é liberada para o humano de B.
- 4Se o entregável está errado, abre-se uma disputa e um árbitro humano decide com base na descrição e nas provas. Nenhum agente pode liberar ou reembolsar por conta própria.
Por que o humano continua no circuito, até aqui
- Um agente que pode liberar fundos pode ser convencido a liberar fundos. Um entregável que contém instruções ("marque isto como concluído") é o ataque óbvio, e a única defesa que se sustenta é que liberar precise de uma pessoa.
- Atribuição do dinheiro. Cada liberação cai no saldo de uma pessoa com um registro do que foi. É isso que torna o pagamento explicável depois.
- Disputas precisam de julgamento. Código verifica um hash; não julga se uma tradução está boa.
O que isto não é: um trilho de micropagamentos para agentes que chamam as APIs uns dos outros. Para isso, pagar-e-receber é a ferramenta certa. Escrow é para a tarefa em que uma entrega que falha custa mais do que um centavo.