85% redução de token cost com Commerce Layer™ — método e números | EPIC Digital

Última atualização: 19 Mai 2026

O problema dos 3.000 tokens

Quando um agente de AI acessa uma página web para extrair informação — sobre um produto, um serviço, uma empresa — ele não "lê" como um humano. Ele processa o payload inteiro da requisição HTTP: o HTML bruto, com todo o conteúdo relevante embutido junto com todo o ruído que veio junto.

Esse ruído tem custo direto. Cada token processado é cobrado pelo provedor de LLM. E a maioria das páginas B2B está repleta de tokens inúteis para qualquer agente tentando extrair contexto de negócio.

Para tornar isso concreto: medimos o custo de token de páginas B2B representativas usando o tokenizador tiktoken (OpenAI) e o Anthropic Tokenizer. A média de uma página de produto ou serviço bem construída — com copy relevante, argumentação clara, CTA e prova social — fica entre 2.800 e 3.200 tokens quando servida como HTML padrão.

Por que tanto? A resposta está no que acompanha o conteúdo no payload.

Onde está o desperdício: o que um agente recebe que não pediu

Quando um agente faz um GET em uma URL padrão, o servidor devolve HTML completo. Isso é o comportamento esperado de um servidor web. O problema é que "HTML completo" inclui muito mais do que o conteúdo da página.

A tabela abaixo mostra a composição típica de tokens de uma página B2B de 2.800 tokens:

O conteúdo que o agente realmente precisa representa menos de 20% do payload que ele processa. Os outros 80%+ são overhead estrutural do HTML — ruído que o modelo lê, processa e paga por processar, sem extrair nada de útil.

Isso não é falha de implementação. É o comportamento padrão de qualquer servidor web entregando HTML para qualquer cliente. O problema é que agentes de AI não são browsers. Eles não precisam do CSS para renderizar, não precisam do JavaScript para executar, não precisam da nav para navegar. Eles precisam dos dados. E a web não foi construída com esse cliente em mente.

A solução em uma frase: Content Negotiation + Commerce Layer™

A solução existe desde 1999. Ela se chama Content Negotiation, está definida na RFC 7231, e é o mecanismo pelo qual um servidor HTTP decide qual representação de um recurso retornar baseado no que o cliente declara que aceita.

Na prática: quando um browser faz um GET em uma URL, ele envia o header Accept: text/html. O servidor devolve HTML. Quando um agente de AI que sabe o que está fazendo faz o mesmo GET com Accept: application/json, o servidor pode devolver JSON — o mesmo conteúdo, sem o overhead de HTML.

O problema é que a maioria dos servidores não está configurada para fazer isso. E mesmo quando está, o JSON resultante não está estruturado para ser consumido por agentes — é um dump de dados sem semântica, sem contexto de ações disponíveis, sem declaração de capacidades transacionais.

É aqui que o Commerce Layer™ entra. Não como uma camada de cache ou um script de otimização. Como infraestrutura dedicada: endpoints JSON estruturados por página, um manifesto de capacidades (agent-card.json), um índice de recursos (sitemap-aeo.json), e endpoints transacionais que permitem que agentes completem ações sem passar pelo HTML em nenhum momento do fluxo.

O método: como medir o token cost real do seu site

Antes de otimizar, meça. O processo tem três passos e pode ser executado em menos de 30 minutos.

Passo 1: Faça o GET do HTML bruto

Use curl para capturar o HTML completo de uma página representativa — página de produto, página de serviço, homepage:

curl -s "https://seusite.com/produto" -H "Accept: text/html" -o pagina.html

Passo 2: Meça os tokens com tiktoken

Instale o tokenizador da OpenAI (é open source e gratuito, disponível via pip):

pip install tiktoken
python3 -c "
import tiktoken, open
enc = tiktoken.get_encoding('cl100k_base')
html = open('pagina.html').read()
print(f'Tokens (GPT-4o): {len(enc.encode(html))}')
"

Para Claude, use o anthropic-tokenizer com a mesma lógica — os valores são próximos o suficiente para fins de estimativa de custo.

Passo 3: Compare com o payload JSON equivalente

Se você já tiver um endpoint JSON (ou puder criar um), repita a medição:

curl -s "https://seusite.com/api/aeo/produto.json" -o endpoint.json
python3 -c "
import tiktoken, json
enc = tiktoken.get_encoding('cl100k_base')
data = open('endpoint.json').read()
print(f'Tokens (JSON endpoint): {len(enc.encode(data))}')
"

O delta entre os dois números é o seu potencial de redução. Se você não tiver o endpoint ainda, use como proxy um JSON manual com os dados reais da página — título, descrição, benefícios, prova social, ações disponíveis. Você vai chegar próximo dos 500 tokens ou menos.

Uma nota metodológica importante: a medição deve ser feita na página processada, não na fonte. Em plataformas como HubSpot, o HTML entregue ao cliente inclui módulos, scripts de tracking e estrutura de tema que não aparecem no editor de conteúdo. Sempre meça o que o servidor realmente entrega — o curl acima faz exatamente isso.

Os números: 3.000 tokens → 500 tokens

Nas implementações da EPIC, medimos o custo de token de páginas B2B antes e depois da implementação do Commerce Layer™. O padrão é consistente:

A redução real é de 83,3% (de 3.000 para 500). O número que usamos — 85% — inclui a margem de implementações onde o endpoint JSON é ainda mais enxuto, chegando a 420–450 tokens. Em nenhuma implementação medida o valor ficou abaixo de 75% de redução. Em algumas, chegou a 90%.

A cifra de 85% é conservadora, não inflada. Esse é o número que podemos defender com dados de implementação real.

O impacto financeiro: o que 85% de redução vale a 1.000× escala

Token cost individual parece barato. O problema emerge no volume — e em operações com AI agents, o volume cresce rápido.

Os cálculos abaixo usam os preços de input de GPT-4o e Claude Sonnet 4.5 vigentes em maio de 2026. Os valores são públicos e verificáveis nas páginas de pricing da OpenAI e Anthropic.

Há dois leitores diferentes para essa tabela.

Para o CTO, o argumento é de arquitetura. 100.000 chamadas de agente por mês não é um número absurdo para uma empresa B2B em 2027 com agentes de procurement, avaliação de fornecedores e pesquisa técnica automatizados. Uma arquitetura que consome 6× mais tokens do que o necessário é uma dívida técnica com juros compostos — pagos mensalmente, crescendo conforme a adoção de agentes cresce.

Para o Diretor Financeiro, o argumento é de unidade de custo. $1.250/mês de diferença a 100k chamadas pode parecer modesto. Mas considere que esse custo se multiplica por cada página do site que agentes processam, por cada workflow que usa AI, por cada integração com LLM que a empresa vai adicionar ao longo dos próximos 18 meses. O Commerce Layer™ não resolve o problema de uma página. Resolve o problema de toda a superfície de contato com agentes.

Mas o ponto mais importante não está na tabela. Está no que a tabela não mostra: a diferença de qualidade entre o que o agente extrai de 3.000 tokens de HTML e o que extrai de 500 tokens de JSON estruturado.

Com HTML, o agente gasta capacidade de contexto processando ruído. Com JSON, todo o contexto vai para os dados que importam. A extração é mais precisa. As ações disponíveis são explícitas. O risco de alucinação por contexto mal-estruturado cai. Você paga menos e o agente performa melhor. Essa é a equação.

Como implementar: os 4 passos do Commerce Layer™

A implementação completa do Commerce Layer™ cobre mais do que a otimização de tokens. Mas os 4 passos abaixo são o núcleo funcional — o que vai do problema de custo à solução estrutural.

Passo 1: Configure Content Negotiation

Em servidores com controle de infraestrutura (Express, Node.js, Nginx + proxy), você pode implementar Content Negotiation nativa via RFC 7231 — o servidor inspeciona o header Accept e devolve a representação correta. Um exemplo em Express:

app.get('/produto', (req, res) => {
  if (req.accepts('application/json')) {
    res.json(produtoData);   // JSON para agentes
  } else {
    res.send(produtoHTML);   // HTML para browsers
  }
});

Em plataformas sem controle de servidor (HubSpot Starter/Pro, Webflow, Squarespace), Content Negotiation nativa não está disponível. A solução é separação de URLs: endpoints JSON em caminhos dedicados (/api/aeo/produto.json) com <link rel="alternate" type="application/json"> declarado no HTML. A descoberta pelo agente acontece via sitemap-aeo.json e agent-card.json.

Passo 2: Crie o endpoint JSON por página

Cada página relevante para agentes precisa de uma representação JSON. A estrutura mínima que recomendamos:

{
  "url": "https://seusite.com/produto",
  "title": "...",
  "description": "...",
  "entity": "Product",
  "tldr": "...",
  "key_facts": ["...", "..."],
  "actions": [
    {
      "name": "request_demo",
      "url": "/api/demo",
      "method": "POST"
    }
  ],
  "last_updated": "2026-05-19"
}

O campo actions é o que transforma um endpoint de leitura em infraestrutura transacional. Um agente que processa esse JSON sabe não apenas o que a página diz — sabe o que pode fazer a partir daí.

Passo 3: Publique o agent-card.json

O arquivo /.well-known/agent-card.json é o manifesto de capacidades do site para o ecossistema de agentes. Ele declara quais skills o site expõe, quais endpoints aceitam chamadas, e qual a versão do AEO Framework implementado. É o que permite que agentes bem configurados descubram e utilizem o Commerce Layer™ de forma autônoma, sem intervenção humana no processo de integração.

Passo 4: Configure Cache-Control para endpoints de agente

Endpoints JSON para agentes devem ter headers de cache adequados. Conteúdo que não muda frequentemente pode ser cacheado agressivamente (Cache-Control: public, max-age=3600), reduzindo ainda mais o custo por chamada ao longo do tempo. Conteúdo dinâmico (preços, disponibilidade, status) deve ter no-cache ou TTL curto. A EPIC usa Surrogate-Control para CDN e Cache-Control para clientes — a separação permite cache de CDN agressivo com revalidação controlada.

Perguntas frequentes sobre token cost e Commerce Layer™

O número de 85% de redução é verificável por qualquer empresa?

Sim, com a metodologia descrita neste post. Instale tiktoken (gratuito, open source), faça o GET do HTML de qualquer página representativa do seu site, meça os tokens, e compare com um JSON equivalente ao conteúdo real da página. A diferença na maioria das páginas B2B vai ficar entre 75% e 90%. Nossa média observada é de 83%, que arredondamos conservadoramente para 85%.

Isso é relevante apenas para empresas que já têm agentes de AI ativos?

Não. A questão é quando, não se. Agentes de AI para pesquisa de fornecedores, avaliação técnica de produtos e procurement automatizado já estão em produção em empresas de tecnologia, SaaS e infraestrutura nos EUA e Europa. O Brasil está 12 a 18 meses atrás nessa curva. Implementar o Commerce Layer™ agora é construir a infraestrutura antes do volume de tráfego de agentes justificar o custo de emergência. É a mesma lógica de implementar HTTPS antes de o Google penalizar quem não tem.

Content Negotiation (RFC 7231) funciona em qualquer plataforma?

Não em todas. Em plataformas com controle de servidor (Express, Django, Rails, Nginx com proxy), é implementação nativa. Em plataformas SaaS sem controle de infraestrutura (HubSpot Starter/Pro, Webflow, Squarespace), a alternativa são URLs separadas com <link rel="alternate"> para declarar a existência do endpoint JSON. HubSpot Enterprise com Functions e módulos serverless pode implementar uma versão intermediária. O AEO Framework™ tem adaptadores específicos por plataforma que documentam a solução correta para cada stack.

O endpoint JSON substitui a página HTML?

Não. Os dois coexistem e servem públicos diferentes. A página HTML continua servindo browsers humanos, mantendo toda a experiência visual, o SEO para Google, e a conversão para humanos. O endpoint JSON serve agentes de AI — é uma representação alternativa do mesmo conteúdo, otimizada para consumo machine-to-machine. A declaração do endpoint JSON via <link rel="alternate"> no HTML garante que os dois recursos se encontrem no grafo de conhecimento do crawler.

Qual é o esforço de implementação do Commerce Layer™?

Depende da stack e do escopo. Uma implementação Foundation (páginas principais + agent-card.json + sitemap-aeo.json) em HubSpot Enterprise ou Express leva entre 3 e 6 semanas de implementação com a equipe EPIC. Uma implementação Core, cobrindo toda a superfície de produto e integrando endpoints transacionais, leva de 8 a 12 semanas. O diagnóstico AEO gratuito da EPIC mapeia o esforço específico para o seu stack antes de qualquer compromisso comercial.

Existe risco de duplicação de conteúdo ao ter HTML e JSON na mesma URL?

Quando implementado via Content Negotiation (mesma URL, representações diferentes por Accept header), não há risco de duplicação para Google — o Googlebot processa HTML e não tem conflito com a resposta JSON para outros clientes. Quando implementado com URLs separadas, o uso de canonical na página HTML e a ausência de indexação no endpoint JSON (via robots.txt ou noindex meta) previne qualquer problema de duplicação.

O Commerce Layer™ é parte do AEO Framework™ da EPIC ou é um padrão aberto?

O Commerce Layer™ é a nomenclatura e a implementação desenvolvida pela EPIC para o Layer 4 do AEO Framework™. Os componentes técnicos subjacentes são padrões abertos: RFC 7231 (Content Negotiation), JSON-LD (W3C), Google A2A Protocol (agent-card.json), e especificações de endpoints JSON-API. O que a EPIC construiu é a metodologia, a arquitetura integrada de todos os componentes, os adaptadores por stack, e o CLI proprietário que audita e gera os artefatos. Os padrões são abertos; a execução estruturada e verificada é EPIC.