O agente de IA usará cartão bancário? Por que o Pagamento Agentic não pode evitar as stablecoins e a blockchain

Autor: Yokiiiya

Na semana passada, participei no Web3 Festival em Hong Kong, e uma sensação muito clara foi: atualmente, quase todos os fóruns, cada painel, giram em torno de IA.

Não importa se o tema original era pagamento, stablecoins, RWA, carteiras, exchanges, ou conformidade e infraestrutura, no final quase sempre regressamos à mesma questão: quando a IA deixa de ser apenas geradora de conteúdo, e começa a executar tarefas, invocar serviços, tomar decisões, e até gerir fluxos de fundos, os sistemas financeiros e de pagamento atuais ainda são suficientes?

Num painel em que participei, alguém também lançou uma questão direta: o Web3 está a aproveitar-se da IA? Eu acho que não. Claro que há projetos que aproveitam a tendência. Mas se apenas interpretarmos IA × Web3 como uma narrativa de colagem, podemos estar a perder uma mudança mais profunda: a IA fica responsável por entender, decidir e agir, enquanto o Web3 fornece ativos, contas, liquidação e ambientes de execução verificáveis. Não são conceitos simplesmente sobrepostos, mas uma nova divisão de tarefas.

O Chefe do Departamento de Finanças de Hong Kong, Paul Chan, também mencionou no discurso do Web3 Festival 2026 que, no futuro, agentes de IA irão analisar informações a velocidade de máquina e agir, aproveitando ao máximo a infraestrutura blockchain em segundo plano, para aumentar a eficiência das transações e remodelar cenários como finanças, comércio, gestão de património, cadeias de abastecimento e logística. Quando a IA começa a agir, o problema deixa de ser apenas a “inteligência” em si, e passa a ser: como é que essas ações são autorizadas, liquidadas, registadas e responsabilizadas.

Entre os tópicos cada vez mais relevantes está o Agentic Payment. Mas, no início, tinha uma dúvida simples: por que é que, ao falar de Agentic Payment ou Agentic Commerce, parece-se sempre a assumir que estão automaticamente ligados a Crypto, Stablecoins, Blockchain?

A IA Agent não pode usar um cartão bancário? Não pode usar um cartão de crédito? Não pode usar Apple Pay, Visa, Mastercard, Stripe, PayPal?

Se o Agent apenas ajuda a comprar uma passagem, reservar um hotel, renovar um SaaS, teoricamente pode invocar os sistemas de pagamento existentes. Uma autorização do utilizador, o Agent executa o pagamento dentro de limites e regras, por trás podem estar cartões bancários, cartões virtuais, contas empresariais ou carteiras de pagamento de terceiros, e nada parece de todo estranho.

Logo, a questão não é “é possível usar cartão bancário”. Claro que sim. A verdadeira questão é: em que parte do Agentic Payment os cartões bancários e de crédito são adequados, e em que parte não conseguem resolver? O IA Agent usará mesmo cartões bancários? E por que, ao evoluir o Agentic Payment, quase inevitavelmente, surge a necessidade de stablecoins e blockchain?

1. Os cartões resolvem o checkout, não a Agent Economy

Se o Agentic Payment apenas ajuda a completar a última etapa de pagamento, como comprar uma passagem, reservar um hotel, renovar um SaaS, usar cartões bancários, cartões de crédito, cartões virtuais, Apple Pay, Stripe, PayPal, não há obstáculos essenciais. Podem ser usados, sem dúvida.

O utilizador autoriza previamente, o Agent executa o pagamento dentro de limites e regras. Não é uma ideia difícil de entender, é como uma versão mais inteligente de débito automático, cartões virtuais empresariais, cartões de viagem ou sistemas de compras automáticas.

Assim, os tradicionais players de pagamento como Visa, Mastercard, Stripe, não vão desaparecer. Pelo contrário, podem até ser uma porta de entrada importante para o early stage do Agentic Commerce.

O protocolo Machine Payments, lançado pela Stripe e Tempo, ilustra bem isto. Não é apenas sobre stablecoins, mas permite que comerciantes aceitem pagamentos diretamente de agents, suportando stablecoins, cartões, BNPL e outros métodos de pagamento fiduciário. Ou seja, na fase inicial do agent payment, a coexistência de pagamentos tradicionais e stablecoins é mais provável do que uma substituição imediata. Mas isto resolve apenas uma parte do checkout.

O checkout pressupõe que produtos, comerciantes, pedidos, botões de pagamento, processos de reembolso e resolução de disputas já estejam estabelecidos. O Agent apenas fica ao lado do utilizador, ajudando-o a automatizar uma compra.

O verdadeiro desafio surge em cenários diferentes: o Agent não entra apenas numa cesta de compras já preparada, mas continua a invocar recursos, combinar serviços e completar tarefas na rede aberta.

Por exemplo, um AI research agent para um relatório de setor pode precisar de consultar múltiplas bases de dados, comprar várias fontes pagas, aceder a APIs de modelos, invocar um crawler, pagar por ferramentas de geração de gráficos, ou até comprar uma análise de outro Agent. Pode não haver uma “loja” tradicional, nem uma página de checkout completa. Pode estar a lidar com APIs, interfaces de dados, serviços de modelos, nodos de computação, recursos de conteúdo, ferramentas automatizadas, ou até outro Agent.

Recentemente, encontrei um exemplo concreto: quero criar um assistente de análise de tráfego, que possa, quando necessário, invocar fontes de dados como Semrush, para analisar tráfego, palavras-chave, concorrentes e tendências de mercado. Mas, ao estruturar a solução, percebi que o problema não era “se a IA consegue analisar”, mas “como ela consegue aceder aos dados”. Muitas fontes comerciais não são desenhadas para chamadas pontuais, pagamento por uso, resposta instantânea. Por exemplo, a API do Semrush funciona com contas, pacotes e unidades de API. Cada pedido consome unidades, e o utilizador precisa de ter acesso à API ou comprar um pacote. Mesmo a API Trends, que pode ser adquirida separadamente, funciona com unidades de API.

Para um Agent, este modelo não é natural. Se precisa apenas de consultar dados de tráfego ocasionalmente, o que realmente quer não é criar uma conta SaaS, nem comprar um pacote completo de unidades, mas fazer uma requisição como uma página web: quanto custa? Tenho autorização para comprar? Se estiver dentro do orçamento, pago, e recebo o resultado imediatamente.

Este é o fosso entre Agentic Payment e o modelo tradicional de APIs. Hoje, muitas APIs cobram por “software para humanos”, não por “recursos sob demanda para máquinas”.

Assim, o problema do Agentic Payment não é apenas a última etapa de débito, mas toda a cadeia de tarefas: como é que a máquina mantém autorização contínua, inicia pagamentos, verifica entregas, conclui liquidações.

Aqui é que o sistema de cartões entra na sua fronteira.

Não porque seja atrasado, mas porque foi desenhado para cenários de consumo humano: uma pessoa entra numa loja, escolhe produto, confirma pedido, paga, e depois o banco, a rede de cartões, o adquirente e o processador cuidam da autorização, liquidação, risco e disputas.

Mas a Agent Economy enfrenta outro conjunto de problemas: por que é que o Agent tem direito de gastar esse dinheiro? Como é que o serviço confirma que não é um bot malicioso, mas uma extensão da intenção real do utilizador? Pode o Agent pagar pequenas quantias, de forma frequente, sem intervenção humana? Quando o pagamento é feito, o serviço pode libertar imediatamente o recurso? Se o Agent comprar errado, ultrapassar limites, for atacado, quem é responsável?

Por isso, quando a Google lançou o AP2, não focou na “forma de pagamento”, mas numa estrutura de confiança mais geral para Agentic Payment. O AP2 é definido como um framework agnóstico de pagamento, que permite aos utilizadores, comerciantes e provedores de pagamento fazerem pagamentos liderados por Agent com maior confiança, independentemente do método. A especificação do AP2 exige uma forma segura e simples de obter permissões limitadas, que o Agent usa para agir em nome do utilizador; a segurança do protocolo depende de assinaturas criptográficas por parte do utilizador e do comerciante.

Assim, o primeiro problema do Agentic Payment não é: de onde vem o dinheiro? Mas: por que é que o Agent tem direito de gastar esse dinheiro?

Este problema, o sistema de cartões consegue resolver parcialmente. Como cartões virtuais, credenciais tokenizadas, gestão de limites, controlo de despesas empresariais, regras de risco, tudo permite que o Agent realize transações dentro do sistema atual de comerciantes.

A Visa também avança nesta direção. O seu protocolo Trusted Agent e a iniciativa Intelligent Commerce visam fazer com que os AI Agents sejam reconhecidos, confiáveis e autorizados a representar consumidores ou empresas na rede de comerciantes. A descrição do Trusted Agent na plataforma Visa Developer é direta: agentes ajudam os utilizadores a navegar em sites de comerciantes, descobrir produtos, comparar preços e fazer escolhas, antes mesmo do checkout; estes acessos automáticos muitas vezes são confundidos com bots e bloqueados por serviços de mitigação.

Isto mostra que as redes de pagamento tradicionais também percebem o mesmo problema: Agentic Commerce não acontece apenas no momento do pagamento, mas ao longo de toda a cadeia — pesquisa, comparação, autorização, pagamento final. Mas as redes de cartões são melhores em resolver como um Agent entra na cadeia de comércio existente e realiza uma transação autorizada. Não resolvem naturalmente como um Agent, na rede aberta, pode fazer pagamentos pequenos, contínuos, a APIs, dados, modelos, recursos de computação, conteúdo, ou outro Agent.

Por isso, cartões não são impossíveis. Mais precisamente, eles resolvem o checkout do Agentic Commerce, mas o que o Agent Economy precisa é de um protocolo de pagamento mais profundo.

E aí surge a questão seguinte: se o objeto da transação não é um comerciante tradicional, mas uma API, um modelo, uma interface de dados, ou outro Agent, como é que as máquinas podem iniciar e concluir um pagamento? É por isso que protocolos como o x402, L402, T402 começam a ser discutidos.

2. O que o Agent realmente precisa é de um protocolo de pagamento legível por máquinas

Se o objeto da transação é um comerciante tradicional, o Agent pode usar o fluxo de checkout existente, com cartões, carteiras ou pagamentos virtuais. Mas se o objeto é uma API, um modelo, uma interface de dados, ou outro Agent, a questão muda.

Neste caso, o que as máquinas precisam não é de um “botão de pagamento”, mas de uma sequência de pagamento que possam entender: o Agent solicita um recurso. O serviço responde: este recurso requer pagamento, qual o preço, qual o endereço de pagamento, quais os métodos suportados. O Agent avalia se a compra está autorizada pelo utilizador. Se sim, paga. O serviço verifica o pagamento e liberta o recurso imediatamente.

Este fluxo parece simples, mas na verdade preenche uma camada que o internet sempre deixou de fora: a camada de pagamento nativa. Antes, a internet suportava naturalmente o fluxo de informação: páginas, emails, APIs, downloads. Mas “pagamento” não fazia parte do protocolo da internet, era uma funcionalidade externa: criar contas, ligar cartões, integrar gateways, comprar pacotes, gerir chaves API, fazer reconciliações.

Para as pessoas, isso é tolerável. Podem criar contas, fazer login, ligar cartões, aprovar compras, reembolsar. Mas para as Agents, este processo é demasiado pesado.

Um Agent não deve precisar de criar uma conta para cada API que invoca, nem comprar um pacote de unidades de API para cada consulta. Não deve precisar de passar por um processo completo de pagamento e compra por cada pequena chamada de alguns cêntimos ou euros. É por isso que surgem protocolos como o x402.

O x402 reativa o código de estado HTTP 402 Payment Required, que há muito existe, mas raramente foi usado. Permite que o serviço diga ao cliente na camada HTTP: “precisa pagar antes de aceder a este recurso”. O cliente pode ser uma pessoa ou uma máquina. Depois do pagamento, o serviço verifica e devolve o recurso, conteúdo ou serviço digital.

A definição do Coinbase para o x402 é direta: é um protocolo aberto que permite pagamentos instantâneos e automáticos com stablecoins via HTTP, para que clientes humanos ou máquinas possam pagar programaticamente e obter acesso sem precisar de contas, sessões ou autenticação complexa.

O que importa aqui não é “usar Coinbase” ou “usar USDC”. O que importa é que o x402 integra o pagamento na própria requisição-resposta da internet.

Antes, era:

• criar conta
• comprar pacote
• obter API key
• fazer a chamada
• fazer reconciliação no final do mês

Agora, com o x402, é:

• solicitar recurso
• receber 402 Payment Required
• pagar
• obter recurso

Este fluxo é fundamental para o Agentic Payment, porque as transações de um Agent podem ser muitas, pequenas, em tempo real, sob demanda.

Por exemplo:

• um Agent de escrita compra uma consulta de dados
• um Agent de investigação financeira invoca uma análise on-chain
• um Agent de viagens consulta múltimos preços
• um Agent de desenvolvimento compra modelos, ambientes de teste
• um Agent de tráfego compra dados de Semrush uma única vez, sem precisar de um SaaS completo

Se cada serviço exigir contas, subscrições, API keys, pacotes e aprovações humanas, a execução do Agent fica presa na fase de pagamento e aquisição. Por isso, o significado do x402 não é tornar o pagamento “mais cripto”, mas torná-lo mais parecido com um protocolo da internet: solicitável, retornável, verificável, automatizável.

O L402 é uma abordagem semelhante, usando HTTP, mas combinando com redes como Lightning Network, macaroons, para autenticação e micropagamentos. A Lightning Labs define o L402 como um protocolo para facilitar a autenticação e pagamento de recursos de API, tornando mais fácil para AI Agents participarem.

Isto mostra que o problema não surgiu com o x402. Antes, já se tentava fundir três conceitos: controlo de acesso HTTP, micropagamentos e permissões de serviços digitais. Mas faltava uma necessidade forte de mercado.

Os humanos não pagam alguns cêntimos por um API endpoint. Mas os Agents sim. Humanos não invocam centenas de fontes de dados por dia, mas os Agents sim. Humanos não combinam chamadas, consultas, pagamentos e verificações em tempo real entre diferentes serviços, mas os Agents podem.

Por isso, a emergência do AI Agent torna a via do pagamento nativo na internet mais relevante.

No ecossistema Tether, também começam a surgir iniciativas semelhantes. O documento x402 do Tether WDK afirma que o x402 é importante para AI Agents, porque permite programaticamente pagar por recursos; torna o pagamento uma componente nativa da web, permitindo que um Agent descubra preços, assine pagamentos e aceda a recursos numa única requisição-resposta. O projeto t402 também se apresenta como um padrão aberto de pagamentos nativos na internet, suportando várias formas de valor: cripto, fiat, stablecoins, tokens, e compatível com o Tether WDK. É importante notar que não é ainda um padrão oficial do Tether, mas uma exploração de protocolos similares ao x402 no ecossistema USDT/Tether.

Por trás, há uma tendência importante: Agentic Payment não é uma competição de produtos de uma única empresa ou blockchain. Está a formar uma nova pilha de protocolos.

• AP2 responde: por que é que um Agent tem autorização para pagar?
• Protocolos como o x402, L402, T402 respondem: quando um Agent solicita um recurso digital, como é que o serviço inicia o pagamento, como é que o Agent conclui, e como é que o recurso é entregue?
• Stablecoins e blockchain respondem: com que ativo final se liquida, onde se verifica, como fazer de forma rápida, programável e cross-platform?

Por isso, Agentic Payment e Crypto não estão a ser discutidos apenas porque o Web3 quer aproveitar IA. Mas porque o Agentic Payment está a reabrir uma questão antiga do internet: a de um pagamento nativo, que seja parte do protocolo, e não uma funcionalidade externa.

A informação pode fluir de forma nativa na internet. Mas o valor, a longo prazo, não. A emergência do Agent está a forçar a internet a preencher essa lacuna.

Por isso, protocolos como o x402, L402, T402 merecem atenção. Não se trata apenas de fazer IA pagar com criptomoedas, mas de definir uma nova forma de interação: máquinas pedem recursos, entendem preços, verificam autorizações, pagam, recebem serviços.

Se o cartão resolve o checkout, estes protocolos resolvem como as máquinas iniciam uma transação de pagamento. E, ao fazerem isso, as stablecoins e a blockchain deixam de ser apenas ferramentas de pagamento, para se tornarem a linguagem de liquidação e execução nativa do Agentic Payment.

3. Porque é que as stablecoins: o Agent precisa de uma unidade de valor estável, não de ativos voláteis

Se o Agent realmente precisa de um protocolo de pagamento legível por máquinas e que possa ser executado automaticamente, por que é que a maior parte da discussão recai sobre stablecoins? Por que não BTC? Por que não ETH? Por que não cartões bancários tradicionais?

O ponto-chave não é “crypto asset” em si, mas que tipo de ativo de pagamento o Agent precisa. Se um Agent apenas mantém ativos a longo prazo, pode preocupar-se com oscilações, ganhos, riscos. Mas se um Agent paga para completar tarefas, o que mais precisa não é de um ativo de especulação, mas de uma unidade de valor estável.

Um Agent de pesquisa, ao consultar uma API de dados, pode gastar 0,1 dólares. Um Agent de codificação, ao invocar um modelo, pode gastar 0,03 dólares. Um Agent de marketing, ao comprar dados de tráfego, pode gastar 1 dólar. Um Agent de compras, ao fazer comparações, pedidos e pagamentos automáticos, precisa de controlar cada despesa dentro do orçamento.

Nestes cenários, o Agent não está a fazer uma troca, nem a especular com moedas. Está a completar uma tarefa. Precisa de saber: quanto custa este recurso? Esta chamada vai ultrapassar o orçamento? A compra está autorizada pelo utilizador? Após a entrega, o custo pode ser registado com precisão?

Se o ativo de pagamento oscila muito, o orçamento do Agent fica difícil de gerir. Hoje, uma chamada API vale 0,1 dólares, amanhã, devido à volatilidade, pode valer 0,12 ou 0,08. Para mercados de troca, pouco importa. Para compras sob demanda de recursos, aumenta a complexidade desnecessariamente.

Por isso, o Agentic Payment tende a usar stablecoins, não ativos voláteis.

A primeira vantagem das stablecoins é oferecer uma unidade de valor mais próxima do mundo real dos negócios. Hoje, muitas APIs, SaaS, serviços de dados, modelos, cloud, são cotados em dólares. Se o Agent quer comprar esses recursos sob demanda, usar uma stablecoin permite colocar orçamento, preço, autorização e faturação na mesma unidade.

Parece simples, mas é fundamental para o Agent. Porque o Agent não só paga, mas também avalia: vale a pena? O orçamento é suficiente? Precisa de confirmação do utilizador? Pode registar o custo? E, se algo correr mal, explicar porquê gastou aquele dinheiro.

Por isso, o Agentic Payment precisa de uma moeda de valor estável, legível por máquinas, que possa ser invocada por programas. E as stablecoins, mais do que BTC ou ETH, atendem melhor a esse requisito.

A segunda vantagem é que as stablecoins são mais adequadas a pagamentos pequenos, frequentes, instantâneos. Como já vimos com o x402, o Coinbase define o x402 como um protocolo para pagamentos instantâneos e automáticos com stablecoins via HTTP, permitindo que APIs, conteúdos digitais e serviços possam cobrar de clientes humanos ou máquinas, sem necessidade de contas, sessões ou autenticação complexa. Este fluxo é ideal para chamadas rápidas, de baixo valor, sob demanda: uma consulta de dados, uma invocação de modelo, uma desbloqueio de conteúdo, uma análise on-chain, uma geração de gráficos. O documento do Tether WDK sobre o x402 explica claramente: os AI Agents precisam de pagar programaticamente por recursos, e o x402 permite que, numa única requisição-resposta, descubram preços, assinem pagamentos e acedam aos recursos.

Isto não é compatível com o uso de cartões bancários. Cartões são mais indicados para o consumo humano, para o checkout de lojas físicas ou online. Stablecoins, por outro lado, encaixam-se melhor na liquidação instantânea, de pequenas quantias, em ambientes abertos, automatizados.

Claro que os cartões não vão desaparecer. Protocolos como o MPP da Stripe, que suportam pagamentos com cartões e stablecoins, mostram que as duas vias coexistirão. Os comerciantes podem aceitar pagamentos de agents com stablecoins ou com cartões, dependendo do contexto.

Por isso, a questão não é “stablecoin substitui cartão”, mas “cartão serve para o comércio tradicional, stablecoin para o pagamento de recursos digitais na rede aberta”.

A terceira vantagem é que as stablecoins são naturalmente mais adequadas a operações cross-border e cross-platform. Um Agent pode consultar APIs nos EUA, usar modelos na Europa, aceder a conteúdos na Ásia, fazer análises na blockchain, e negociar com outro Agent. Se cada transação dependesse de contas bancárias, adquirentes e métodos locais diferentes, o fluxo seria fragmentado. Mas as stablecoins, como ativos nativos da internet, podem circular 24/7, atravessar plataformas, carteiras, aplicações, e serem processadas por contratos inteligentes ou protocolos de pagamento. Para o utilizador humano, é mais rápido. Para o Agent, é essencial: a sua execução não deve parar por causa de fins de semana, fronteiras, janelas de liquidação bancária ou sistemas de contas tradicionais. Precisa de uma moeda que esteja sempre disponível, que possa ser automaticamente invocada, e que seja verificável.

Por isso, o suporte do x402, do Tether WDK, e as explorações em torno do ecossistema USDT/Tether, caminham na mesma direção: transformar o pagamento com stablecoins numa componente nativa do stack web, acessível por máquinas, e não apenas por humanos.

Contudo, há problemas. As stablecoins não são perfeitas.

A transparência das reservas, a entidade emissora, a regulação, a capacidade de resgate, a liquidez na cadeia, variam bastante. O BIS, no seu relatório anual de 2025, criticou as stablecoins por insuficiências em aspectos essenciais como singularidade, elasticidade e integridade, alertando que não devem ser vistas como uma substituição completa do sistema monetário moderno.

Mais precisamente, as stablecoins não são uma moeda perfeita, mas são atualmente uma das melhores opções de liquidação nativa na internet, que atende às necessidades do Agentic Payment.

O seu valor não está na narrativa de descentralização, mas na capacidade de oferecer:

• Preços relativamente estáveis
• Serem invocáveis por programas
• Circularem entre plataformas
• Operarem 24/7
• Integrar com pagamentos nativos na web, carteiras, contratos inteligentes e auditorias na blockchain

Por isso, quando se discute o recurso a recursos na rede aberta, as stablecoins surgem naturalmente. Porque o que o Agent precisa não é de uma “mão que paga com cartão”, mas de uma linguagem de pagamento que os softwares possam entender e usar.

Se o cartão foi criado para o consumo humano, as stablecoins parecem mais uma linguagem de liquidação para a economia das máquinas.

Claro que essa linguagem ainda não está madura. Precisa de melhores frameworks de conformidade, mecanismos de emissão mais estáveis, regras de risco mais claras, carteiras com permissões mais robustas, e de protocolos como o AP2, x402, MPP, para se integrar numa infraestrutura de pagamento agentic em larga escala.

Mas o caminho está claro: o Agent precisa de uma unidade de valor estável, de uma liquidação instantânea, de uma moeda que possa ser programada, e de uma capacidade de pagamento cross-platform e cross-border.

E essa é a razão pela qual as stablecoins são essenciais no Agentic Payment. Não porque todas as transações se tornem cripto, mas porque, ao passar a envolver entidades de software, o “dinheiro” começa a parecer mais uma parte do protocolo da internet.

Porém, as stablecoins respondem apenas a uma questão: com que dinheiro o Agent paga? Ainda não respondem à outra: após gastar na rede aberta, quem autorizou, onde foi gasto, houve ultrapassagem de limites, o serviço foi entregue? Essa questão leva-nos ao blockchain.

4. Porque é que precisamos de blockchain: não para colocar na cadeia, mas para tornar verificáveis as ações do Agent

Mesmo que o Agent precise de pagar com stablecoins, por que razão usar blockchain? Não pode ser um livro-razão centralizado? Não pode ser a Stripe, Visa, bancos, ou uma plataforma que faça a contabilidade?

Claro que sim. Se o Agent atua num ambiente fechado, como uma loja na Amazon, um serviço SaaS, ou um sistema interno de uma empresa, um livro-razão centralizado é suficiente. A plataforma conhece o utilizador, o Agent, as permissões, o valor gasto, se o serviço foi entregue.

Mas o verdadeiro valor do Agentic Payment está em cenários onde o Agent opera numa rede aberta, cruzando plataformas, serviços, carteiras, países, e até outros Agents. Nesse momento, a questão não é só “o dinheiro foi gasto”, mas “por que foi gasto, quem autorizou, houve ultrapassagem de limites, o serviço foi entregue, quem é responsável se algo correr mal”.

Estas perguntas é que justificam o uso de blockchain na Agentic Payment. Não porque todas as transações devam estar na cadeia, mas porque, ao começar a executar tarefas, invocar serviços e gerir fundos, cada ação económica precisa de uma prova verificável.

Para as pessoas, é tolerável a opacidade. Se um serviço não for entregue, podem reclamar ao suporte. Se há problemas na compra, podem consultar contratos, finanças, emails, reuniões. Se há uma cobrança indevida, podem contestar com o banco. Esses mecanismos são lentos, mas funcionam.

Para as Agents, isto não funciona. A frequência de transações pode ser maior, os valores menores, os serviços mais diversos, a cadeia de execução mais longa. Se cada pagamento precisar de uma verificação manual, captura de tela, consulta de emails, reclamações, o Agentic Payment perde sentido. Precisa de uma cadeia de responsabilidade clara.

Por exemplo, um utilizador dá uma tarefa ao Agent: gastar até 100 dólares esta semana, para fazer uma análise de mercado, comprando apenas recursos de dados, modelos e gráficos. O Agent faz uma requisição a uma API de dados, que devolve 0,2 dólares. O Agent avalia se está dentro do orçamento, paga, e o serviço devolve os dados. Aqui, o que importa não é “qual blockchain”, mas se podemos responder a perguntas como: que autorização foi dada, o que foi comprado, se o valor está dentro do limite, se o serviço foi entregue, e se há possibilidade de rastrear uma compra maliciosa ou uma compra por erro.

Por isso, acho que, ao discutir Agentic Payment, ao reler o white paper do Bitcoin, não é por nostalgia. Satoshi Nakamoto não criou uma moeda para substituir o dinheiro tradicional, mas para permitir transferências verificáveis sem terceiros de confiança, usando uma cadeia de hashes e proof-of-work que impede alterações posteriores.

O Agentic Payment tem problemas diferentes. Não é só evitar duplo gasto, mas garantir que a autorização, a ultrapassagem de limites, a entrega e a responsabilidade estejam verificadas. E há um ponto comum: ao atuar numa rede aberta, uma transação verificável é a infraestrutura fundamental.

Essa é a essência do blockchain. Não é para tornar o pagamento “místico”, mas para transformar estados internos de plataformas e bancos de dados em estados verificáveis externamente. Pelo menos na teoria, registros de pagamento, autorizações, acessos, condições de reembolso, consumos de orçamento, podem ser mais padronizados e auditáveis. Para o utilizador humano, pode parecer apenas “contas mais claras”. Para o Agent, é a base da confiança.

Porque o Agent não é humano. Não pode confiar na sua memória ou na sua intenção. Precisa de uma cadeia de provas verificáveis.

Por isso, o AP2, o x402, as stablecoins e o blockchain aparecem frequentemente associados, mas não são a mesma coisa. O AP2 é um quadro de confiança, um framework de autorização, que permite que o Agent execute pagamentos de forma segura e autônoma. Os protocolos como o x402, L402, T402 são camadas de requisição de pagamento, que definem como um Agent solicita recursos e como o serviço responde com pagamento. As stablecoins são o ativo de liquidação, que resolve com que valor se paga. O blockchain é a camada de estado verificável, que garante que as transações, autorizações e entregas possam ser auditadas.

Estas camadas não são uma só, mas juntas formam uma infraestrutura de pagamento agentic. Caso contrário, o Agent, mesmo sendo inteligente, pode acabar a clicar em botões, mas a depender de processos tradicionais de contas, reembolsos, disputas, que anulam a automação.

Claro que há riscos. Permitir que um Agent aceda a pagamentos na cadeia implica riscos de segurança, de responsabilidade, de fraude. Se o Agent for atacado, se a autorização for demasiado ampla, se o serviço não entregar, se um site malicioso induzir pagamento, ou se o Agent gastar toda a verba numa noite, tudo isso é um problema.

Por isso, o Agentic Payment não é só dar uma carteira ao Agent e dizer “vai lá, gasta”. Precisa de mecanismos de controlo: limites, listas brancas, listas negras, escopo de autorização, níveis de risco, confirmação manual, pausas, auditoria. Pequenas transações, de baixo risco, podem ser automáticas. Grandes transações, de alto risco, que envolvem o mundo real, devem voltar à intervenção humana.

Assim, vejo o blockchain na Agentic Payment mais como uma camada de responsabilidade verificável, que não serve para substituir o sistema financeiro tradicional, mas para garantir que as ações do Agent na rede aberta possam ser auditadas, verificadas e responsabilizadas. Não é uma questão de fé, nem de narrativa, mas de que, ao começar a gastar na rede aberta, o Agent precisa de uma prova de que o que fez foi autorizado, que o que comprou é registado, que a sua ação é rastreável, e que a responsabilidade pode ser atribuída.

Este é o verdadeiro papel do blockchain neste contexto. Não uma questão de crença, nem uma narrativa, nem uma “fusão de IA + Web3”. Mas uma resposta à necessidade de verificar, registrar e responsabilizar as ações económicas de máquinas numa rede aberta.

É por isso que o AP2, o x402, as stablecoins e o blockchain aparecem frequentemente juntos, mas não são a mesma coisa. O AP2 é um quadro de confiança, de autorização, que permite ao Agent agir com segurança. Os protocolos como o x402, L402, T402 são camadas de requisição de pagamento, que definem como um Agent solicita recursos e como o serviço responde com pagamento. As stablecoins são o ativo de liquidação, que resolve com que valor se paga. O blockchain é a camada de estado verificável, que garante que as ações possam ser auditadas.

Estas camadas, juntas, formam uma infraestrutura de pagamento agentic. Caso contrário, o Agent, mesmo inteligente, pode acabar a clicar em botões, mas dependente de processos tradicionais de contas, reembolsos e disputas, que anulam a automação.

Claro que há riscos. Permitir que um Agent aceda a pagamentos na cadeia implica riscos de segurança, responsabilidade, fraude. Se o Agent for atacado, se a autorização for demasiado ampla, se o serviço não entregar, se um site malicioso induzir pagamento, ou se gastar toda a verba numa noite, tudo isso é um problema.

Por isso, o Agentic Payment não é só dar uma carteira ao Agent e dizer “vai lá, gasta”. Precisa de mecanismos de controlo: limites, listas brancas, listas negras, escopo de autorização, níveis de risco, confirmação manual, pausas, auditoria. Pequenas transações, de baixo risco, podem ser automáticas. Grandes transações, de alto risco, que envolvem o mundo real, devem voltar à intervenção humana.

Assim, vejo o blockchain na Agentic Payment mais como uma camada de responsabilidade verificável, que não serve para substituir o sistema financeiro tradicional, mas para garantir que as ações do Agent na rede aberta possam ser auditadas, verificadas e responsabilizadas. Não é uma questão de fé, nem de narrativa, mas de que, ao começar a gastar na rede aberta, o Agent precisa de uma prova de que o que fez foi autorizado, que o que comprou é registado, que a sua ação é rastreável, e que a responsabilidade pode ser atribuída.