DiagnosticMind · ← Todas as edições · EN

A Armadilha do Rebranding: Carris Velhos, Rótulos Novos

Uma tabela comparativa tornou-se viral esta semana. «Jogadas de Comércio Agêntico» — Google, Visa, Mastercard, Stripe lado a lado, cada uma com a sua estratégia para comércio movido a AI. Novos protocolos, novas capacidades, novo posicionamento.

Parecia o futuro.

Depois os detalhes contaram outra história.


A tabela que diz mais do que pretendia

A Google chama à sua jogada «Universal Commerce Protocol» — orquestração de comércio agente-para-comerciante. A Visa e a Mastercard oferecem «execução de pagamento agente-para-rede». A Stripe, em abono da verdade, mal a disfarça: «execução de checkout agente-para-API».

Agora traduza-se isso para linguagem simples de infraestrutura.

A Visa e a Mastercard estão a dizer: a nossa rede fica no meio, mas aquilo que a invoca está agora rotulado como «agente» em vez de «navegador» ou «app». O carril de pagamento não mudou. A portagem não se moveu. O rótulo no veículo que passa é a única coisa diferente.

A versão da Stripe é ainda mais transparente. «Execução de checkout agente-para-API» é o que acontece de cada vez que um script chama um endpoint de pagamento. Os programadores têm vindo a construir isto há anos. A API existia ontem. A palavra «agente» chegou hoje.

A Google é mais ambiciosa — quer possuir a camada de descoberta, a intenção e a orquestração. É uma jogada estratégica genuína. Mas o checkout em si? Continua a ser uma chamada de API no fim da cadeia.

Isto não é uma crítica a estas empresas. Estão a fazer o que os grandes jogadores fazem sempre: posicionar infraestrutura para a próxima onda. A pergunta é se a onda é tão nova quanto o vocabulário sugere.


O padrão que se repete sem parar

Não é a primeira vez que a indústria tecnológica reembala capacidades existentes sob nova terminologia. Pode ser o exemplo mais visível neste momento, mas o padrão dura há décadas.

Os microserviços eram a resposta à arquitetura monolítica. Cada conferência, cada whitepaper, cada pitch de consultoria dizia o mesmo: parte o monólito, faz deploy de forma independente, escala horizontalmente. O conceito tinha mérito genuíno. O que se seguiu foi uma corrida a decompor tudo em centenas de pequenos serviços — muitas vezes sem a governação, a observabilidade ou a maturidade operacional para gerir a complexidade resultante. Organizações que tinham um sistema para monitorizar passaram de repente a ter duzentos, a chamarem-se uns aos outros em padrões que estavam documentados em teoria mas eram incognoscíveis na prática.

A capacidade subjacente — componentes de software modulares, com deploy independente — não era nova. O Unix fora construído sobre esse princípio desde a década de 1970. O que era novo era o marketing, o ecossistema de ferramentas e a receita de consultoria que o rodeava.

A migração para a cloud seguiu um arco semelhante. «Mudar para a cloud» tornou-se um imperativo estratégico. A promessa: escalabilidade elástica, menor peso operacional, economia de pagar-pelo-que-se-usa. A realidade, em muitas empresas: as mesmas aplicações, a correr nos servidores de outra pessoa, com um modelo de facturação diferente e uma nova categoria de complexidade operacional para a qual as equipas existentes não estavam preparadas. As organizações que mais beneficiaram foram as que rearquitetaram para a cloud. As que simplesmente migraram — «lift and shift» — acabaram muitas vezes por pagar mais por aproximadamente a mesma coisa.

O blockchain foi talvez o exemplo mais extremo. Entre 2016 e 2019, a tecnologia de registo distribuído foi posicionada como a solução para a transparência da cadeia de abastecimento, a liquidação financeira, a verificação de identidade, os sistemas de voto, e praticamente todos os outros domínios onde a confiança era um fator. A tecnologia em si — verificação criptográfica de transações sequenciais — tem casos de uso genuínos e estreitos. O que não tinha era a aplicabilidade universal que a narrativa de mercado insistia. A distância entre o que o blockchain conseguia fazer e o que era vendido como fazendo media-se em milhares de milhões de dólares de investimento.


O que muda de facto vs. o que é apenas rerrotulado

Há uma distinção útil que tende a perder-se nestes ciclos: a diferença entre uma nova capacidade e uma nova interface para uma capacidade existente.

Uma capacidade genuinamente nova muda o que é possível. LLMs a raciocinar através de problemas ambíguos e não-estruturados — isso é novo. Uma máquina que consegue interpretar «preciso de algo para a minha mulher, que adora jardins mas não flores cortadas, abaixo de 50 €, entregue até sábado» e produzir uma resposta útil — isso não existia há cinco anos. É uma verdadeira mudança no que a tecnologia consegue fazer.

Uma nova interface para uma capacidade existente muda como algo é acedido, não o que faz. Chamar uma API de pagamento a partir de um «agente» em vez de a partir de um formulário web é uma nova interface. O pagamento continua a fluir pela mesma rede, o mesmo processo de liquidação, o mesmo quadro de conformidade. A capacidade — processar uma transação — está inalterada. Quem chama tem um nome novo.

A maior parte do que se comercializa como «agêntico» hoje cai na segunda categoria. Os sistemas subjacentes — carris de pagamento, plataformas de comércio, redes de logística — permanecem funcionalmente idênticos. O que mudou foi a porta de entrada.

Isto importa porque o investimento, a atenção e a urgência dirigidos ao «comércio agêntico» ou aos «fluxos agênticos» são muitas vezes dimensionados como se tivesse emergido uma nova capacidade, quando o que de facto aconteceu foi um rebranding da camada de acesso.


O custo que raramente se discute

Quando uma indústria adota um novo vocabulário para capacidades existentes, as consequências económicas são reais mas distribuídas de formas que as tornam difíceis de atribuir.

As organizações investem em iniciativas de «transformação agêntica» que, quando auditadas, são projetos de integração de APIs com um nome diferente e um orçamento maior. Os profissionais investem tempo e dinheiro em certificações e formação para frameworks que são camadas finas sobre padrões estabelecidos. Os circuitos de conferências enchem-se de sessões sobre o «futuro agêntico» que poderiam ser rebatizadas «orquestração de APIs» sem mudar um único slide.

Entretanto, o trabalho genuinamente difícil — o trabalho que de facto prepararia as organizações para capacidades de AI que são verdadeiramente novas — tende a ser adiado. Limpar dívida técnica, documentar conhecimento tribal, construir os quadros de observabilidade e governação que os sistemas autónomos reais acabarão por exigir. Este trabalho é caro, lento, sem glamour, e não gera o tipo de anúncios que atraem aprovação de orçamento.

O ciclo de rebranding não se limita a rotular mal o que existe. Desvia ativamente atenção e recursos daquilo que é preciso.


Por que o padrão persiste

Seria fácil enquadrar isto como cinismo ou desonestidade, mas a realidade é mais estrutural do que isso.

As grandes empresas tecnológicas precisam de narrativas de crescimento. «Melhorámos a documentação da nossa API» não move cotações. «Estamos a construir a infraestrutura para o comércio agêntico» move. O incentivo para posicionar produtos existentes dentro de novas narrativas é racional, mesmo que a narrativa inflacione o que é de facto novo.

As consultoras e os integradores de sistemas precisam de justificação para os projetos. «A sua integração atual funciona bem» não gera receita. «Precisa de uma estratégia de comércio agêntico» gera. Mais uma vez, a estrutura de incentivos recompensa o reenquadramento em vez da avaliação honesta.

Os profissionais individuais precisam de relevância de carreira. «Faço a gestão de integrações de APIs» soa a manutenção. «Arquiteto fluxos agênticos» soa a inovação. O mesmo trabalho, descrito de forma diferente, tem valor de carreira diferente. O incentivo para adotar nova terminologia — mesmo quando o trabalho subjacente não mudou — é inteiramente racional ao nível individual.

Nenhum destes atores está errado em seguir os seus incentivos. Mas o efeito agregado é uma indústria que confunde regularmente mudança de vocabulário com mudança de capacidade, e aloca recursos em conformidade.


O aspeto da evolução verdadeira

A verdade incómoda é que a evolução tecnológica genuína raramente é entusiasmante da forma que o mercado quer que seja.

A evolução real tem o aspeto de uma organização a passar 18 meses a limpar duas décadas de dependências não documentadas — para que, quando os sistemas autónomos reais chegarem, tenham algo coerente sobre que operar.

Tem o aspeto de uma equipa a passar seis meses a construir observabilidade a sério na sua infraestrutura — não porque está na moda, mas porque não se consegue governar o que não se consegue ver.

Tem o aspeto de um profissional a investir tempo em compreender como os LLMs de facto raciocinam — os seus modos de falha, os seus padrões de confiança, as suas limitações — em vez de aprender a sintaxe de API da framework que será descontinuada dentro de 14 meses.

Tem o aspeto de uma avaliação honesta que diz: «Esta tecnologia é genuinamente nova. Esta outra coisa é um rótulo novo em algo que já fazemos. Invistamos proporcionalmente.»

Este tipo de evolução não é tendência no LinkedIn. Não enche salas de conferência. Não gera posts de blogue ofegantes. Mas é o trabalho que determina se as organizações estão de facto prontas para o que aí vem — ou apenas prontas para falar disso.


A conclusão

A indústria tecnológica tem um padrão crónico: rebatizar capacidades existentes, comercializar o nome novo como transformação, e redirecionar o investimento para a mudança de vocabulário em vez do trabalho estrutural que a transformação genuína exige.

Isto não é exclusivo do «comércio agêntico». Aconteceu com os microserviços, a cloud, o blockchain, e acontecerá com o que quer que venha a seguir. O padrão persiste porque a estrutura de incentivos o recompensa a todos os níveis — fornecedores, consultores e indivíduos por igual.

A resposta útil não é o cinismo. É a calibração. Quando aparece um termo novo, a primeira pergunta que vale a pena fazer é: que capacidade é de facto nova aqui, e o que é um rótulo novo em algo que já existe? A resposta determina para onde o tempo, o dinheiro e a atenção devem de facto ir.

As organizações e os profissionais que aprenderem a distinguir mudança de vocabulário de mudança de capacidade serão os que investem no que importa — e evitam pagar preços de inovação por rebranding.


Qual é a sua experiência? Está a ver capacidades genuinamente novas naquilo que é comercializado como «agêntico» — ou sobretudo padrões familiares com terminologia atualizada? As histórias reais são sempre mais interessantes do que os comunicados de imprensa.