Obenan

Briefings da Obenan · Signal

As ações pagas de agentes estão a tornar-se infraestrutura. O compromisso do comerciante continua por resolver.

As plataformas de agentes estão a transformar APIs pagas, servidores MCP pagos, conteúdos web pagos e pagamentos entre máquinas em infraestrutura nativa de tempo de execução. Isso responde à pergunta sobre como um agente paga. Não responde à pergunta sobre se o comerciante do outro lado consegue cumprir um compromisso específico no momento em que o dinheiro circula.

Published May 13, 2026 · Global · Infraestrutura pública

Leitura para operadores

Os lançamentos recentes reduzem a lacuna na infraestrutura de pagamentos; o lado do comerciante continua por resolver. Se gere reservas, mobilidade, serviços, bilhética ou qualquer fluxo de serviço local, trate a verdade sobre disponibilidade, políticas, elegibilidade e confirmação como trabalho seu, antes da execução do pagamento. Setembro de 2026 trouxe movimento em três camadas separadas, e nenhuma delas é um cliente a comprar-lhe a si.

Enviar email à CerenVer Merchant Infrastructure

O que mudou

A infraestrutura pública para ações pagas de agentes consolidou-se entre 29 de abril e 12 de maio de 2026

Nas últimas duas semanas, quatro movimentos públicos independentes trataram as ações pagas de agentes como infraestrutura gerida, e não como teatro de protocolos. O padrão é coerente: as plataformas de agentes contam agora pagar por ferramentas, conteúdos e recursos como um comportamento de primeira linha em tempo de execução.

01

O AWS Bedrock AgentCore Payments entra em pré-visualização

A 7 de maio de 2026, a AWS lançou o Amazon Bedrock AgentCore Payments em pré-visualização. O lançamento torna os pagamentos uma capacidade nativa de tempo de execução para os agentes Bedrock, suporta o x402, integra as carteiras da Coinbase e as carteiras Privy da Stripe, impõe limites de gastos ao nível da sessão e enquadra explicitamente os micropagamentos como o primeiro passo para fluxos mais amplos do lado do comprador.

02

A Stripe consolida o comércio com agentes numa única pilha

A 29 de abril de 2026, na Sessions 2026, a Stripe alargou o acesso dos comerciantes através do painel, acrescentou a Google como rota de descoberta e checkout a jusante, através do AI Mode e da aplicação Gemini, e introduziu as carteiras de agente Link, bem como o suporte ao Machine Payments Protocol para pagamentos programáticos por agentes.

03

O MPP publica rascunhos de autenticação de pagamento e de transporte MCP

A 12 de maio de 2026, o ecossistema do Machine Payments Protocol publicou dois Internet-Drafts interligados em paymentauth.org: um esquema de autenticação HTTP Payment e um mapeamento de transporte JSON-RPC e MCP. Em conjunto, dão uma semântica concreta ao 402 Payment Required e definem a forma como as chamadas a ferramentas pagas, as leituras de recursos e as obtenções de prompts podem ser expressas em MCP.

04

A Adyen adere à x402 Foundation

Na sua atualização de negócio do primeiro trimestre, de 6 de maio de 2026, a Adyen revelou que aderiu à x402 Foundation para ajudar a estabelecer normas abertas para pagamentos através de HTTP, associando explicitamente esse passo a fluxos de transação interoperáveis no comércio agêntico. Um grande PSP fez uma aposta visível em normas para objetos de pagamento nativos de HTTP.

Provas posteriores

Na primeira quinzena de setembro de 2026 aconteceram quatro factos datados. É fácil ouvi-los como uma única história sobre agentes que compram coisas. Não são uma única história. Situam-se em três camadas diferentes da infraestrutura, e vale a pena mantê-las separadas, porque só uma das três fica do lado do balcão que pertence ao comerciante — e mesmo essa é o escritório das traseiras, não a caixa.

As provas abaixo foram consultadas a 22 de setembro de 2026. Cada elemento indica a data da respetiva fonte.

O que é: o código de biblioteca de um protocolo de pagamento tornou-se mais cuidadoso a falhar de forma visível. Ninguém pagou a ninguém por causa disso.

  • Um protocolo é um conjunto acordado de regras que dois computadores seguem para poderem fazer uma transação sem uma pessoa no meio; um SDK é o código já feito que um programador integra num programa para que este consiga falar esse protocolo. A 15 de setembro de 2026, os responsáveis pela manutenção do SDK em Python do protocolo de pagamento x402 lançaram a versão 2.23.0, que se seguiu à 2.22.0.
  • As alterações são do género pouco vistoso, que só importa quando circula dinheiro a sério. A liquidação é a etapa em que o dinheiro chega de facto, e não fica apenas autorizado — a mesma diferença entre um cartão aprovado no seu terminal de pagamento na sexta-feira e o valor a aparecer na sua conta na terça. Durante a liquidação, o código passa a reutilizar uma verificação que já tinha feito, em vez de consultar a rede uma segunda vez. Os erros de configuração permanentes passam a ser detetados quando o programa arranca, enquanto os tempos de espera esgotados temporários continuam a poder ser repetidos. Os tempos de espera foram alargados e ganharam limites máximos — nas chamadas ao facilitador, o serviço que verifica e executa um pagamento em nome de ambas as partes, e nas chamadas a ferramentas pagas —, para que uma liquidação lenta possa terminar em vez de ser interrompida. A validação de rotas foi reforçada contra um endereço web disfarçado de propósito. O limite de gastos que um programador define passa a ser transmitido a todos os métodos de pagamento que a biblioteca suporta.
  • Trata-se de uma implementação para uma linguagem de um único protocolo — o código para uma só linguagem de programação — que se torna mais explícita no seu funcionamento. É escrita pelas pessoas que mantêm esse protocolo, sobre o próprio código. E também não é a versão mais recente: a 2.24.0 surgiu a 22 de setembro de 2026, o dia em que estas provas foram consultadas.

Isto não é: adoção, volume de transações nem qualquer comerciante a fazer o que quer que seja. Uma nota de versão é uma afirmação sobre uma base de código. Não menciona nenhum restaurante, clínica ou oficina, e não dá a entender nenhum.

O que é: software a pagar a software. Um programa paga por dados ou por um serviço de que precisa para fazer o seu trabalho. O comprador é um programa, o vendedor é um fornecedor de API — uma empresa que vende a outros programas acesso aos seus dados ou ao seu software — e cada montante situa-se entre 0,001 e 0,01 dólares norte-americanos.

  • A 1 de setembro de 2026, um artigo no blogue da AWS sobre a t54, escrito por colaboradores da AWS em conjunto com membros da equipa da t54, apresentou o número da própria t54: o serviço x402-secure «processou mais de 20 milhões de transações iniciadas por agentes de IA» desde o lançamento, cada uma «um micropagamento entre $0.001 e $0.01» — um pagamento tão pequeno que não faria sentido passá-lo num cartão.
  • O exemplo prático do artigo é um agente que acompanha carteiras de ações e precisa de comprar dados de mercado em tempo real a uma API paga. O fundador da t54 descreve as transações da mesma forma, como «o tipo de chamada rápida e pequena por dados ou por uma API que nenhuma pessoa conseguiria rever em tempo real», e o artigo diz que acontecem «sem que um humano aprove uma única que seja». Segundo a própria descrição da t54, é isso que o número conta: software a pagar a um fornecedor de software por um serviço que o próprio software consome, milhões de vezes.
  • A analogia mais próxima num negócio local é o carregamento automático do cartão SIM de dados do seu terminal de pagamento. Funciona sem parar, ninguém aprova cada débito, e não é um cliente a reservar uma mesa.

Isto não é: compras, clientes nem qualquer pagamento na caixa de retalho ou de comerciante — o número não conta nada disso. Não é um número auditado de forma independente: é comunicado pela empresa cujo serviço processou as transações, num artigo no blogue do seu fornecedor de nuvem. Ninguém pagou um corte de cabelo com isto.

O que é: ferramentas que permitem ao próprio agente de um negócio operar a própria conta de pagamentos do negócio — e um produto de aceitação anunciado para comerciantes. É a única das três camadas do lado do comerciante, e é o escritório, não o balcão.

  • A 1 de setembro de 2026, a Checkout.com publicou um texto que descreve o seu servidor MCP, que, segundo a empresa, construiu para levar as suas ferramentas ao próprio software de desenvolvimento dos comerciantes. Um servidor MCP é uma porta normalizada que uma empresa coloca à frente dos seus sistemas para que um assistente de IA os possa utilizar — a mesma ideia de dar a um novo gerente um acesso com um conjunto fixo de permissões, em vez das chaves de tudo.
  • O que o assistente pode fazer através dessa porta é, nas palavras da Checkout.com, «consultar o estado dos pagamentos, gerir ligações de pagamento ou executar em segurança ações como reembolsos, disputas e anulações». Um reembolso devolve dinheiro a um cliente que já pagou; uma disputa é a contestação de um débito por parte de um cliente, tratada através do banco; uma anulação cancela um pagamento que foi autorizado mas ainda não capturado — aprovado, mas ainda não cobrado —, pelo que o dinheiro nunca chega a ser debitado. São as tarefas que a pessoa que trata da sua contabilidade faz na segunda-feira de manhã. As permissões «espelham a sua conta no Dashboard da Checkout.com», e as ferramentas estão disponíveis tanto no ambiente de testes como no ambiente real.
  • A Checkout.com afirma também que está a «transformar o MCP numa camada de pagamento nativa para agentes de comerciantes, passando da simples assistência para fluxos de trabalho autónomos e operações em várias etapas». Essa frase descreve trabalho em curso, não um produto acabado. É uma intenção declarada, e deve ser lida como tal até que algo seja lançado.
  • Cerca de uma semana depois, a IXOPAY anunciou uma Agentic Suite com três partes: um Payment Agent que «liga novas experiências de comércio à infraestrutura existente», Universal Tokens que «preservam a identidade do agente, o consentimento do cliente e a intenção de compra juntamente com a credencial de pagamento», e um MCP Server que «dá a assistentes de IA aprovados um acesso controlado a capacidades de pagamento e tokenização suportadas». A página do anúncio apresenta duas datas diferentes para si própria — 8 de setembro de 2026 no cabeçalho e 9 de setembro de 2026 na linha de data. Indicamos as duas em vez de escolher uma. Uma citação no anúncio da Tilopay, um parceiro que trabalha sobre a plataforma da IXOPAY, afirma que os comerciantes da Tilopay «podem começar a crescer com transações agênticas já hoje»; um parceiro dizê-lo no próprio anúncio de lançamento do fornecedor é uma declaração de um parceiro, não uma prova independente de que os comerciantes o tenham feito.
  • A página de produto do Payment Agent acrescenta mais um pormenor: «O suporte inicial a protocolos começa com o Visa Trusted Agent Protocol (TAP). O Payment Agent está a ser construído sobre uma base agnóstica em relação ao protocolo, concebida para suportar protocolos adicionais à medida que o ecossistema do comércio agêntico evolui.» Leia-o como um ponto de partida num desenho deliberadamente multiprotocolo, não como um compromisso com o protocolo de uma única rede — e repare que aparece na página de produto, não no anúncio de lançamento.

Isto não é: o pagamento do consumidor na caixa. Nada aqui descreve um comprador a comprar a um comerciante. Um reembolso e uma disputa dizem respeito a um pagamento já capturado; uma anulação cancela um pagamento autorizado antes da captura. Os três atuam sobre um pagamento que começou por outra via. Um produto de aceitação anunciado é um anúncio. E uma intenção declarada de construir uma camada de pagamento nativa não é uma camada de pagamento nativa.

Volte a juntar as três camadas e a ideia original desta página mantém-se, de forma mais nítida. A canalização tornou-se mais cuidadosa. Os agentes que pagam pelo próprio software produziram um número grande e autodeclarado. Os comerciantes ganharam melhores ferramentas para gerir pagamentos já efetuados. Nada disto diz a um agente se a mesa das 19h00, a marcação de terça-feira na oficina ou o lugar na aula de sábado estão realmente disponíveis e podem de facto ser cumpridos neste momento.

Onde se situa cada um destes passos, e porque são separados: Ler o modelo «committability ladder»

Porque é importante

Pagar está a normalizar-se. Cumprir um compromisso específico não.

A infraestrutura de pagamento responde a uma pergunta sobre credenciais: quem está autorizado a pagar e como o dinheiro deve circular. Não responde, por si só, a uma pergunta sobre a preparação do comerciante: se um lugar de estacionamento, um lugar numa aula, um depósito num restaurante, uma marcação, um bilhete ou uma janela de levantamento específicos podem realmente ser cumpridos no momento em que um agente se compromete. Quando a pilha pública se consolida em torno da autorização, da tokenização, da intenção e dos pagamentos entre máquinas, a pergunta sobre a capacidade de compromisso do lado do comerciante não fica mais fácil. Fica mais visível.

Para onde a pilha se está a mover

A infraestrutura cobre agora a execução do pagamento. O compromisso do comerciante está a montante dela.

Leia os quatro lançamentos em conjunto e surge um quadro. As grandes plataformas começaram a controlar aquilo por que um agente está autorizado a pagar, como o pagamento é estruturado e como é encaminhado. Nada disso decide se um compromisso local identificado, do lado do comerciante, é real, atual, completo em termos de política e seguro para se agir sobre ele neste momento.

Lado da infraestrutura de pagamento

Já público

  • Tempo de execução gerido para pagamentos de agentes numa grande plataforma de agentes na nuvem (AWS Bedrock AgentCore Payments)

  • Carteiras de agentes, primitivas de pagamento entre máquinas e rotas de descoberta de comerciantes consolidadas numa única pilha de PSP (Stripe)

  • Semântica de pagamento nativa de HTTP, com chamadas pagas a ferramentas e recursos MCP definidas em rascunhos de normas (MPP)

  • Normas abertas de pagamento HTTP apoiadas por um grande PSP que adere à fundação (Adyen e x402)

Lado do compromisso do comerciante

Ainda por resolver

  • Se o horário, o bilhete, o lugar, a mesa, o lugar de estacionamento, a marcação ou a janela identificados estão realmente disponíveis no momento do compromisso

  • Se a política do comerciante sobre cancelamento, depósito, chegada tardia, alteração e reembolso pode ser consultada antes de o dinheiro circular

  • Se a elegibilidade do lado do comerciante para o compromisso específico é verdadeira agora, e não apenas numa página de perfil

  • Se o comportamento de confirmação, cumprimento e disputa se mantém fora de pilotos controlados

A nossa posição

Pagar está a tornar-se infraestrutura. A capacidade de compromisso ainda tem de ser construída.

O padrão nos lançamentos de abril e maio de 2026 é suficientemente coerente para ser lido como um único movimento. O lado do pagamento da pilha de agentes está a consolidar-se publicamente em torno de tempos de execução geridos, carteiras de agentes, primitivas de pagamento entre máquinas e semântica de pagamento nativa de HTTP. É a direção certa. Também torna mais nítida a pergunta a montante. Um desafio de pagamento pode dizer a um agente como pagar. Não lhe pode dizer se o comerciante do outro lado consegue cumprir o compromisso identificado no momento em que o dinheiro circula. Obenan lê isto como a pilha pública a aproximar-se da fronteira da preparação do comerciante, e não a ultrapassá-la.

O acesso ao pagamento não é o mesmo que o compromisso do comerciante

Compromissos delimitados, identificados e com carimbo temporal são a unidade da preparação do comerciante

A verdade do lado do comerciante está a montante da execução do pagamento e a jusante da descoberta

O que este briefing não afirma

O que este briefing não afirma

O argumento acima é delimitado. A lista abaixo é o conjunto explícito de afirmações que este briefing não faz.

  1. 01

    Não afirmamos que Obenan seja um prestador de serviços de pagamento, um adquirente, uma camada de checkout, uma camada de tokenização, uma carteira de agente ou uma rede de liquidação.

  2. 02

    Não afirmamos qualquer integração, piloto ou parceria com o AWS Bedrock AgentCore Payments, a Stripe, a Coinbase, a Privy, a Adyen, a x402 Foundation, o Machine Payments Protocol, a OpenAI, a Visa, a Mastercard, a American Express, o Universal Commerce Protocol, o Agentic Commerce Protocol, o AP2 ou qualquer rede de pagamentos ou programa para programadores.

  3. 03

    Não afirmamos que ferramentas MCP pagas, APIs pagas ou chamadas a recursos pagos resolvam a capacidade de compromisso do lado do comerciante para serviços locais.

  4. 04

    Não afirmamos que todos os serviços locais estejam hoje preparados para o pagamento agêntico.

  5. 05

    Não afirmamos que qualquer piloto controlado de qualquer rede prove o comportamento de uma implementação comercial alargada.

  6. 06

    Este briefing não publica nomes de parceiros privados, o estado de reuniões privadas nem material abrangido por NDA. O argumento assenta apenas em fontes públicas.

  7. 07

    Não afirmamos que as transações iniciadas por agentes que a t54 comunica sejam compras a comerciantes, pagamentos de retalho ou uma contagem auditada de forma independente. São micropagamentos de agentes a serviços de software, comunicados pela empresa que os processou.

  8. 08

    Não afirmamos que a Checkout.com tenha lançado uma camada de pagamento nativa para agentes de comerciantes. A Checkout.com declara essa intenção; o que é descrito como disponível são operações de pagamento de escritório das traseiras.

  9. 09

    Não afirmamos que a Agentic Suite da IXOPAY, ou qualquer componente dela, tenha sido adotada por comerciantes. Um anúncio de lançamento e a citação de um parceiro não são prova de adoção.

  10. 10

    Não afirmamos que uma nova versão da biblioteca de software de um protocolo de pagamento indique adoção, volume de transações ou preparação dos comerciantes.

Plano de ação para operadores

O que fazer agora, o que acompanhar e o que não presumir

Separado entre aquilo sobre o qual o lado do comerciante pode agir diretamente e aquilo que se situa do lado da infraestrutura de pagamento.

01

Fazer agora

Sob controlo do comerciante

  • Estruturar a disponibilidade, a capacidade e os objetos de reserva para que um agente os possa verificar antes de se comprometer

  • Codificar as regras de cancelamento, depósito, elegibilidade e política num formato legível por máquina

  • Fazer com que as mensagens de confirmação correspondam àquilo que o comerciante consegue realmente cumprir no momento

Sob controlo da infraestrutura

  • Acompanhar que superfícies de ações pagas de agentes começam a acrescentar semântica de compromisso do lado do comerciante, e não apenas semântica de pagamento

02

Acompanhar

Sob controlo do comerciante

  • Se a capacidade de compromisso do lado do comerciante passa a poder ser consultada de forma duradoura nos sistemas de reservas, de agendamento e de marcações

  • Se a política específica de cada categoria passa a ser normalizada a montante da execução do pagamento

Sob controlo da infraestrutura

  • Se a AWS, a Stripe, a Adyen e a x402 Foundation vão além da autorização e dos micropagamentos, para uma semântica de reserva, de depósito e de intenção explícita do comprador

  • Se os rascunhos do MPP e do transporte MCP passam de rascunhos públicos a protocolos adotados

  • Se as ferramentas de pagamento do lado do comerciante que surgiram em setembro de 2026 passam das operações de escritório das traseiras para o compromisso que um cliente está a comprar

03

Não presumir

Sob controlo do comerciante

  • Que um perfil, uma listagem ou uma entrada de catálogo equivale a capacidade de compromisso para um compromisso específico identificado

  • Que a normalização do lado do pagamento resolve automaticamente a preparação do lado do comerciante

Sob controlo da infraestrutura

  • Que ferramentas MCP pagas ou ações pagas de agentes equivalem a compromisso do lado do comerciante

  • Que tempos de execução de agentes em fase de pré-visualização equivalem a fluxos comerciais de comércio de nível de produção

  • Que uma nova versão do software de um protocolo de pagamento, uma contagem de transações comunicada por um fornecedor ou um anúncio de produto indiquem adoção pelos comerciantes

Continue a ler

Como isto se liga ao resto da tese da participação do comerciante

O lado do comerciante ainda tem de ser construído

As ações pagas de agentes estão a tornar-se infraestrutura. A próxima camada em falta é a capacidade de compromisso. Para os operadores de reservas, mobilidade, serviços, bilhética ou qualquer fluxo de serviço local, o trabalho está a montante do pagamento: a verdade sobre disponibilidade, política, elegibilidade e confirmação.

Enviar email à CerenVer Merchant Infrastructure

Fontes

Este Signal baseia-se apenas em fontes públicas. Os lançamentos de maio de 2026 são lidos em conjunto como um único padrão: a consolidação da infraestrutura gerida de pagamentos de agentes entre 29 de abril e 12 de maio de 2026. As fontes de setembro de 2026 são lidas como três camadas separadas, deliberadamente não misturadas, e cada número é atribuído a quem o comunicou.

  1. 1.
    Agents that transact: Introducing Amazon Bedrock AgentCore Payments, built with Coinbase and Stripeaws.amazon.com · 7 de maio de 2026 · 13 de maio de 2026

    Prova primária de que uma grande plataforma de agentes na nuvem trata agora recursos pagos, ferramentas MCP pagas e gastos de agentes limitados por orçamento como uma capacidade de primeira linha em tempo de execução

  2. 2.
    Stripe builds out the economic infrastructure for AI with 288 launches at Sessions 2026stripe.com · 29 de abril de 2026 · 13 de maio de 2026

    Prova primária de que uma única pilha de PSP abrange agora a distribuição de agentes, as carteiras de agentes e as primitivas de pagamento entre máquinas numa só camada orientada para o comerciante

  3. 3.
    Payment Authentication Scheme: JSON-RPC and MCP Transport (draft-payment-transport-mcp-00)paymentauth.org · 12 de maio de 2026 · 13 de maio de 2026

    Prova primária de que as chamadas a ferramentas MCP pagas, as leituras de recursos e as obtenções de prompts estão a receber uma semântica de pagamento concreta em Internet-Drafts públicos

  4. 4.
    The Payment HTTP Authentication Scheme (draft-httpauth-payment-00)paymentauth.org · 12 de maio de 2026 · 13 de maio de 2026

    Prova secundária que formaliza o 402 Payment Required como um esquema estruturado de autenticação HTTP

  5. 5.
    Adyen publishes Q1 2026 Business Updateadyen.com · 6 de maio de 2026 · 13 de maio de 2026

    Prova primária de que um grande PSP fez uma aposta visível em normas para objetos de pagamento nativos de HTTP no comércio agêntico

  6. 6.
    Everything we announced at Sessions 2026stripe.com · 29 de abril de 2026 · 13 de maio de 2026

    Referência de cobertura detalhada para os componentes da Stripe Sessions 2026 mais relevantes para este Signal, incluindo as carteiras de agente Link, o suporte ao Machine Payments Protocol e a superfície do painel orientada para o comerciante para o acesso de agentes

  7. 7.
    x402 Python SDK Changelog — 2.23.0github.com · 15 de setembro de 2026 · 22 de setembro de 2026

    Primária. As próprias notas de versão dos responsáveis pela manutenção de uma implementação para uma linguagem do protocolo de pagamento x402, consultadas na entrada 2.23.0; o mesmo ficheiro já inclui a 2.24.0, datada de 22 de setembro de 2026. Prova de reforço operacional em código de biblioteca, e de nada sobre comerciantes.

  8. 8.
    How t54 built a trust layer with Amazon Bedrock AgentCore paymentsaws.amazon.com · 1 de setembro de 2026 · 22 de setembro de 2026

    Primária para a escala dos micropagamentos de agentes a serviços, e origem da contagem de transações citada nesta página. Comunicada pela t54, a cliente, num artigo no blogue da AWS escrito por colaboradores da AWS e da t54. Não é uma auditoria, nem comércio de comerciantes.

  9. 9.
    Building trusted AI infrastructure with the Checkout.com MCPcheckout.com · 1 de setembro de 2026 · 22 de setembro de 2026

    Primária para as operações de pagamento de escritório das traseiras do lado do comerciante através de um servidor MCP — reembolsos, disputas e anulações na própria conta do comerciante. A intenção declarada de construir uma camada de pagamento nativa é trabalho futuro, não uma capacidade lançada.

  10. 10.
    IXOPAY Launches Agentic Suite to Help Merchants Support Agentic Commerce and Automate Payment Workflowsixopay.com · 8 de setembro de 2026 (cabeçalho da página) / 9 de setembro de 2026 (linha de data) · 22 de setembro de 2026

    Anúncio de lançamento do fornecedor para Payment Agent, Universal Tokens e um MCP Server. A página apresenta duas datas diferentes para si própria, e ambas são indicadas. A citação de parceiro que contém é uma declaração de um parceiro, não prova de adoção.

  11. 11.
    Payment Agent: Get Started with Agentic Commerceixopay.com · Última alteração a 8 de setembro de 2026 · 22 de setembro de 2026

    A página de produto do IXOPAY Payment Agent, que contém a afirmação sobre o suporte inicial a protocolos. Citada porque o anúncio de lançamento não contém essa afirmação. O TAP surge como protocolo inicial sobre uma base que a página descreve como agnóstica em relação ao protocolo.