Eu comecei a levar context engineering a sério no momento em que percebi que os agentes falhavam do mesmo jeito que sistemas mal projetados falham.
Na demo, tudo parecia funcionar. O agente entendia a tarefa, encontrava arquivos, sugeria mudanças razoáveis e até parecia “lembrar” do que eu tinha dito antes. Mas, quando eu colocava esse mesmo agente em um fluxo maior — uma investigação de incidente, um refactor longo, uma tarefa com várias ferramentas e sessões sucessivas — o comportamento mudava. Ele esquecia uma restrição importante na sexta interação. Contradizia uma decisão tomada meia hora antes. Trazia contexto demais e perdia foco. Ou trazia contexto de menos e começava a preencher lacunas com confiança demais.
Durante um tempo, eu tratei isso como problema de modelo. Hoje, eu acho que isso explica muito pouco.
Os números mais recentes sobre adoção de agentes ajudam a colocar esse incômodo em perspectiva. No relatório State of Agent Engineering, 57% dos respondentes disseram já ter agentes em produção, 32% apontaram qualidade como principal barreira, 20% citaram latência e 89% afirmaram já ter implementado observabilidade para esses sistemas. Quando um problema exige observabilidade, custo, latência e controle de qualidade, ele já deixou de ser só uma curiosidade de IA. Ele virou problema de produção.
É por isso que eu gosto de tratar context engineering menos como uma técnica de prompting e mais como uma camada de arquitetura. A própria Anthropic define context engineering como a progressão natural de prompt engineering: em vez de focar só em escrever a instrução, o trabalho passa a ser curar e manter o conjunto ideal de tokens e informações disponíveis para o modelo durante a inferência. O centro da discussão deixa de ser “o que eu peço” e passa a ser “como eu desenho o ambiente de decisão do agente”.
Prompt engineering continua útil. Só não resolve mais o problema inteiro
Eu não acho que prompt engineering tenha ficado obsoleto. Ele continua sendo valioso para tarefas curtas e discretas. Se eu quero reescrever um texto, gerar um teste unitário, resumir um documento ou pedir uma explicação pontual, o prompt ainda é a principal alavanca.
O problema é que agentes raramente ficam nesse mundo por muito tempo.
No momento em que o modelo deixa de ser uma chamada isolada e passa a operar em múltiplos passos, com histórico, arquivos, ferramentas, memória e continuidade entre sessões, o gargalo muda de lugar. O problema já não é apenas formular bem a instrução. O problema vira decidir o que permanece ativo, o que deve ser persistido fora da conversa, o que deve ser resumido, o que pode ser buscado novamente e o que deveria nem entrar na janela de contexto. A Anthropic insiste justamente nisso: contexto é um recurso finito, e o desafio real está em maximizar a utilidade desse recurso, não em simplesmente enchê-lo.
Foi aí que a definição que mais me ajudou apareceu com clareza:
context engineering é o desenho da memória operacional do agente.
Eu gosto dessa definição porque ela traduz o tema para o vocabulário de arquitetura. Todo sistema sério precisa decidir onde vive o estado transitório, onde vive o estado durável, o que é cache, o que é fonte da verdade, o que é derivado e o que pode ser recalculado. Com agentes, as perguntas são as mesmas — só mudam os nomes.
O erro mais comum que eu vejo: tratar contexto como despejo, não como interface
Quando o agente começa a errar, a reação mais intuitiva é mandar mais contexto. Mais logs. Mais arquivos. Mais documentação. Mais conversas. Mais prints. Mais tickets. A lógica parece razoável: se ele souber mais, vai errar menos.
Na prática, quase sempre acontece o contrário.
A Anthropic descreve contexto como recurso crítico e finito, e fala explicitamente em retornos decrescentes quando a janela cresce sem curadoria. Em vez de ganhar clareza, o agente começa a sofrer com ruído, perda de foco e piora na utilidade marginal de cada novo bloco de informação. É exatamente o tipo de problema que eu já vi em observabilidade mal desenhada: você tem mais dado, mas não tem mais entendimento.
Foi por isso que eu passei a pensar contexto como interface.
Interface boa não é a que expõe tudo. É a que expõe o que altera a decisão.
Esse ajuste de linguagem parece pequeno, mas muda o artigo inteiro. Em vez de perguntar “quanto contexto cabe?”, eu passei a perguntar “qual é a menor superfície de informação que faz esse agente trabalhar bem?”. Essa pergunta é muito mais arquitetural e conversa diretamente com temas que já apareceram no blog, como Design Modular: O Alicerce das Arquiteturas Evolutivas e Arquitetura Evolutiva: Adaptabilidade Contínua no Desenvolvimento de Software. Nos dois casos, a ideia central é parecida: sistemas melhores dependem de fronteiras melhores.
O ponto em que isso vira arquitetura de verdade
Para mim, context engineering vira claramente arquitetura quando ele começa a tocar em quatro dimensões clássicas de sistema: estado, boundaries, custo e observabilidade.
A primeira é estado. Em tarefas longas, o agente precisa de contexto ativo para a tarefa atual, mas também precisa de memória persistente fora da sessão: decisões, restrições, contratos, handoffs, progresso parcial. Quando isso não existe, o trabalho degrada porque tudo depende do histórico imediato da conversa. A Anthropic trata isso como um problema aberto em agentes de longa duração: trabalhar com consistência através de muitas janelas de contexto ainda exige harnesses, handoffs e artefatos externos.
A segunda é boundary design. Nem toda tarefa precisa de um único agente com tudo misturado. A Anthropic argumenta que as implementações mais bem-sucedidas tendem a usar padrões simples e componíveis, e não grandes frameworks complexos. Para mim, isso é quase uma tradução direta de modularidade: quando eu separo melhor responsabilidades, separo melhor também o contexto.
A terceira é custo. Quando um agente usa muitas ferramentas, schemas e resultados intermediários passam a disputar o mesmo orçamento de contexto. Em um caso publicado pela Anthropic, só carregar as definições de mais de 50 ferramentas via MCP consumia cerca de 72 mil tokens upfront, chegando a 77 mil tokens antes de qualquer trabalho começar. Com busca de ferramentas sob demanda, o contexto inicial caiu para cerca de 8,7 mil tokens, preservando 95% da janela. Esse tipo de número muda completamente a conversa, porque transforma “organização de contexto” em problema explícito de latência e custo.
A quarta é observabilidade. Se quase 9 em cada 10 times já implementam observabilidade para agentes, isso mostra que o problema não é mais “o modelo respondeu bem ou mal”, mas “como esse sistema se comporta ao longo do fluxo”. Em outras palavras: já não basta avaliar saída; é preciso observar degradação de contexto, tool calls inúteis, sessões que explodem de tamanho e padrões recorrentes de perda de foco.
Exemplo 1: um agente de investigação de incidentes
Esse é o primeiro exemplo que eu usaria para explicar o tema a qualquer arquiteto.
Imagine um agente ajudando a investigar um incidente em produção. Se eu modelar isso mal, vou tentar resolver o problema na força bruta: jogo stack trace, logs gigantes, dashboards, ticket, runbook, diretórios do projeto e uma descrição longa na mesma janela. O agente “vê tudo”, mas decide pior.
Se eu modelar melhor, o desenho muda.
O contexto estrutural passa a ser algo estável: como o sistema é dividido, quais serviços são críticos, que eventos são sensíveis, que dependências são mais problemáticas, onde estão runbooks e quais contratos não podem ser quebrados.
O contexto operacional passa a ser apenas o incidente atual: o alerta disparado, o fluxo afetado, dois ou três trechos de log realmente úteis, o dashboard certo e talvez um teste ou contrato.
A memória persistente passa a registrar decisões já tomadas em incidentes anteriores, hipóteses descartadas e padrões conhecidos.
E o contexto instrumental passa a vir das ferramentas: observabilidade, dashboards, tickets, repositório.
Perceba como a discussão muda. O ponto já não é “qual prompt o SRE escreveu”. O ponto é como eu separei estado estável, estado efêmero e fontes consultáveis. É por isso que esse assunto conversa tão bem com Observabilidade e Operações: dando olhos e mãos ao sistema e Fitness Functions: O Coração da Arquitetura Evolutiva: em todos os casos, a tese é parecida — atributos importantes demais para depender de improviso precisam virar parte explícita do sistema.
Exemplo 2: um agente de refatoração longa
O segundo exemplo é um dos meus favoritos porque ele mostra que o problema não é “gerar código”; é preservar continuidade.
Pense em um agente me ajudando a refatorar um módulo de pagamentos ou um fluxo de checkout ao longo de vários dias. Essa tarefa atravessa muitas interações, várias decisões intermediárias e algumas restrições arquiteturais que não podem evaporar.
Se eu deixar tudo depender do histórico da conversa, acontece uma de duas coisas. Ou o histórico cresce demais e o agente perde foco. Ou eu inicio uma sessão nova e ele perde decisões que não deveriam ser redescobertas.
É aqui que context engineering deixa de parecer buzzword e começa a parecer modelagem de sistema. Eu preciso separar o que é contexto ativo da etapa atual da refatoração, o que é memória persistente da iniciativa inteira e o que pode ser buscado novamente quando necessário.
Eu costumo imaginar essa memória persistente contendo coisas como:
- esse fluxo precisa continuar idempotente;
- este contrato externo não pode mudar;
- este comportamento legado foi preservado por motivo regulatório;
- este teste cobre um bug antigo e não deve ser removido.
Sem esse tipo de registro, o agente reabre a mesma discussão várias vezes. Com ele, o trabalho ganha continuidade.
Esse é um excelente ponto para encaixar links internos como Design Modular: O Alicerce das Arquiteturas Evolutivas e Arquitetura Evolutiva: Adaptabilidade Contínua no Desenvolvimento de Software, porque ambos tratam exatamente da capacidade de mudar sem perder integridade.
Exemplo 3: um agente corporativo com muitas ferramentas
Esse talvez seja o exemplo mais forte para convencer um público técnico de que context engineering é arquitetura, não só IA.
Quando eu coloco um agente em um ambiente corporativo, ele tende a precisar de acesso a repositório, wiki, tickets, observabilidade, banco, APIs internas e talvez alguma ferramenta de deploy. O erro mais fácil é tratar tudo isso como se pudesse entrar “de uma vez” no contexto.
Os dados da Anthropic ajudam a mostrar por que isso escala mal. No caso publicado por eles, só as definições de mais de 50 ferramentas via MCP já consumiam cerca de 72 mil tokens upfront; o contexto total chegava a aproximadamente 77 mil tokens antes de qualquer trabalho começar. Com busca de ferramentas sob demanda, esse volume inicial caiu para cerca de 8,7 mil tokens.
Esse exemplo é valioso porque ele transforma a conversa em algo concreto.
Eu já não estou mais discutindo “se o agente é bom”. Estou discutindo:
- quais ferramentas entram no contexto base;
- quais devem ser descobertas sob demanda;
- quais resultados podem ser filtrados fora da janela;
- e quais informações não deveriam nem virar texto.
É aqui que Model Context Protocol (MCP): O Futuro da Interação com Modelos de IA entra muito bem como leitura complementar. O valor do MCP, para mim, não está só em “integrar ferramentas”. Está em permitir que contexto instrumental seja tratado como parte explícita da arquitetura do sistema.
Onde eu colocaria dados para deixar o artigo mais embasado
Se eu quisesse sustentar este artigo sem transformá-lo em revisão bibliográfica, eu escolheria três pontos de dados e colocaria cada um onde ele produz mais efeito.
O primeiro entra na abertura: 57% já têm agentes em produção, 32% esbarram em qualidade, 20% em latência e 89% já implementam observabilidade. Isso estabelece, logo de saída, que a discussão saiu do laboratório e entrou na operação.
O segundo entra quando eu quero explicar por que “mais contexto” não resolve. A formulação da Anthropic sobre contexto como recurso crítico e finito, com retornos decrescentes e risco de degradação conforme a janela cresce, dá base teórica suficiente para sustentar a tese sem soar especulativa.
O terceiro entra quando eu quero mostrar que o problema também é econômico e operacional. O caso dos ~72 mil tokens de tool definitions e ~77 mil tokens totais antes do trabalho, versus ~8,7 mil tokens com descoberta sob demanda, é forte porque expõe custo, latência e desenho do sistema de uma vez só.
Com esses três blocos, eu consigo ancorar o artigo sem lotá-lo de números.
O que eu realmente quero defender
Se eu tivesse que condensar a ideia inteira em uma frase, eu diria isto:
prompt engineering melhora a instrução; context engineering melhora a arquitetura que sustenta a instrução.
É por isso que eu não enxergo esse tema como assunto restrito a quem gosta de IA. Eu enxergo como assunto de arquitetura.
No momento em que agentes deixam de ser uma demo simpática e passam a operar em tarefas longas, com memória, ferramentas, custo, latência e observabilidade, o problema principal deixa de ser “como pedir melhor” e passa a ser “como desenhar melhor o sistema que cerca esse pedido”.
A partir daí, contexto deixa de ser detalhe do prompt e vira o que ele realmente é: uma camada invisível de arquitetura.
E, como quase sempre acontece com camadas invisíveis, muita gente só percebe o quanto ela importa quando ela começa a falhar.
