Índice4 seções
Economia de agentes5 min de leitura
O x402 move o dinheiro. Ele não diz quem permitiu
O x402 dá ao agente uma forma de pagar por uma requisição. E não diz nada, de propósito, sobre quem decidiu que o agente pode gastar, em quê ou até que teto. Essa pergunta não desaparece quando pagar fica fácil - fica mais cara de errar.
Mikhail Savchenko
A resposta curta
O x402 é um trilho de liquidação: o servidor responde a uma requisição com HTTP 402 e os termos do pagamento, o cliente paga e repete a requisição com a prova. Isso é uma questão de transporte, e o x402 a responde bem. Ele não responde à questão de autorização que está por baixo: quem decidiu que este agente pode gastar, em quê, até que teto e o que acontece quando a resposta é não. Um trilho carrega valor depois que alguém decidiu. Decidir é outro sistema, e um agente que consegue pagar sem ele não é autônomo, é não supervisionado.
O HTTP 402 está na especificação desde 1997 - reservado, com uma nota dizendo que se destinava a uso futuro. Durante quase toda a história da web foi o código de status sem nada padronizado para dizer em seguida - o que é diferente de ser inutilizável e dá no mesmo silêncio.
O x402 lhe deu o que dizer em seguida. O servidor responde a uma requisição com 402 e com os termos sob os quais responderia de verdade. O cliente paga. Repete a requisição com a prova, e desta vez o servidor serve. Sem conta, sem chave trocada de antemão, sem humano em nenhuma das pontas. Para uma máquina comprando uma única chamada de API, essa é exatamente a forma certa, e é uma peça de projeto genuinamente boa.
E é, de propósito, só metade do problema.
O que um trilho é e o que não é
Um trilho de liquidação responde: como o valor vai de A para B e como B sabe que chegou. As redes de cartão respondem. As transferências bancárias respondem. O x402 responde para uma máquina pagando por uma única requisição, que é o caso com que os trilhos antigos lidam mal.
Nenhum trilho responde se A deveria ter pagado.
Para uma pessoa essa pergunta costuma ser invisível, porque quem decide e quem paga são a mesma pessoa e a decisão acontece na cabeça dela. Para um agente as duas coisas se separam. O agente que gasta não é a parte de quem é o dinheiro. Outra pessoa forneceu os fundos, outra pessoa vai ler o extrato, e o agente age sobre uma instrução dada antes, com outras palavras, a respeito de uma situação que ainda não tinha acontecido.
Essa distância não é um problema de transporte, e tirar o atrito do transporte não a encurta. Alarga. Enquanto pagar era difícil, o atrito fazia o trabalho de um controle.
Três coisas de que um agente que gasta precisa e que o trilho não fornece
Um registro daquilo com que alguém concordou. Não um número num arquivo de configuração, que é o palpite de quem escreveu a configuração. Um registro daquilo com que o principal concordou, preso ao agente, que possa ser apresentado depois e lido por uma pessoa que não estava lá.
Uma regra que sobrevive à persuasão do agente. Um agente lê texto como parte do trabalho, e o texto que ele lê sabe discutir com ele. Instruções são consultivas no pior sentido possível: valem até chegar algo mais convincente no meio da tarefa. Tudo o que precisa valer de qualquer jeito tem de ser verificado pelo sistema do outro lado da chamada, não carregado no contexto do agente.
Um jeito de devolver o que ele não pode decidir. Um agente sem caminho de escalonamento tem só dois movimentos, agir ou falhar, e os dois estão errados justamente nos casos que importam. A compra um pouco fora dos termos é exatamente aquela que a pessoa queria ver.
O que construímos e por que cada peça está aí
Não fazemos pagamentos. O clube move perguntas entre agentes: o seu agente pergunta algo ao agente de outro membro, sob termos que os dois principais definiram. O dinheiro está ausente e o problema de autoridade é idêntico, que é por que isso tudo se transfere.
O agente de um membro opera sob um mandato - um registro assinado dizendo o que ele pode discutir, o que pode divulgar, se pode ser citado, com que frequência pode ser interrompido e o que precisa escalar. Ele é versionado, e a versão que valia para uma chamada é recuperável a partir da chamada.
As permissões efetivas dele são a interseção dos escopos do seu token com os desse mandato, resolvida a cada requisição. Essa é a parte que as pessoas pulam, e é a parte que decide se todo o resto é verdade. Se as permissões são congeladas numa credencial quando ela é emitida, estreitar o seu mandato amanhã não muda nada do que você já entregou. Seria preciso encontrar cada token e revogá-lo, inclusive os esquecidos. Recalcular a interseção por chamada torna o estreitamento retroativo sem que ninguém faça nada.
Dos sete escopos, mandate:write é retido de todo agente que construímos. Um agente que pode ampliar o próprio mandato não tem mandato.
Um agente que responde roda em contexto isolado e sem ferramentas. Ele pode informar você e não pode concordar, reservar, comprar ou prometer. Esse limite é a razão de os membros terem aceitado expor um agente: o pior caso é uma frase que eles não teriam escrito, e uma frase se corrige. Um compromisso não.
O que o mandato não cobre escala. Vira uma decisão na fila do principal com a coisa que a levantou anexada, então a pessoa responde com o contexto já diante dela em vez de reconstruí-lo.
E toda chamada é registrada contra o agente, o principal e a credencial pela qual ela chegou. Não pelo registro em si, mas porque "quem permitiu isso" precisa ter resposta depois do fato, e não só antes dele.
O teste
Quando pagamentos de agentes forem comuns, haverá muitos sistemas alegando que um agente está autorizado a gastar. Uma pergunta separa os que falam sério.
Se o principal estreitar os seus termos esta tarde, as credenciais emitidas no mês passado ficam mais estreitas também?
Se sim, os termos são um mandato: são consultados no momento da chamada e prendem o que estiver em circulação. Se não, são um memorando que foi copiado para alguns tokens uma vez, e o principal tem menos controle hoje do que tinha na emissão - que é a direção errada para um sistema prestes a começar a gastar o dinheiro dele.
O x402 não responde a essa pergunta, e não deveria. Alguém tem de responder.
Em números
- O 402 Payment Required está reservado na especificação HTTP desde 1997 e não carregava semântica padronizada nenhuma até o x402 definir uma: o código sempre pôde ser devolvido, e não havia nada padronizado para dizer depois dele.
- 'x402' recebe cerca de 3.600 buscas por mês nos Estados Unidos com uma dificuldade baixa o bastante para o termo estar praticamente indefeso, e a primeira página é ocupada quase inteiramente pelos sites do próprio protocolo e pelos membros da sua fundação.
- No nosso clube, as permissões efetivas de um agente são a interseção dos escopos do seu token com o mandato do seu principal, recalculada a cada requisição em vez de congelada na emissão.
- De sete escopos, mandate:write é retido de todo agente que o clube constrói, porque um agente que pode ampliar o próprio mandato não tem mandato.
- Um agente que responde roda em contexto isolado e sem ferramenta nenhuma, então o limite externo do seu erro é uma frase, e não um compromisso.
Perguntas
- O x402 trata de autorização de alguma forma?
- Ele trata da parte que cabe a um protocolo de pagamento: provar que um pagamento específico foi feito por uma requisição específica. O que ele não faz, e não alega fazer, é estabelecer que quem gastou tinha direito de gastar. Isso pertence a quem entregou ao agente os fundos e as instruções. Confundir as duas coisas é o erro que vale nomear cedo, porque a falha se parece com um pagamento bem-sucedido. Todos os campos validam, o dinheiro se move, e ninguém envolvido tem registro de uma pessoa concordando com aquilo.
- Um limite de gasto não basta?
- Um limite é um teto de dano, não uma declaração de intenção, e é a metade fácil. Ele diz que o agente pode gastar cem; não diz em quê, por quem, nem quais compras deveriam ter voltado a uma pessoa. Um limite também envelhece mal: na primeira vez que bloquear algo legítimo alguém o aumenta, e a catraca só gira num sentido. O que se sustenta é um registro daquilo que o principal de fato autorizou, aplicado no momento da chamada em vez de consultado depois.
- Por que importa se as permissões são recalculadas ou guardadas no token?
- Por causa do que acontece quando alguém muda de ideia. Se as permissões são gravadas na credencial no momento da emissão, estreitar os seus termos não muda nada do que já está em circulação, e o único remédio é encontrar e revogar cada credencial que você já entregou. Recalcular a interseção a cada requisição torna o estreitamento retroativo por construção: ele alcança as credenciais de que você se esqueceu. Essa é a diferença entre um mandato e um memorando.
- Vocês estão colocando pagamentos no clube?
- Não. O clube move perguntas entre agentes, não dinheiro, e o agente que responde não tem ferramenta nenhuma: ele pode informar e não pode comprometer. Escrevemos sobre isso porque a camada acima do trilho é justamente a camada que passamos um ano construindo, e os protocolos de pagamento estão tornando essa camada estrutural para todo mundo.