Fonte Original: Waterdrop Capital

Resumo

Modelos grandes estão evoluindo de ferramentas que respondem perguntas para agentes inteligentes capazes de planejar, invocar ferramentas e entregar resultados. Paralelamente, liquidação com stablecoins, protocolos de pagamento nativos para HTTP (HTTP 402) e carteiras inteligentes começam a se integrar numa infraestrutura de pagamentos projetada para máquinas. Um programa pode receber uma cotação em tempo de execução, assinar uma autorização e concluir um micropagamento — algo que, há poucos anos, era mera ideia, mas agora é um caminho tecnológico viável.

No entanto, “máquinas podem pagar” não equivale a “máquinas podem concluir transações”. Quando um agente inteligente precisa adquirir serviços como busca, dados, poder computacional, geração de conteúdo ou análise profissional, ainda enfrenta desafios como descobrir endpoints, comparar cotações, efetuar pagamentos entre protocolos, controlar orçamentos, verificar entrega e consolidar conciliações. Trilhos de pagamento resolvem como o valor se move, mas não resolvem automaticamente como a demanda encontra a oferta nem se o serviço correto foi recebido após o pagamento.

Isso significa que, na próxima fase do Pagamento por Agente, o foco competitivo pode deixar de ser apenas o throughput do protocolo, a velocidade de liquidação ou o número de blockchains suportadas, passando a ser a capacidade de construir uma infraestrutura real de comprador para máquinas. Este artigo discute por que o Pagamento por Agente se tornará uma trilha independente — partindo da estrutura da demanda, evolução dos protocolos, gargalos reais e divisão de trabalho no mercado — e quais lacunas críticas ainda persistem antes de sua adoção em larga escala.

Introdução: Agentes Inteligentes Ganham um Orçamento Discrecional Restrito

Nos últimos dois anos, as capacidades dos agentes inteligentes evoluíram rapidamente. Inicialmente, modelos grandes lidavam principalmente com geração de informação — usuários faziam perguntas e os modelos produziam texto. Em seguida, a invocação de ferramentas permitiu que os modelos buscassem páginas web, consultassem bancos de dados, executassem código e operassem softwares. Mais adiante, agentes inteligentes passaram a decompor objetivos, formular planos e ajustar ações com base em resultados externos em múltiplas rodadas de execução.

Quando os alvos de execução eram ferramentas gratuitas ou sistemas internos empresariais, as permissões de invocação podiam ser pré-configuradas pelos desenvolvedores. Contudo, capacidades de alta qualidade em mercados abertos normalmente exigem pagamento: dados financeiros em tempo real têm preço por chamada, web scraping consome créditos, poder de inferência e GPU é cobrado por uso, e geração de vídeo e bancos de dados profissionais possuem preços definidos. Para que um agente inteligente conclua uma tarefa de forma independente, ele inevitavelmente deve se tornar um comprador em tempo de execução.

O modelo tradicional de negócios de API não foi concebido para esse tipo de comprador. Exige que uma pessoa visite primeiro um site, crie uma conta, vincule um cartão bancário, selecione um plano, proteja uma chave de API e insira essa chave no ambiente do programa. As decisões de compra e as invocações reais são divididas em dois momentos distintos: humanos realizam a compra antes da tarefa ocorrer, e o software só é responsável por consumir a cota já adquirida.

Um agente pode não saber o que precisa até atingir determinado passo na execução de uma tarefa. Não consegue prever antecipadamente qual fonte de dados chamará, nem deve exigir que o usuário crie contas individualmente para todos os serviços potenciais. Sua aquisição caracteriza-se por ser instantânea, de baixo valor, multi-mercador, de alta frequência e orientada a resultados. Para ele, a experiência mais natural não é “assinar primeiro, depois chamar”, mas sim “descobrir o serviço, obter cotação, autorizar pagamento, obter resultado.”

O Pagamento por Agente, portanto, não se trata apenas de adicionar um botão de pagamento a um chatbot. Significa que o software começa a ter autoridade limitada para gastar e forma um processo de aquisição pertencente às máquinas. Humanos definem objetivos, orçamentos e limites de risco, e os agentes alocam fundos dentro desses limites. Assim, o pagamento deixa de ser uma ação de liquidação para fazer parte do sistema de tomada de decisão do agente.

1. Por Que o Pagamento por Agente Se Tornará uma Trilha Independente

1.1 Da Invocação de Ferramentas à Ação Econômica

A diferença entre agentes e scripts de automação comuns não está apenas na capacidade de raciocínio. Scripts executam processos predeterminados, e os recursos e fornecedores necessários geralmente já estão codificados; agentes escolhem caminhos com base no ambiente. Na mesma tarefa de pesquisa, pode primeiro adquirir resultados de busca, decidir então, com base nesses resultados, se precisa de um banco de dados setorial e, por fim, chamar outro modelo para validação cruzada. Cada etapa de aquisição altera decisões subsequentes.

Esse modelo de “executar enquanto adquire” introduz escolhas econômicas no tempo de execução do software. Um agente deve não só avaliar se uma ferramenta está disponível, mas também se vale a pena comprá-la: se o preço excede o orçamento, se a velocidade de resposta atende aos requisitos da tarefa, se o histórico de entrega é confiável e se um serviço alternativo é mais adequado. O roteamento tradicional de ferramentas foca em correspondência de capacidades, enquanto a aquisição por máquinas deve lidar simultaneamente com preço e risco contratual. Nessas transações, quem assume o risco é o próprio agente: o pagamento pode ser bem-sucedido, mas o serviço pode não ser entregue.

Portanto, a necessidade central do Pagamento por Agente não é o pagamento automático incondicional, mas a delegação controlada de poder de compra ao software. Usuários não entregarão facilmente toda sua carteira a um agente, mas estarão dispostos a definir um orçamento de poucos dólares para uma tarefa clara, permitindo-lhe realizar várias compras de centavos. Autorizações maiores ainda exigirão construção prolongada de confiança, mas autorizações menores já geram valor real.

1.2 Micropagamentos, alta frequência e múltiplos comerciantes transformam a economia de pagamentos

A infraestrutura de pagamentos da internet humana é eficaz para transações de menor frequência e maior valor. Redes de cartões de crédito, gateways de pagamento e sistemas de assinatura possuem custos fixos, levando comerciantes a agrupar muitas chamadas em pacotes mensais. Para requisições de API que valem apenas alguns centavos, as taxas, o risco de estornos e os custos de manutenção de contas podem superar o valor dos próprios bens.

O consumo por máquinas é exatamente o oposto. Um agente pode iniciar múltiplas compras de diversos comerciantes em minutos para concluir um único entregável. O valor por transação é muito baixo, mas a frequência de chamadas é alta, e o número total de transações pode superar amplamente o dos consumidores humanos. Stablecoins e liquidação programável em cadeia oferecem uma nova base econômica para tais cenários: os fundos fluem 24/7, autorizações de pagamento podem ser assinadas por software e serviços podem ser precificados diretamente por chamada.

Mais importante ainda, a aquisição multi-comerciante mudará a forma como a concorrência opera no mercado de APIs. Modelos de assinatura incentivam usuários a permanecerem presos a um fornecedor por longo prazo, enquanto o pagamento por uso permite que agentes façam escolhas dinâmicas para cada tarefa. Prestadores de serviço não competem mais apenas por contratos anuais, mas também por necessidades momentâneas. Preço, desempenho e histórico de execução podem influenciar em tempo real os resultados de roteamento.

1.3 As stablecoins estão migrando de meio de troca para infraestrutura de liquidação

No início do mercado cripto, a demanda por stablecoins vinha principalmente de negociação e fuga de capital para ativos seguros. À medida que emissão, custódia, conformidade e infraestrutura cross-chain amadurecem, as stablecoins começam a entrar em liquidação transfronteiriça, gestão de tesouraria corporativa e pagamentos nativos da internet. Para pagamentos por máquinas, as stablecoins têm outra vantagem especial: são ao mesmo tempo moeda e ativo digital operável diretamente por programas.

Pagamentos com cartão de crédito dependem de identidade do portador, contas bancárias e redes geográficas. Os próprios agentes não possuem identidade de pessoa física e não conseguem passar independentemente pelos processos tradicionais de abertura de conta. Uma carteira com políticas restritivas, no entanto, pode se tornar a interface de financiamento do agente: o operador injeta saldo limitado, define limites por transação e por sessão, e mantém permissões de bloqueio e revogação; o agente apenas assina pagamentos dentro do escopo autorizado.

Isso não significa que pagamentos em cadeia sejam inerentemente superiores a todos os pagamentos tradicionais. Proteção ao consumidor, mecanismos de reembolso, privacidade, gerenciamento de chaves e responsabilidade regulatória ainda precisam ser resolvidos. Mas em pagamentos máquina-a-máquina, pagamento por uso de baixo valor e aquisição global de serviços, stablecoins programáveis têm clara compatibilidade. Pela primeira vez, permitem que 'chamar uma interface' e 'pagar uma interface' sejam comprimidos numa única interação de rede.

2. Infraestruturas de pagamento já surgiram: x402, MPP e transações nativas HTTP

2.1 Transformar o código de status 402 numa interface comercial

O HTTP reservou há muito tempo o código de status 402 (Pagamento Necessário), mas por quase 30 anos ele não formou um fluxo de trabalho geral. Protocolos de pagamento para máquinas reativaram esse significado: o cliente requisita um endpoint pago, o servidor retorna 402 com termos de pagamento legíveis por máquina; o cliente seleciona uma opção aceitável, conclui a assinatura ou o pagamento e tenta novamente a requisição com as credenciais.

A importância desse processo está em eliminar a página de cadastro humano. Descoberta de preços, exigências de pagamento e entrega de conteúdo ocorrem todas na camada de protocolo compreensível por programas. Para desenvolvedores, APIs pagas não precisam mais construir um portal SaaS completo em torno de contas, planos e chaves; para agentes, serviços podem ser descobertos como páginas web comuns e adquiridos quando realmente necessários.

O x402 é um dos protocolos abertos mais observados nesse caminho. Ele organiza desafios e credenciais de pagamento em torno do HTTP 402, permitindo que prestadores de serviço recebam pagamentos por requisição. O MPP, por sua vez, parte de um ecossistema distinto e explora métodos de pagamento orientados a máquinas, como cobrança e sessão. Embora suas concepções específicas difiram, ambos validam uma direção: pagamentos por máquinas podem fazer parte do protocolo de aplicação, sem exigir um processo de liquidação manual separado construído fora da aplicação.

2.2 A natureza duradoura da diversificação das infraestruturas de pagamento

O setor frequentemente espera que, eventualmente, reste apenas um protocolo-padrão, uma rede de liquidação e um esquema de pagamento. Mas, sob a perspectiva do comerciante, a diversificação tem fundamentação de longo prazo. Consultas pontuais de dados se adequam ao pagamento por chamada, enquanto serviços contínuos de inferência ou streaming podem ser melhores com cobrança por sessão; serviços de alto valor exigem garantias e tratamento de disputas mais robustos, enquanto chamadas de baixo valor priorizam velocidade e custo; diferentes regiões e empresas também escolherão redes de conformidade e liquidação distintas.

A camada de protocolo continuará inovando. Comerciantes podem adotar débito direto, pré-autorização, depósito em garantia, pagamentos contínuos ou liquidação em lote; redes podem fazer diferentes trade-offs entre custo, irrevogabilidade, liquidez e ferramentas de ecossistema. Para vendedores, isso representa liberdade de escolha. Para compradores, cada nova combinação adiciona outra superfície de integração.

A matriz de configuração abaixo é uma seção transversal dessa diversificação: protocolos/esquemas de pagamento formam as colunas, blockchains formam as linhas, e cada escolha é uma configuração de pagamento que exige integração separada — e essa tabela continua se expandindo.

Figura 1: Matriz de configuração de infraestruturas de pagamento sob fragmentação

Portanto, a fragmentação não desaparecerá necessariamente naturalmente à medida que o mercado amadurece. O mercado de cartões bancários não terminou com apenas uma organização de cartões após longo desenvolvimento, e a computação em nuvem não convergiu num único fornecedor. Mercados maduros normalmente não eliminam diferenças, mas sim formam camadas de agregação, roteamento e compensação sobre elas. Pagamentos por agentes provavelmente seguirão esse mesmo caminho evolutivo. Essa divisão já é mensurável. Dados de dois exploradores públicos (x402scan e mppscan) nos últimos 30 dias (até 3 de setembro de 2026) mostram: o protocolo MPP possui 65.591 carteiras ativas de compradores na cadeia Tempo, o x402 tem 19.472 na cadeia Base, e apenas 365 carteiras aparecem em ambas as infraestruturas — menos de 0,6% dos compradores do MPP e 2% dos compradores do x402 na Base; dessas, apenas 112 realizaram mais de dez transações em cada infraestrutura, e grande parte são agregadores de duas infraestruturas que pagam em nome de usuários com a mesma chave, e não compradores que adotaram uma segunda infraestrutura. Os compradores não migram entre infraestruturas; cada uma acumula sua própria base independente de compradores.

2.3 A adesão do vendedor representa apenas metade da transação

Os protocolos de pagamento reduzem inicialmente a barreira para que comerciantes aceitem pagamentos. Assim que um endpoint consegue publicar cotações, verificar credenciais e fornecer serviços, ele atende às condições básicas para o comércio voltado a máquinas. Um número crescente de ferramentas para desenvolvedores, serviços de dados e interfaces de conteúdo está, assim, se tornando comprável por máquinas.

No entanto, a disponibilidade de oferta pagável não significa que a demanda seguirá automaticamente. Comerciantes resolvem a questão 'como recebo pagamentos de máquinas', mas agentes ainda precisam responder 'de quem devo comprar, qual método de pagamento usar e como confirmar a entrega após o pagamento'. Se cada comprador tiver de integrar separadamente todos os protocolos, preparar fundos em redes distintas e manter livros-razões independentes, os pagamentos por máquinas repetirão a complexidade da integração inicial de APIs — trocando apenas chaves de API por carteiras e adaptadores de protocolo.

A adoção real depende do atrito total da transação, não apenas do atrito na etapa de liquidação.

3. O verdadeiro gargalo do setor: transações sem ciclo fechado

Figura 2: Processo completo de uma aquisição por máquina

3.1 Primeiro obstáculo: descobrir serviços compráveis

Agentes precisam de diretórios de serviços legíveis por máquinas. Um diretório eficaz não pode conter apenas nomes e URLs; deve também descrever capacidades do endpoint, entradas e saídas, unidades de precificação, protocolos disponíveis, latência, restrições geográficas e status de atualização. Também é necessário mapear intenções em linguagem natural para parâmetros de API; caso contrário, um agente sabe que 'precisa de dados macroeconômicos', mas não consegue identificar qual endpoint atende à tarefa.

Diretórios em mercados abertos enfrentam ainda problemas de duplicação, expiração e declarações falsas. Qualquer comerciante pode afirmar fornecer dados de alta qualidade, mas agentes não podem gastar dias realizando verificações de antecedentes como fazem profissionais humanos de compras. A camada de descoberta deve verificar continuamente se os endpoints são chamáveis, se as cotações são reais e se as descrições correspondem ao conteúdo retornado.

Isso torna a descoberta de serviços distinta da busca tradicional. Motores de busca otimizam para relevância da informação, enquanto diretórios de aquisição por máquinas devem também otimizar para negociação: compatibilidade das capacidades, aceitabilidade dos preços, compatibilidade dos pagamentos e capacidade de entrega dos comerciantes.

3.2 Segundo obstáculo: compreender e comparar cotações

Superficialmente, APIs semelhantes podem todas ser precificadas por chamada, mas, na prática, as cotações são fracamente comparáveis. Uma cobra por requisição, outra por item retornado; uma inclui inferência de modelo no preço, outra exige pagamento adicional; outros serviços faturam dinamicamente conforme comprimento da entrada, tempo de execução ou resultados bem-sucedidos.

Um agente não pode simplesmente escolher o endpoint com o menor preço nominal. Ele precisa considerar custo total, probabilidade de entrega, latência e qualidade do resultado. Se uma interface barata falhar repetidamente, os custos de repetição e os atrasos na tarefa podem tornar seu preço efetivo mais alto. As cotações devem, portanto, ser avaliadas juntamente com o nível de serviço, desempenho histórico e contexto da tarefa.

Cotações legíveis por máquinas também devem especificar períodos de validade e valores finais. Em um ambiente de precificação dinâmica, o que o agente assina deve ser um compromisso firme, não uma faixa de preços vaga. Os operadores também precisam conhecer a composição das taxas, incluindo tarifas de serviço, custos de rede e taxas de roteamento, para definir orçamentos confiáveis.

3.3 Terceiro portão: distribuição de fundos e liquidez entre redes

Se um agente precisar adquirir serviços simultaneamente em múltiplas blockchains e múltiplos protocolos, a abordagem mais direta é pré-financiar saldos em cada rede. Contudo, isso fragmenta um pequeno montante de capital em muitas partes. Fundos ficam ociosos em redes não utilizadas no momento, enquanto redes populares podem ficar com saldo insuficiente; recarregar saldos envolve pontes, conversões, taxas de gás e operações de segurança.

Para um único usuário, isso já é trabalhoso. Para uma empresa que gerencia grande número de agentes, o problema se amplifica: quanto saldo cada agente deve manter, quem é responsável pela recarga, como evitar uso indevido de fundos e como agregar ativos e taxas entre redes diferentes? Sem uma camada unificada de financiamento, quanto mais vias de pagamento existirem, maior será a complexidade financeira.

Idealmente, o que um agente vê é um único orçamento utilizável, não múltiplos saldos por rede. O sistema subjacente lida com a seleção de rotas de liquidação, gestão de liquidez e fornecimento de cotações transparentes. O princípio é semelhante ao de um viajante usando um único cartão para gastar em diferentes países: o usuário se importa com o limite total de crédito e com a taxa de câmbio, sem precisar abrir previamente uma conta local em cada destino.

3.4 Quarto portão: autorização baseada em políticas

A preocupação mais facilmente despertada por pagamentos autônomos é se um agente gastará sem controle. A solução não é simplesmente escolher entre 'proibição total' e 'autorização total', mas estabelecer políticas em múltiplas camadas.

Limites por transação reduzem perdas decorrentes de um único erro, orçamentos por sessão limitam o gasto total de uma tarefa, listas brancas ou pretas de comerciantes controlam contrapartes, regras por categoria restringem o que pode ser comprado e limites de taxa evitam chamadas anormais em curto período. Transações de alto risco ou alto valor também podem acionar confirmação manual. As políticas devem ser definidas pelos operadores, e os agentes só podem agir dentro desses limites — não podem elevar os limites por conta própria.

Uma carteira também não deve apenas lidar com assinaturas. Ela precisa ser integrada a tarefas, identidade e registros de auditoria para responder à pergunta: «qual agente aprovou este pagamento, para qual tarefa e sob qual política?». Caso contrário, a empresa acaba apenas com uma sequência de hashes de transações em cadeia, incapazes de atender aos requisitos de controles internos e atribuição de custos.

3.5 Etapa Cinco: Liquidação Bem-Sucedida Não Equivale à Entrega do Serviço

Blockchain é excelente para provar que fundos foram transferidos de um endereço para outro, mas não pode, por natureza, comprovar que uma API retornou o conteúdo correto. Uma transação pode concluir sua liquidação, mas o servidor pode expirar, retornar um status de erro ou entregar dados que não correspondem ao anunciado. Para agentes, isso não é um caso raro — é o cerne do risco de aquisição.

O comércio eletrônico tradicional conecta pagamento e entrega por meio de logística, avaliações e reembolsos; serviços máquinas não têm logística física — a entrega pode ser simplesmente uma resposta HTTP transitória. Se os sistemas de pagamento registram apenas a trajetória dos fundos e os comerciantes registram apenas suas próprias respostas, o mercado carece de uma visão unificada de execução que abranja comerciantes e protocolos.

O que exige cautela é que registrar uma resposta não equivale a comprovar sua qualidade. Contudo, correlacionar pagamento com resposta permite, ao menos, distinguir estados básicos como «pago e resultado recebido», «pago, mas serviço falhou» e «não liquidado». Essa é a primeira camada de fatos para construir credibilidade nas transações máquinas.

3.6 Etapa Seis: Conciliação Unificada e Definição de Responsabilidades

Uma única tarefa pode envolver dezenas de microcompras. Se cada transação estiver espalhada por diferentes carteiras, protocolos e back-ends de comerciantes, será difícil para os usuários entenderem por que o produto final custou o valor cobrado. As empresas também precisam atribuir despesas a projetos, equipes, clientes e centros de custo, além de manter evidências auditáveis.

Um livro-razão unificado deve registrar simultaneamente a intenção de aquisição, comerciantes, cotações, políticas de autorização, resultados de liquidação, status da resposta e motivos de falha. Ele serve não apenas à área financeira, mas também à otimização de agentes. O sistema pode analisar quais fontes de dados falham com frequência, quais rotas são mais caras e qual é a combinação típica de aquisições para um dado tipo de tarefa.

Quando o pagamento está embutido na cadeia de raciocínio, o custo torna-se um sinal de retroalimentação para decisões do modelo. Sem conciliação unificada, os agentes só conseguem otimizar respostas, não o processo econômico de obtê-las. Grande parte do valor de longo prazo do Pagamento por Agentes vem exatamente dessa observabilidade.

4. Do Protocolo de Pagamento à Camada de Aquisição Máquina

4.1 A Abstração Central do Futuro Não É «Pagar», Mas «Comprar»

Pagar é uma ação executada após a definição clara do objeto e do preço, enquanto a aquisição abrange todo o processo, da demanda à aceitação. Expor uma função pay() a um agente permite apenas transferir fundos para um endereço conhecido; expor uma capacidade buy() significa que o sistema pode receber a demanda, descobrir serviços, comparar opções, executar o pagamento e retornar resultados verificáveis.

Essa distinção define a divisão de trabalho no setor. Protocolos fornecem mensagens padronizadas de pagamento, carteiras gerenciam assinaturas e ativos, redes de liquidação movem valor, diretórios agregam oferta e a camada de aquisição organiza esses componentes em uma única tarefa. Qualquer componente isolado é importante, mas nenhum representa sozinho uma transação completa.

A camada de aquisição máquinas deve permanecer aberta. Não deve exigir que todos os comerciantes migrem para o mesmo protocolo, nem determinar quem pode ser adquirido por meio de um diretório fechado. Um modelo mais sustentável é ser compatível com múltiplas vias de pagamento, divulgar custos de roteamento nas cotações e permitir que agentes escolham autonomamente com base em políticas.

4.2 A agregação de compradores pode ser mais importante que a agregação de vendedores

Plataformas da internet normalmente agregam primeiro a oferta e depois atraem consumidores. Nos mercados máquinas, a oferta já existe amplamente na forma de APIs; o que falta é um comprador padronizado capaz de realizar compras contínuas. Um agente equipado pode transformar demandas fragmentadas e ocasionais em um fluxo estável de transações.

A agregação de compradores também melhora a visibilidade de serviços de nicho. Desenvolvedores humanos tendem a usar grandes marcas conhecidas porque o custo de tempo para avaliar novos fornecedores é alto; se agentes puderem ler sinais padronizados de capacidade, preço e execução, poderão escolher serviços mais adequados para cada tarefa. Isso pode reduzir os custos de aquisição de clientes para novos comerciantes e também forçar comerciantes estabelecidos a competirem com base no desempenho real.

Contudo, os pontos de entrada para compradores também podem criar novo poder de plataforma. Quem controla o diretório padrão, a classificação e os caminhos de pagamento pode influenciar a alocação de tráfego. Portanto, o setor precisa de regras de classificação transparentes, taxas explicáveis e registros de transações portáteis. A agregação pode reduzir fricções, mas não deve transformar protocolos abertos em canais fechados.

4.3 Construindo reputação com base em dados reais de transações

Compradores máquinas tomam decisões muito rapidamente e não podem confiar em diligências extensas. Eles precisam de sinais sobre as contrapartes no mesmo momento em que aparece uma cotação. Avaliações tradicionais e comentários de usuários podem servir de referência, mas são facilmente manipuláveis por volume falso, contas sybil e partes relacionadas. Se as avaliações não exigirem pagamento real, o custo de ataque é especialmente baixo. Pesquisas empíricas recentes sobre o ERC-8004 — a primeira camada de confiança em cadeia sem permissão para agentes — confirmam isso [6]. A especificação do protocolo afirma textualmente que «pagamentos são ortogonais a este protocolo» — avaliações, por padrão, não precisam estar vinculadas a nenhuma transação paga real, e a prova de pagamento é apenas um campo opcional. O resultado é: na Ethereum, BSC e Base (até 13 de maio de 2026), respectivamente, 73,5%, 59,2% e 90,6% dos avaliadores exibiram comportamento sybil coordenado.

Uma base mais confiável são registros de resultados vinculados a chamadas reais pagas: quantos acordos um ponto final de serviço concluiu, qual é a taxa de sucesso das respostas, qual é a latência comum e quão alta é a proporção de ausência de resposta após o pagamento. Essas métricas ainda não conseguem representar plenamente a qualidade do conteúdo, mas estão mais próximas de fatos verificáveis do que declarações autodeclaradas.

À medida que os dados se acumulam, o mercado pode desenvolver uma reputação em níveis: o primeiro nível é o status objetivo da transação, o segundo é métricas de serviço reproduzíveis e o terceiro é avaliação de qualidade para tarefas específicas. Agentes podem escolher a robustez necessária das provas conforme valor e risco: alguns centavos para uma consulta de dados podem depender de sinais estatísticos, enquanto compras de alto valor exigem garantias, auditorias ou resolução de disputas.

4.4 A estratégia orçamentária tornar-se-á uma capacidade importante para agentes

Atualmente, os agentes são avaliados principalmente pela qualidade das respostas, taxa de conclusão de tarefas e precisão nas chamadas de ferramentas. Ao entrarem em ambientes pagos, métricas econômicas devem ser acrescentadas: quanto é gasto para atingir a mesma qualidade, se a tarefa é concluída dentro do orçamento, quando vale a pena adquirir dados mais caros e como equilibrar velocidade, custo e confiabilidade.

Isso criará novas direções para treinamento e avaliação. Os agentes não aprenderão apenas «qual ferramenta responde à pergunta», mas também «se comprar essa ferramenta é vantajoso, dada a importância da tarefa atual». Podem usar primeiramente serviços de baixo custo para filtragem e depois adquirir verificação de alta qualidade para conclusões-chave; também podem reduzir a frequência de chamadas ao se aproximar do esgotamento do orçamento ou solicitar autorização adicional do usuário.

Nesse sentido, o Pagamento por Agente não é um plug-in financeiro externo às capacidades do modelo, mas parte da inteligência decisória. Um agente verdadeiramente maduro deve não só usar recursos, mas também precificá-los.

5. Possíveis caminhos evolutivos para o Pagamento por Agente

5.1 Fase um: ferramentas para desenvolvedores e serviços digitais lideram o caminho

Os primeiros cenários em larga escala provavelmente continuarão sendo entregas puramente digitais, como busca, dados, raspagem por proxy, inferência de modelos, execução de código, armazenamento e geração de conteúdo. Esses serviços já são fornecidos via APIs, têm baixos custos marginais de entrega, permitem pagamento e resposta na mesma sessão de rede e não envolvem logística complexa.

Os valores típicos nesta fase são muito pequenos, e os usuários priorizam conveniência no desenvolvimento e taxa de conclusão de tarefas. O mercado validará rapidamente os protocolos, mas o volume de transações pode ser altamente fragmentado. Muitas chamadas ainda serão tratadas por chaves de API tradicionais e assinaturas, com pagamentos automatizados usados mais para necessidades temporárias, compras entre fornecedores distintos e serviços de nicho que não podem ser pré-habilitados como contas.

5.2 Fase dois: orçamentos corporativos e colaboração entre múltiplos agentes

Quando as empresas começarem a implantar múltiplos agentes, a gestão de fundos evoluirá de carteiras individuais para sistemas de contas em nível organizacional. As empresas precisarão alocar orçamentos a diferentes papéis, controlar categorias compráveis, definir limites de aprovação e registrar despesas nos sistemas financeiros. Também poderá surgir liquidação interna entre agentes: agentes de pesquisa compram dados, agentes de análise adquirem poder computacional e agentes de execução chamam serviços externos.

Neste estágio, segurança e conformidade tornam-se mais importantes do que a novidade do pagamento. As empresas valorizam a custódia de chaves, isolamento de permissões, monitoramento de transações, avaliação de fornecedores e rastreabilidade auditável. Apenas infraestruturas capazes de integrar-se aos processos financeiros existentes poderão migrar da fase experimental para a produção.

5.3 Fase três: expansão de serviços digitais para a economia real

Passagens aéreas, hotéis, logística, publicidade e serviços profissionais podem todos se tornar alvos de aquisição por agentes, mas transações no mundo real exigem identidade, reembolsos, impostos e resolução de disputas mais complexos. Estáveis (stablecoins) resolvem apenas parcialmente o problema de liquidação; não substituem direitos do consumidor nem contratos comerciais.

Portanto, o setor não deve interpretar erroneamente «pagamentos autônomos» como eliminação de todos os intermediários. Pelo contrário, à medida que o valor das transações aumenta, garantias, seguros, crédito e arbitragem reaparecerão — simplesmente precisam ser transformados em serviços invocáveis por máquinas. A futura pilha de Pagamento por Agente poderá incluir simultaneamente protocolos abertos de pagamento e conectividade com finanças tradicionais, em vez de um caminho substituir o outro.

5.4 Fase quatro: do roteamento entre protocolos à execução entre mercados

A longo prazo, o que os agentes adquirem não é apenas uma resposta de API, mas um resultado. Um usuário pode solicitar «gerar um relatório setorial confiável», e o sistema combinará autonomamente buscas, bancos de dados, tradução, modelos e serviços de verificação. Múltiplas transações ocorrem na camada inferior, enquanto o usuário vê apenas o orçamento total, fontes de evidência e entrega final.

Isso elevará o roteamento de pagamentos à execução de mercado. O sistema precisa decompor metas complexas em portfólios de aquisição, substituir dinamicamente fornecedores falhos e otimizar entre custo total e qualidade. A compatibilidade de protocolos é apenas a base; a verdadeira vantagem competitiva vem da compreensão da demanda, dados transacionais e feedback de execução.

6. Riscos e questões em aberto

Pagamentos por agentes têm enorme potencial imaginativo, mas restrições do mundo real não podem ser ignoradas. A primeira é a segurança. Injeções de prompts poderiam levar agentes a adquirir serviços maliciosos; ataques à cadeia de suprimentos poderiam substituir endereços de recebimento; e políticas defeituosas poderiam causar pagamentos duplicados em larga escala. As ações de pagamento devem ser isoladas de conteúdos não confiáveis e dotadas de limites, simulação, revogação e detecção de anomalias.

A segunda é a privacidade. Registros de compras revelam quais tarefas um agente está executando, e dados públicos em blockchain poderiam vincular identidade do usuário à intenção comercial. Os sistemas precisam minimizar vazamentos de metadados sensíveis e equilibrar exigências de auditoria com a privacidade.

A terceira é a responsabilidade. Quando um agente efetua uma compra errônea, um comerciante falha na entrega ou uma conversão de protocolo falha, quem deve arcar com a perda? Transações de baixo valor podem aceitar risco automatizado, mas transações de alto valor exigem limites claros de responsabilidade. Uma rede de pagamentos sem mecanismo de disputa terá dificuldade para ingressar diretamente no comércio de alto valor.

A quarta é a regulação. Emissão de stablecoins, controles de carteira, transferências transfronteiriças e pagamentos a comerciantes estão sujeitos a regras distintas em várias jurisdições. Máquinas são executoras, não sujeitos de responsabilidade legal. A infraestrutura deve ser capaz de rastrear cada transação autônoma até um operador claro, uma política de autorização e uma fonte de fundos.

A quinta é a sustentabilidade comercial. A receita de micropagamentos é facilmente corroída por custos de rede, liquidez e taxas de controle de risco. Se plataformas subsidiarem a experiência por meio de markup oculto, minam a confiança dos compradores. As taxas devem ser transparentes, e um modelo de negócios sólido deve ser construído por meio de escala, eficiência de roteamento e serviços de valor agregado.

Esses problemas não invalidam o setor; ao contrário, mostram que os Pagamentos por Agentes não serão concluídos por um único protocolo. Tornar-se-ão, no final, infraestrutura composta para pagamentos, identidade, permissões, descoberta, reputação e conciliação.

7. SELAT: Equipando o lado da compra para o comércio nativo de máquinas

'SELAT' vem da palavra malaia para 'estreito', como o Estreito de Malaca (Selat Melaka). Por séculos, independentemente da origem das mercadorias ou do destino final, a corrente principal do comércio Leste-Oeste passou por essa via aquática. O SELAT visa tornar-se esse estreito no comércio nativo de máquinas: não importa em qual via ferroviária um comerciante esteja ancorado, a demanda dos agentes pode fluir por aqui.

O SELAT é uma empresa nativa de IA que opta por entrar no mercado de pagamentos por máquinas pelo lado da compra. É a camada do lado da compra para o comércio nativo de máquinas. Seu objetivo central não é criar mais uma via de pagamento que exija migração de comerciantes, mas permitir que agentes realizem compras através de vias existentes. Concentra-se em dois problemas centrais: primeiro, a fragmentação das configurações de pagamento, onde vias, protocolos, blockchains e credenciais diferem, exigindo nova integração para cada comerciante; segundo, a ausência de medição do risco contratual, pois liquidação bem-sucedida não significa que o serviço foi entregue.

Figura 3: Diagrama esquemático da camada do lado da compra SELAT

Para enfrentar a fragmentação, a CLI SELAT mantém as diferenças entre protocolos, esquemas de pagamento e redes de liquidação na camada de infraestrutura, permitindo que agentes realizem compras inter-vias com um único comando. Descoberta, cotação, autorização, pagamento, registros de status de entrega e conciliação são todos incorporados ao mesmo processo de compra, e cada chamada também é registrada no mesmo livro-razão.

• Um tesouro, usando N vias de pagamento

Agentes mantêm um saldo em USDC sob custódia própria, sem necessidade de pré-financiamento por blockchain nem de manter clientes distintos para diferentes protocolos.

• Catálogo agregado de endpoints

A CLI SELAT integra quatro registros de serviços de terceiros — Circle, MPP, Apify e pay.sh — além do próprio catálogo SELAT, permitindo que agentes descubram e comparem mais de 4.000 endpoints de serviço com base na intenção em tempo real.

• Limites rígidos de gastos

Operadores podem definir limites por transação e orçamentos por sessão, além de congelar permissões de gasto a qualquer momento; agentes não podem elevar esses limites por conta própria.

• Sem migração de comerciantes

Comerciantes podem manter suas vias de pagamento preferidas e ser descobertos e comprados por agentes sem precisar se registrar novamente no SELAT.

No lado do financiamento, o SELAT opera com qualquer carteira de agente, incluindo carteiras de agentes Circle e MetaMask. O SELAT roteia cada compra por vias de pagamento como x402 e MPP, conforme cotações em tempo real.

7.1 ERC-8004: Primitivos Corretos, Sinais Questionáveis

O ERC-8004 define três tipos de registros — identidade, reputação e validação — e permite que compradores enviem avaliações a vendedores. A direção está correta, mas separa explicitamente pagamento de reputação: o feedback não precisa vir de transações reais, e anexar prova de pagamento é opcional.

Pesquisas empíricas no ecossistema implantado mostram que, na Base, 93,8% dos avaliadores nunca realizaram um pagamento x402, mas contribuíram com 94,9% do feedback; grande parte desse feedback também exibe comportamento coordenado de sybil [6]. Os registros armazenam afirmações, mas o que os compradores realmente precisam são resultados.

7.2 Reputação Vinculada a Dados Reais de Transação É o Que os Compradores Precisam

As infraestruturas de pagamento podem confirmar se os fundos foram liquidados, mas não conseguem ver o que o serviço retornou; os comerciantes veem suas próprias respostas, mas não enxergam o mercado inteiro; os registros listam endpoints, mas não provam que as avaliações vieram de compras reais.

A camada de comprador que executa as aquisições está melhor posicionada para conectar ambas as pontas da transação: toda compra concluída via SELAT registra qual endpoint foi pago, quanto foi liquidado e metadados sobre o status da entrega pós-pagamento (2xx, 4xx, 5xx). Esses registros acumulam-se continuamente por comerciante e infraestrutura de pagamento, formando a base de dados do «Grafo Liquidação–Entrega».

É necessária uma distinção precisa: registros que vinculam pagamento e status de entrega não equivalem à prova independente de qualidade da entrega ou exatidão da cotação. Contudo, fornecem a base que a reputação baseada em registros carece — dados de resultado vinculados a invocações pagas de fato.

7.3 Obtenção de Credibilidade da Contraparte Antes das Transações

Enquanto pessoas discutiam no X como projetar um mecanismo de confiança tipo Google PageRank para a quarta geração da internet, o SELAT já havia lançado o «Índice de Transacionabilidade» sobre seu grafo liquidação–entrega, visando oferecer aos agentes acesso em tempo de execução a dados de credibilidade da contraparte respaldados por resultados reais de transações.

O índice é retornado junto às cotações, sem exigir que os agentes interrompam suas tarefas para investigar separadamente os comerciantes. Ele sinaliza riscos sem criar barreiras ao mercado: endpoints ainda podem ser descobertos e adquiridos, e os agentes tomam decisões com base em orçamento, importância da tarefa e tolerância ao risco.

Agentes não têm tempo para ler histórias de marcas. Eles precisam saber antes de pagar: como esse endpoint se comporta em transações reais? A credibilidade no comércio nativo de máquinas não deve vir de afirmações, mas de resultados.

Figura 3: Sinais de Transacionabilidade na Etapa de Cotação

Atualmente, a CLI do SELAT foi adaptada para ambientes de execução de agentes, incluindo Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes e Grok Bot.

8. Resumo: A Economia de Máquinas Precisa de Mais do Que Apenas Infraestruturas de Pagamento Mais Rápidas

O Pagamento por Agente está numa fase em que é facilmente superestimado e facilmente subestimado. É superestimado porque concluir tecnicamente um pagamento em stablecoin não significa que o agente tenha autonomia comercial madura; é subestimado porque, assim que o software puder adquirir capacidades externas sob restrições claras, os métodos organizacionais, modelos de precificação e fronteiras competitivas da economia de máquinas mudarão inteiramente.

Os protocolos de pagamento já provaram que máquinas podem receber cotações e concluir liquidações. O próximo passo-chave é expandir um pagamento isolado para uma aquisição completa: permitir que agentes encontrem serviços adequados, compreendam custos reais, paguem entre diferentes infraestruturas dentro do orçamento, confirmem a entrega e transformem cada transação num registro auditável e aprendível.

A futura economia de máquinas não terá apenas uma blockchain, um protocolo ou uma carteira. A oferta multicentralizada persistirá a longo prazo, e a infraestrutura verdadeiramente valiosa ajudará os compradores a navegar nessa complexidade. O Pagamento por Agente precisa integrar infraestruturas de pagamento, oferta, pagamentos padrão e mecanismos de confiança para converter capacidade técnica em demanda real.

Quando o software começa a agir como comprador, o pagamento é apenas o primeiro passo que ele dá. A pergunta mais importante sempre foi: será capaz de concluir uma transação genuinamente útil de maneira controlável, transparente e verificável?

Referências

[1] Circle, «Construindo a Economia Aberta de Agentes», 2026. https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT, «Risco de contraparte em pagamentos agênticos: a metade não medida», 2026. https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud, «Impulsionando o comércio por IA com o novo Protocolo de Pagamentos para Agentes (AP2)», 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] Fundação x402, «x402: Um padrão aberto de pagamento nativo da internet». https://github.com/x402-foundation/x402

[5] Protocolo de Pagamentos por Máquina, «MPP: Um protocolo de pagamento por máquina baseado no HTTP 402». https://mpp.dev/

[6] Xiong et al., «Agentes sem confiança podem ser confiáveis? Um estudo empírico do ecossistema descentralizado de agentes de IA ERC-8004», arXiv, 2026. https://arxiv.org/abs/2606.26028

[7] Site oficial da SELAT: https://www.selat.ai

Este artigo é uma contribuição e não representa as opiniões da BlockBeats.