O que vamos cobrir em cinco partes.

Se alguma dessas três frases te incomodar, é sinal de que vale ficar mais 40 minutos.

é a taxa de deployment de agentes de IA em Q4 de 2025, queda de 16 pontos percentuais em relação ao Q3. Mais agentes foram desligados do que colocados em produção no último trimestre.

Fonte: KPMG GenAI Tracker, Q4 2025. Amostra de 1,200 empresas Fortune 2000 globalmente.

Diretoria acredita em uma coisa. A realidade do deployment é outra.

Fontes: KPMG CEO Outlook 2025 (confiança), KPMG GenAI Tracker Q4 2025 (deployment). O gap explica por que boards estão pedindo "strategy resets" em 2026.

é a diferença de dificuldade entre tarefas de bug fix e tarefas de feature real. POCs que demonstram bug fix superestimam a capacidade do agente em produção por um fator de sete.

Fonte: FeatureBench, paper aceito em ICLR 2026. Claude Opus 4.5 atinge 74,4% em SWE-bench (bugs) e apenas 11,0% em FeatureBench (features).

Dos 42 POCs que a sua empresa vai financiar este ano, 1 vai gerar receita.

Funil típico observado em clientes enterprise que operamos em 2024-2025. O ponto não é que a taxa seja baixa, é que ela é previsível quando as quatro camadas não estão em lugar.

Quatro perguntas que a maioria das empresas falha em responder com precisão.

As falhas são previsíveis. Três causas raiz explicam 80% dos casos.

Observe o padrão: as três causas ignoram as camadas 01, 03 e 04. Organizações tendem a investir pesado na camada 02 (platform engineering) e achar que já está resolvido. Não está.

The Context Platform Stack.

O que sobe e o que desce em cada fronteira.

Tratar agentes como microserviços é o erro mais comum, e o mais caro.

Arquitetura de quatro planos, publicada pela CNCF Working Group em 2025.

Referência: CNCF WG Platforms, "Cognitive Platform Engineering Reference Architecture", 2025.

Os cinco padrões que você precisa reconhecer em 2026.

A maioria dos times só rastreia compute. O compute é menos da metade do custo real.

O diagnóstico inicial em qualquer cliente: quais desses cinco você tem dashboard para? Se a resposta é "só o primeiro", seu TCO de agente está errado por um fator de dois.

A topologia de pod de agente tem quatro containers, não um.

O pod não é um container. É quatro, deployados juntos, com contratos bem definidos. Essa é a primeira decisão de platform engineering que define se o agente vai escalar ou não.

Os quatro pilares de controle, agora aplicados a agentes.

Os quatro pilares existiam antes de agentes. O que muda é que agora todos os quatro precisam considerar o agente como primeiro consumidor, não como afterthought de um portal humano.

O IDP agêntico tem sete componentes. Só dois deles mudam vs IDP de dev.

Ferramentas comuns: Backstage (Spotify), Port, Humanitec. Os dois blocos em amarelo são o que transforma um IDP comum em agent-ready. Sem eles, o IDP é bom para humanos e invisível para agentes.

Quando o consumidor primário é um agente, toda a ergonomia do IDP muda.

RBAC tradicional dá permissão a pessoas. RBAC agêntico dá permissão a agentes.

Cada linha é um SPIFFE SVID diferente. Cada célula é uma policy em OPA. Aprovação humana no meio da matriz é feature, não workaround.

Context engineering não é prompt engineering com mais passos.

Prompts são táticas. Contexto é estratégia. Organizações que tratam as duas como a mesma disciplina confundem decisões do tech lead com decisões do desenvolvedor, e a confusão sempre custa tokens.

Hot, warm, cold. Cada camada tem orçamento de tokens e política de atualização distintos.

A soma dos três orçamentos dá 4160 tokens em uma invocação típica. O agente bem engenheirado não excede isso. O agente mal engenheirado carrega tudo em hot e paga 30 mil tokens por tarefa trivial.

108 mil linhas de C#, 283 sessões de agente, 32% de tokens economizados.

AGENTS.md gerado por LLM é contraproducente. Curadoria humana bate geração automática.

Experimento controlado em 47 repositórios internos, mesmo agente, três condições de AGENTS.md. Curadoria humana vence porque LLMs ainda não distinguem o que é "tacit knowledge" do time do que é redundante com código-fonte.

Arquitetura MCP real, não o diagrama de vendor.

Pontos críticos: o gateway é PEP (enforcement), o registry é PDP (decision), os servers são minimalistas, a observabilidade é primeiro cidadão. Se você removeu o gateway porque "adiciona latência", você removeu o RBAC.

A pirâmide de quatro níveis, do prompt à especificação.

A maioria das empresas investe no nível 01 e deixa 02-04 implícitos. A hierarquia é cumulativa, nível 04 só funciona se 01-03 estiverem explícitos.

O CONSTITUTION.md tem cinco seções. Todas não negociáveis.

# Identity
You are "code-review-agent", reviewing PRs in the
enterprise-backend monorepo.

# Values, in priority order
1. Correctness of production behavior
2. Security, specifically authz and secrets
3. Test coverage on changed lines
4. Style and idiom, last

# Hard constraints
NEVER approve a PR that adds a new dependency
  without an explicit license check comment.
NEVER suggest code that disables authentication,
  even for test paths.

# Protocol on ambiguity
If intent of change is unclear after 2 passes,
  comment "clarification needed" and escalate
  to human reviewer via @team-lead mention.

# Escalation hooks
Escalate if PR touches auth/, billing/ or crypto/.
Escalate if diff size exceeds 800 lines.

Intent debt, a dívida entre o que você disse que o agente deve fazer e o que ele está fazendo.

Specification Driven Development, escrito em EARS, é testável por máquina.

// EARS pattern, Ubiquitous
The system shall emit a telemetry event
for every agent decision.

// EARS pattern, Event-driven
When a network call fails 3 times in 60s,
the system shall open circuit breaker.

// EARS pattern, State-driven
While circuit is open,
the system shall serve cached responses
for up to 30 seconds.

// EARS pattern, Optional feature
Where context cache is enabled,
the system shall skip KB queries on
identical requests within 120 seconds.

A pilha só funciona como pilha. Cada camada depende da camada abaixo.

Pular camadas não funciona. Tentar fazer intent engineering sem context engineering é como escrever contrato em uma língua que ninguém fala.

Sua maturidade é o mínimo das quatro camadas, não a melhor prática de uma.

O diagnóstico que aplicamos em clientes coloca ~64% das empresas em estágio 02. O salto mais caro é 02 para 03, porque exige enfrentar as três camadas que foram ignoradas.

Avalie sua organização agora. Uma pergunta por camada, resultado em tempo real.

Tarefas de feature são 7× mais difíceis que bug fixes. Hype esconde isso.

Claude Opus 4.5, benchmark padronizado. Pilotos em "bug fix" overestimam capacidade por 7× quando extrapolados para feature work. O contexto da camada 03 fecha parte dessa lacuna, não toda.

Quatro anti-padrões que você vai encontrar antes de qualquer boa prática.

Modos de falha agrupados por camada. Se você sabe o sintoma, sabe onde debugar.

Diagnóstico inicial: qual desses sintomas você vê hoje? A camada do sintoma é a camada onde você precisa investir primeiro, não necessariamente a que você achava que era o problema.

Cinco coisas que você pode fazer na segunda-feira, sem novo orçamento.

30 / 60 / 90 dias. Uma mudança mensurável por período, não cinco.

Não tente fazer as quatro camadas em um agente. Faça uma camada em quatro agentes, depois profunde. A ordem certa de ataque depende do diagnóstico dos dias 1-30.

Do piloto à plataforma, em quatro trimestres.

Clientes que perseguiram este roadmap em 2025 reportam taxa de deployment de 62%, não 26%. O diferencial não é tecnologia, é disciplina de camada.