Durante a maior parte da história da web, o software recomendava e os humanos transacionavam. Uma página sugeria um produto; uma pessoa clicava em Comprar, digitava um número de cartão, lia um código. Todos os fluxos de checkout alguma vez construídos assumiram silenciosamente que havia um humano sentado à frente deles.
Esse pressuposto ruiu no espaço de cerca de um ano. A Anthropic lançou o Model Context Protocol para dar aos modelos acesso estruturado a ferramentas e APIs. A OpenAI lançou um Agentic Commerce Protocol e o Instant Checkout dentro do chat. A Google publicou o Agent Payments Protocol. A Coinbase ressuscitou o há muito adormecido código de estado HTTP 402 Payment Required sob a forma de x402, uma maneira de cobrar por uma chamada de API em stablecoins. A Visa anunciou o Intelligent Commerce; a Mastercard anunciou o Agent Pay. As redes de cartões, os laboratórios de modelos e os trilhos cripto chegaram todos à mesma conclusão no espaço de poucos trimestres: o comprador está prestes a ser um programa.
A canalização está a ser instalada depressa. O que se discute muito menos é quais categorias estão de facto prontas para um agente comprar. Essa é a pergunta mais interessante, e a resposta não é a que as demos procuram. Não são bilhetes de concerto, nem ténis, nem compras de supermercado. É conectividade — dados móveis — e vale a pena explicar as razões, porque elas funcionam ao mesmo tempo como uma checklist do que é o comércio pronto para agentes em qualquer categoria.
O que significa de facto “comércio agêntico”
Vale a pena ser preciso, porque o termo já está a ser esticado. Um chatbot que te encaminha para uma página de checkout não é comércio agêntico; é uma caixa de pesquisa com melhores modos. Comércio agêntico é o caso em que o próprio agente reúne três coisas ao mesmo tempo — uma intenção (o utilizador quer dados no Japão na próxima semana), um orçamento (gastar até determinado limite) e a autoridade para agir — e completa a transação de ponta a ponta sem devolver o controlo a um humano no passo crítico.
Tira a marca aos protocolos listados acima e todos eles descrevem o mesmo formato de cinco passos:
- Descobrir — encontrar o produto e o seu preço num formato legível por máquina.
- Autenticar — estabelecer em nome de quem o agente está a agir, ou se precisa sequer disso.
- Autorizar o pagamento — movimentar dinheiro dentro de um limite que o utilizador aceitou.
- Cumprir — entregar de facto o produto.
- Confirmar — devolver algo que o utilizador possa verificar ou usar.
Cada protocolo é forte num ou dois destes passos e silencioso quanto aos restantes. O MCP trata da descoberta e da invocação de ferramentas. O x402 e o AP2 tratam da autorização do pagamento. Nenhum deles te diz quais produtos sobrevivem ao contacto com os outros três passos. O cumprimento é onde a maioria das categorias se desfaz silenciosamente — e a conectividade é a rara categoria em que o cumprimento é trivial.
Porque é que a conectividade é a categoria inicial ideal
Cinco propriedades fazem dos dados móveis algo próximo de uma compra perfeita para um agente. A maioria das categorias físicas e de alto valor falha pelo menos uma delas.
1. Não há átomos. Um eSIM é um direito puro — um perfil entregue pelo ar mais um identificador. Não há morada de envio, nem armazém, nem formulário aduaneiro, nem janela de devolução, nem “deixei-o à porta”. As partes mais difíceis do comércio — logística, cumprimento, a identidade do mundo físico necessária para entregar um objeto a uma pessoa — simplesmente não existem. Um agente em quem não se pode confiar a tua morada continua a poder comprar-te dados em segurança.
2. É instantânea e de baixo risco. O provisionamento acontece em segundos, os montantes são pequenos e os saldos têm limite. Se um agente errar ligeiramente uma compra de dados, o raio de impacto são alguns dólares que podem ser recarregados ou reembolsados — o oposto de um agente a reservar um voo internacional não reembolsável. O baixo risco é o que torna a autonomia razoável, para começar. As primeiras compras certas para os agentes são as baratas e reversíveis.
3. É medida, não empacotada — que é como um modelo já raciocina. O mercado de eSIM tradicional vende pacotes: 5 GB por 15 dias, 10 GB por 30 dias. Para comprar um, um agente tem de adivinhar o consumo do utilizador e apostar contra uma data de expiração. Erra por defeito e o utilizador fica sem dados a meio da viagem; erra por excesso e os gigabytes não usados evaporam-se. Um modelo por megabyte transforma essa aposta em aritmética: MB previstos por dia, vezes dias, vezes a tarifa do país. Aritmética é aquilo em que os modelos são bons. Adivinhar sob um prazo de expiração é aquilo em que são maus.
4. É a necessidade latente por baixo de quase qualquer outra tarefa. A conectividade raramente é o título daquilo que um agente está a fazer; é a coisa de que o título depende. Um agente de viagens que reserva uma viagem comprometeu implicitamente o seu utilizador a precisar de dados num sítio onde não os tem. Um agente de frota a gerir sensores no terreno precisa de cada dispositivo online. Um assistente pessoal que continua a trabalhar enquanto o seu humano atravessa uma fronteira precisa de que a rede o acompanhe. Os dados estão por baixo de outro comércio como infraestrutura — o que significa que a procura por eles é criada automaticamente sempre que um agente faz algo no mundo físico.
5. É globalmente uniforme e bem especificada. Uma compra de conectividade reduz-se a três valores: um país, uma tarifa e um saldo. Esse formato é idêntico em todos os mercados. Um agente que consegue raciocinar sobre a França consegue raciocinar sobre o Japão ou a Tailândia sem um novo modelo do mundo — apenas um número diferente. Produtos uniformes, numéricos e comparáveis são exatamente o tipo que um modelo consegue avaliar e citar sem alucinar.
O que uma compra de conectividade exige de um agente
Portanto a categoria é a certa. O problema é que a forma atual de vender conectividade foi construída para o humano no checkout, e desfaz-se em quase todos os cinco passos quando o comprador é um programa:
- Descobrir — o catálogo vive numa montra renderizada em JavaScript que um agente não consegue ler, atrás de milhares de SKUs de pacotes sobrepostos.
- Autenticar — comprar exige uma conta, e criar uma exige uma confirmação por email ou uma dança de OAuth que o agente não tem browser para completar.
- Autorizar o pagamento — o checkout quer um formulário de cartão, e não existe qualquer conceito de um limite de gasto a que o agente esteja vinculado.
- Cumprir — a ativação é um código QR feito para ser lido pela câmara de um telemóvel, num dispositivo que o agente normalmente não consegue alcançar.
- Confirmar — os identificadores devolvidos são canalização interna (ICCID, IDs de encomenda) em vez de algo de que o utilizador precise.
Nenhum destes é um problema difícil. São apenas problemas que ninguém teve de resolver enquanto o comprador foi sempre humano. Resolvê-los é o que “nativo para agentes” significa de facto — não um widget de chat aparafusado a uma loja de consumo, mas as camadas de autenticação, pagamento e entrega reconstruídas em torno de um comprador diferente.
Como é um fornecedor nativo para agentes
Esta é a parte em que paramos de falar no abstrato. A Roamzy foi construída como um exemplo prático dos cinco passos feitos para agentes; aqui está cada um deles, incluindo onde ainda está em bruto.
Descobrir. O catálogo é exposto de três formas que um agente consegue ler sem browser: uma API REST pública com uma especificação OpenAPI, um llms-full.txt escrito para modelos e não para pessoas, e um servidor Model Context Protocol com doze ferramentas. O servidor MCP corre de duas formas — como pacote npm via stdio, e como endpoint remoto ao qual um agente se liga por URL com zero instalação. A descoberta é o passo que toda a gente acerta primeiro porque é o mais visível; é também o menos importante, porque é inútil se os quatro passos seguintes ainda assumirem um humano.
Autenticar. Este é o maior removedor de atrito, e é uma eliminação em vez de uma adição: não há registo obrigatório. Um agente chama um endpoint, obtém uma sessão anónima, e pode navegar, consultar preços e comprar imediatamente — sem email, sem OAuth, sem conta. Se o utilizador mais tarde quiser ligar a compra a uma identidade real, a sessão pode ser reivindicada com um código de uso único e início de sessão pelo Google ou Telegram. O padrão é anónimo; a identidade é opcional, à posteriori. Um agente não deveria ter de negociar um login antes de conseguir descobrir quanto custa algo.
Autorizar o pagamento. O pagamento é em USDT, o que permite a um utilizador (ou a um agente a agir em seu nome) manter um saldo e gastar contra ele sem um formulário de cartão no circuito. Sejamos honestos quanto ao compromisso: um utilizador sem carteira cripto fica pior aqui do que num checkout de cartão, e os trilhos nativos de pagamento agêntico on-chain — o estilo x402 de “pagar diretamente a chamada de API” — ainda não estão ligados; isso exige uma tesouraria e está deliberadamente em pausa. O que existe hoje é um URL de pagamento que o utilizador abre em qualquer carteira, após o que um webhook confirma e credita o saldo. Mais sobre a mecânica no artigo sobre liquidação em USDT.
Cumprir. Um produto, não um catálogo: um único eSIM global, com preço por megabyte por país, com um saldo que não expira. É isso que faz com que a matemática do orçamento da razão #3 funcione de facto — sem pacote a escolher, sem expiração a vencer. O provisionamento corre contra uma plataforma de eSIM real, por isso o que volta é um perfil funcional, não um placeholder.
Confirmar. O agente recebe um número de telefone (MSISDN) como identificador voltado para o utilizador, uma imagem QR mais um payload em bruto mais um link de instalação com um toque para que a ativação funcione quer o agente e o telemóvel sejam o mesmo dispositivo ou não, e um saldo que o utilizador pode ver a diminuir. Os identificadores internos ficam internos.
As salvaguardas são o produto. A parte que é fácil saltar — e a parte que de facto separa “um agente pode comprar isto” de “pode confiar-se a um agente comprar isto” — são os limites. Cada token de agente carrega um limite de gasto diário e mensal, um teto de arrefecimento em tokens recém-criados, uma porta de confirmação em qualquer transação invulgarmente grande, e um interruptor de emergência que o operador pode acionar. As sessões anónimas são mantidas mais apertadas do que as nomeadas, de propósito:
Os dados têm preço por megabyte à tarifa local de cada país — na ordem de um dólar ou dois por gigabyte na maioria dos mercados, mais nos premium — com a tabela completa de 193 países pública e legível por máquina. O agente não trabalha a partir de um número fixado neste artigo; vai buscar a tarifa em tempo real ao catálogo para qualquer país de que precise, faz a aritmética e mantém-se dentro de um limite sem adivinhar. Uma fonte, sempre atual.
A parte honesta: isto é cedo
Nada disto é uma volta de vitória. O comércio agêntico é suficientemente novo para que a coisa mais comum que um agente faz quando se liga a nós seja ligar-se anonimamente — a camada de identidade OAuth está construída e publicada, mas a forma como os conectores se comportam hoje significa que ela fica maioritariamente por usar, por design. O modelo de pagamento exclusivamente cripto é um filtro real sobre quem pode comprar. Os trilhos de pagamento agêntico on-chain que entusiasmam toda a gente ainda não estão ativos na nossa stack. Estamos há umas semanas nisto, não há uns anos.
Aquilo de que estamos confiantes é o formato da aposta, não o tamanho da liderança. A categoria é a certa: a conectividade passa em todos os testes que importam para uma compra autónoma, e a maioria das alternativas falha pelo menos um. Os pontos de atrito são conhecidos e individualmente resolúveis. E os fornecedores que vendem dados à moda antiga — SKUs de pacotes, registo obrigatório, formulários de cartão, ativação só por QR — estão otimizados para um comprador que está prestes a deixar de ser o único comprador. Preferimos chegar cedo e ser honestos quanto às lacunas do que chegar tarde e polidos. Para um confronto mais afiado sobre onde o modelo tradicional ainda ganha, a comparação Roamzy vs Airalo não poupa nos golpes.
Para onde isto vai
A primeira compra que um agente faz será uma compra aborrecida. É esse o ponto. A conectividade é a rampa de acesso, não o destino — mas é a rampa de acesso para a qual quase tudo o resto vira. Assim que um agente consegue colocar de forma fiável um dispositivo numa rede em qualquer parte do mundo, dentro de um orçamento, sem um humano no checkout, as tarefas interessantes desbloqueiam-se sozinhas: o agente de viagens que provisiona dados antes da viagem em vez de deixar o utilizador encalhado nas chegadas; o agente de frota que recarrega um sensor num campo noutro país; o assistente pessoal que mantém o seu humano online enquanto ele atravessa uma fronteira, sem que lho peçam.
Os dados são a coisa menos entusiasmante na lista do que os agentes vão comprar. São também a coisa de que o resto da lista depende. É normalmente assim que a infraestrutura funciona.
Perguntas que os construtores fazem
Um agente precisa de uma conta Roamzy para comprar? Não. Um agente chama o endpoint de sessão anónima e pode consultar preços e comprar imediatamente. Reivindicar a sessão para uma identidade real é opcional e acontece à posteriori, com um código de uso único mais início de sessão pelo Google ou Telegram.
Como é que um agente se mantém dentro de um orçamento? Cada token tem um limite diário e mensal, um teto de arrefecimento em tokens novos, e uma porta de transação grande que devolve ao humano as compras invulgarmente grandes. O orçamento restante é devolvido a cada chamada, por isso o agente raciocina sobre ele em vez de o descobrir ao falhar.
Qual é a forma mais barata de integrar? O endpoint MCP remoto — ligas por URL, sem pacote para instalar, doze ferramentas disponíveis de imediato. A página de instalação e o guia do programador cobrem tanto o caminho remoto como o stdio, e a visão geral dos agentes é o resumo de uma página de como tudo se encaixa.