L4Commerce Layer · Agent Card + MCP + A2A11 checks

L4 — Commerce Layer™: o seu site como canal de transação para agentes autônomos, não apenas como brochure para humanos

L0 a L3 tornam o site legível e citável por máquinas. L4 torna o site acionável — agentes autônomos podem solicitar cotação, agendar demo e comparar preços sem intervenção humana.

TL;DR

Commerce Layer é a camada que diferencia um site que é consumido por máquinas de um site que é acionado por máquinas. A diferença tem a mesma magnitude do salto de brochure para e-commerce no início dos anos 2000 — só que agora o comprador é uma máquina. Um agente autônomo (ChatGPT Action, Claude com MCP, agente A2A) pode descobrir o site via Agent Card, entender suas capacidades, e executar ações reais. Menos de 5% dos sites B2B têm qualquer componente de Commerce Layer em 2026.

O que é

A diferença entre ser citado por máquinas e ser usado por máquinas

Commerce Layer é a camada que diferencia um site que é consumido por máquinas de um site que é acionado por máquinas. A diferença tem a mesma magnitude do salto de brochure para e-commerce no início dos anos 2000 — só que agora o comprador é uma máquina.

Um agente autônomo (ChatGPT Action, Claude com MCP, agente A2A) pode descobrir o site via Agent Card, entender suas capacidades, e executar ações reais. Diferença entre ser uma referência que o agente cita e ser um canal que o agente usa.

Por que importa

Os quatro dados que definem a janela de vantagem

<5%
Sites B2B com Commerce Layer em 2026
85%
Redução de token cost com endpoint JSON vs HTML
150+
Organizações fundadoras do Google A2A Protocol
  • Google A2A Protocol (Abr/2025, 150+ orgs fundadoras) estabeleceu agent-card.json em /.well-known/ como ponto de entrada canônico. Sites sem Agent Card são invisíveis para o protocolo.
  • MCP (Model Context Protocol, Anthropic Nov/2024) é padrão para LLMs acessarem ferramentas externas. ChatGPT, Claude Desktop e Gemini suportam first-class em 2026.
  • Token cost: 85% de redução. HTML médio: ~3.000 tokens. Endpoint JSON equivalente: < 500 tokens. Agentes preferem fontes eficientes.
  • Primeiro a implementar em um setor captura posição. < 5% dos sites B2B têm qualquer componente de Commerce Layer em 2026.
Como medimos

11 checks — do Agent Card ao endpoint abaixo de 500 tokens

11 checks em L4 — Agent Card válido em /.well-known/agent-card.json, sitemap-aeo.json acessível, pelo menos 1 endpoint transacional funcional, <link rel="alternate"> apontando para JSON, llms.txt referenciando Agent Card, endpoints < 500 tokens.

Score sem AEO0
Após implementação75–95
Como implementamos

5 passos — 6h para o trio + 8–15h por endpoint transacional

  1. 01
    Geramos o trio de arquivos via aeo generate <url> (llms.txt + agent-card.json + sitemap-aeo.json). EPIC refina com contexto real. (~3–4h)
  2. 02
    Definimos endpoints transacionais com o cliente — RequestQuote, BookDemo, GetPricing, OrderAction. (~2–4h de definição)
  3. 03
    Publicamos conforme stack — HubSpot: URL Mappings + Serverless (Enterprise); Express/Node.js: rotas nativas + Content Negotiation RFC 7231. Static sites: ~40% compat. (~6–15h por endpoint)
  4. 04
    Adicionamos <link rel="alternate" type="application/json"> no <head> de cada página. (~1h)
  5. 05
    Testamos com curl -H "Accept: application/json" + simulação de agente A2A. (~1–2h por endpoint)

Esforço total: 6–10 horas para o trio + 8–15h por endpoint transacional.

Governança

Governança e segurança nos endpoints transacionais

Endpoints transacionais para agentes autônomos não podem ser open by default. Para clientes B2B enterprise, EPIC aplica cinco controles como padrão:

  1. A1
    Autenticação por token — agentes autenticam via API key ou OAuth2 client credentials. Sem token válido, endpoint retorna 401. Tokens scoped por skill (agente A pode pedir cotação mas não agendar demo).
  2. A2
    Rate limiting por agent identity — header X-Agent-ID ou claim no token identifica o agente; quotas configuráveis por agente, skill e janela de tempo. Mitiga abuso, protege capacidade.
  3. A3
    Validação humana opcional — cada skill no Agent Card pode setar requires_human_approval: true. Agente recebe status: pending_human_review, transação fica em fila no CRM aguardando aprovação.
  4. A4
    Audit logs com retenção — toda chamada (request body, agent identity, timestamp, response, outcome) é loggable e retenível por 90 dias configurável. Trilha de auditoria para compliance, debugging, LGPD/GDPR DSAR.
  5. A5
    Scope restrito por declaração — agentes só conseguem invocar skills explicitamente listadas no Agent Card. Endpoints não declarados retornam 404 mesmo se existirem internamente. Princípio de menor privilégio aplicado por design.

Implementação: HubSpot CMS Enterprise ou infraestrutura externa (Express + Quave, Cloudflare Workers, Vercel Edge). HubSpot CMS Pro suporta L4 com endpoints read-only; transações reais com governança completa exigem tier superior ou edge worker.

Caso anchor

Combined Score 93,1 — primeiro end-to-end L0 a L6 no portfólio

Empresa de tecnologia B2B com produto AI-native

Primeira a implementar Commerce Layer completo com a EPIC. Agent Card com 3 ações executáveis. Combined AEO Score: 93,1/100. Site passou a receber requisições de agentes. Layer 6 deployada na mesma sprint. Único caso end-to-end L0 a L6 no portfólio.

FAQ

Perguntas frequentes sobre L4

Parcialmente, dependendo do tier. HubSpot Pro: o trio base (llms.txt + agent-card.json + sitemap-aeo.json) pode ser publicado via URL Mappings e Custom HTML. Endpoints transacionais reais requerem HubSpot Enterprise (Serverless Functions). Para o Commerce Layer completo em HubSpot Pro, a solução é um proxy leve no Cloudflare Workers — avaliamos isso no audit.
São URLs que aceitam requisições HTTP e retornam JSON estruturado. Exemplos: GET /api/aeo/quote?service=core retorna estimativa de escopo. POST /api/aeo/demo agenda demonstração. GET /api/aeo/services lista serviços com metadados para agentes. Um agente autônomo pode descobrir esses endpoints via Agent Card e executar ações sem que um humano precise clicar em nada.
Sim e não. L0 e L4 são frequentemente implementados juntos no bundle Foundation porque compartilham arquivos: o llms.txt de L0 referencia o agent-card.json de L4, e o robots.txt de L0 permite os bots que vão usar L4. Tecnicamente você pode publicar o agent-card.json sem L0 completo, mas o discovery de agentes será incompleto.