Context Engineering: por que seu agent fica mais burro no turno 40

A Anthropic traçou a linha em setembro de 2025, e as duas frases pertencem lado a lado. Prompt engineering é “métodos para escrever e organizar instruções de LLM para resultados ideais”. Context engineering é “o conjunto de estratégias para curar e manter o conjunto ideal de tokens (informações) durante a inferência de LLM, incluindo todas as outras informações que podem acabar ali fora dos prompts”.¹

A diferença operacional é quando, e por quem. Um prompt é criado uma vez, por uma pessoa, e revisado. Um contexto é montado em toda chamada, por código que ninguém está olhando, a partir de material que ninguém escreveu à mão: quarenta turnos de histórico, seis resultados de ferramentas, quatro trechos recuperados, um perfil de usuário, doze schemas JSON. O Capítulo 15 mediu o que instruções melhores compram. Este capítulo é sobre os outros noventa por cento dos tokens, que chegam sozinhos.

O mesmo documento nomeia o recurso que todos eles gastam: modelos “têm um ‘orçamento de attention’ do qual sacam ao analisar grandes volumes de contexto. Cada novo token introduzido esgota esse orçamento em alguma medida”. E nomeia o sintoma: “à medida que o número de tokens na context window aumenta, a capacidade do modelo de recordar informações com precisão a partir desse contexto diminui” — context rot.¹

Essa última frase é uma afirmação sobre comportamento, o que significa que pode ser verificada, e a tabela no topo desta página é a verificação.

Quarenta linhas contra o endpoint local do Capítulo 22 — um pequeno servidor Python mantendo Qwen2.5-0.5B-Instruct na CPU e falando no formato chat-completions, para que o loop fique em TypeScript e os tensores fiquem do outro lado da porta.

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

O contador other é o que transforma um resultado decepcionante em um resultado útil: quando o modelo erra, ele está perdido ou está confiante?

A resposta é confiante. Nas oito posições que não são a primeira, 136 das 205 respostas erradas eram o ramal de outro ticket — um número real de quatro dígitos, formatado corretamente, lido da linha errada. Na posição 1, só uma das cinco falhas foi isso; na posição 7, vinte e uma de vinte e seis foram.

Essa distinção é o que importa em produção. Um modelo que diz não consigo encontrar é um bug que você percebe; um modelo que retorna o número de uma linha vizinha é um bug que você coloca no ar, porque na tela os dois parecem idênticos. É a falha contra a qual o Capítulo 19 construiu citações verificáveis, chegando de dentro do prompt em vez de vir do índice.

Posição é um eixo. Comprimento é o outro, e mais fácil de testar: mantenha a resposta no meio e aumente a lista.

Um registro e 97 tokens: 90 %. Três registros e 159 tokens: 55 %. Oito registros e 315 tokens: 15 %, e daí em diante baixo e plano até 140 registros e 4.477 tokens. Todo o colapso acontece entre a primeira e a oitava linha de uma lista.

A última coluna é tudo que não é nem o ramal correto nem o de outro registro; com um único registro na página, é o único lugar onde uma resposta errada pode cair. As duas falhas com um registro merecem ser relatadas, não arredondadas para fora, porque nenhuma foi uma recusa: uma respondeu 5806 para um registro cuja única linha diz 5805. Com 97 tokens e um único candidato, este modelo ainda copia um dígito errado duas vezes em vinte, e esse é o piso contra o qual todo o resto é medido.

Duas coisas decorrem disso. Uma context maior compra o direito de enviar mais, não a certeza de ser lido: este modelo tem uma window de 32.768 tokens e uma faixa de trabalho, nesta tarefa, de algumas centenas de tokens. E não há limiar, penhasco nem estado de “contexto cheio” — a degradação já está em curso no terceiro registro e completa no oitavo, a um por cento da window. Seja lá o que for um limite de contexto, não é isso que governa este resultado.

Dois mecanismos costumam ser oferecidos. O primeiro é a aritmética do Capítulo 9, que a Anthropic enuncia nos mesmos termos deste curso: modelos “são baseados na arquitetura transformer, que permite que todo token atenda a todos os outros tokens em todo o contexto. Isso resulta em n² relações par a par para n tokens”.¹ Attention sobre uma sequência mais longa não é a mesma operação aplicada a mais material; é um orçamento fixo de massa de probabilidade espalhado por mais concorrentes. O segundo é o treinamento: modelos veem muito mais sequências curtas do que longas, então padrões posicionais de longo alcance são a parte menos praticada da rede. Isso é um argumento, não uma medição, e este capítulo não consegue resolvê-lo.

O que está resolvido é o formato, e está desde 2023. Liu et al. testaram resposta a perguntas em múltiplos documentos e recuperação key-value em famílias e tamanhos de modelos, e descobriram que “o desempenho costuma ser mais alto quando a informação relevante ocorre no começo ou no fim do contexto de entrada, e degrada significativamente quando os modelos precisam acessar informação relevante no meio de contextos longos, mesmo em modelos explicitamente de contexto longo”.² O Capítulo 15 tirou sua regra de posição desse artigo; o Capítulo 19 tirou dele o motivo pelo qual vinte chunks recuperados podem pontuar pior do que quatro. A forma prática do fato é a única frase aqui sobre a qual você deve agir: isso leva cinco minutos para medir no seu próprio modelo com seus próprios dados, e nenhuma curva publicada substitui a sua.

Pergunte a uma equipe o que preenche o contexto do agent dela e você recebe uma estimativa, porque nenhuma API retorna a resposta: a resposta fornece prompt_tokens, um número único para tudo.

Você pode recuperar a decomposição com quatro contagens e três subtrações — o prompt inteiro renderizado, o mesmo sem definições de ferramentas, apenas a mensagem de sistema com e sem elas, e tudo com os resultados das ferramentas removidos:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

countPrompt aplica o próprio template de chat do modelo antes de tokenizar, o que importa mais do que parece: seu texto não é o que é contado. Marcadores de papel, o preâmbulo de tool calling e a renderização do schema são todos tokens pelos quais você paga e nunca digitou. O Capítulo 7 construiu um tokenizer e o Capítulo 16 contou com js-tiktoken; aqui, a contagem vem do mesmo modelo que lerá o prompt, que é a única contagem exatamente certa.

Agora rode um agent real por ele: quarenta turnos de uma investigação de incidente, doze ferramentas, um ambiente operacional falso retornando despejos de log realistas e séries de métricas.

Leia a primeira linha contra a última.

No turno 1, o prompt tem 2.547 tokens e 71 % dele são definições de ferramentas. O system prompt é 3 %. O que o usuário digitou é 6 %. O agent ainda não fez nada e já está carregando 1.817 tokens de schema JSON.

No turno 40, o prompt tem 10.632 tokens e as proporções se inverteram: definições 17 %, conversa 29 %, resultados de ferramentas 53 %. A saída das ferramentas ultrapassou as definições no turno 5; a conversa só as ultrapassou no turno 25, então nos primeiros sessenta por cento da sessão o catálogo de ferramentas era maior do que tudo que havia sido dito.

Então o total. Em 57 chamadas de modelo, a execução faturou 370.291 tokens de entrada para um contexto final de 10.632 — o último prompt pago cerca de trinta e cinco vezes, que é o quadrático do Capítulo 16 com um multiplicador de agent por cima. Desses 370.291, 103.569, ou 28 % de tudo que foi faturado, eram as doze definições de ferramentas, reenviadas byte a byte idênticas em toda chamada.

O catálogo de ferramentas é o maior custo fixo em um agent e é invisível, porque você nunca o vê: você passa um array de objetos e o provedor o renderiza no prompt por você. Medido nas mesmas doze ferramentas:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

Por ferramenta, o custo marginal vai de 80 tokens para get_current_time, que recebe uma string, a 263 para search_tickets, que recebe quatro parâmetros com um enum e uma frase de orientação para cada um. Essa é a taxa de câmbio por trás do conselho central do Capítulo 18 de que a descrição é a API: uma boa descrição custa cerca de cem tokens em toda requisição pelo resto da vida do agent. Três consequências.

Uma ferramenta que você não usa ainda é faturada. O agent chamou sete das doze. As outras cinco custaram 697 tokens em cada uma das 57 requisições — 39.729 no total, mais de um décimo de tudo que a execução faturou, por capacidades que ele nunca tocou. Uma das cinco carrega o detalhe mais afiado do trace: o modelo tentou três vezes chamar read_log, que não existe. A ferramenta que ele queria era search_logs, a segunda definição mais cara do catálogo, com 237 tokens. Ele pagou por essa definição 57 vezes, nunca a usou e nunca encontrou seu nome.

Cortar prosa é a otimização mais barata disponível, e é uma troca. Reduzir descrições a uma frase e remover a documentação de parâmetros economizou 526 tokens por chamada, 29 por cento, sem tocar em uma linha de lógica — e fez o modelo chamar pior as ferramentas, que foi o que o Capítulo 18 mediu. O ponto é que os dois lados dessa troca agora estão na mesma unidade.

Em certa escala, enviar definições deixa de fazer sentido. A Anthropic colocou um número nisso em novembro de 2025: um conjunto grande de servidores conectados significa processar “centenas de milhares de tokens” de definições antes de a requisição ser lida, e substituir isso por execução de código — o agent descobrindo e carregando apenas as definições de que precisa — “reduz o uso de tokens de 150.000 tokens para 2.000 tokens, uma economia de tempo e custo de 98,7%”.³ A mesma ideia do resto deste capítulo, aplicada a schemas em vez de histórico: mantenha o índice, resolva a entrada sob demanda.

Duas coisas foram plantadas naquele transcript de quarenta turnos. No turno 2, antes de qualquer trabalho real, o usuário declara uma regra permanente: qualquer ticket que você abrir deve ser registrado sob meu número de funcionário, 4417. No turno 19, no meio do incidente, um fato: o shard afetado é pay-shard-7, confirmado pela equipe de pagamentos. No turno 40, o usuário pede ao agent que abra o ticket de incidente, que precisa dos dois. Cada sondagem é feita em seis formulações diferentes e pontuada de seis — greedy decoding é determinístico, então uma chamada dá um sim ou não irrepetível, e seis dão uma taxa.

O transcript então é reproduzido sob sete políticas de contexto. Reproduzido, não executado de novo, deliberadamente: as mensagens, as chamadas de ferramentas e os resultados das ferramentas são byte a byte idênticos nas sete, então a única variável é o que cada política escolheu manter. O Capítulo 16 mostrou por que uma sliding window é uma jogada econômica ruim, porque destrói o prefixo que poderia usar cache. Aqui está o que ela faz com o comportamento:

As linhas de compactação incluem o custo de compactar: 18.581 tokens de entrada para sete resumos e mais 3.392 para o anotador. A linha de controle está ali para que um zero possa ser lido como zero — com apenas as duas mensagens em um prompt de 1.981 tokens, este modelo responde às duas sondagens perfeitamente, então nenhuma linha é a tarefa sendo difícil demais.

O histórico completo lembra, e é a coisa mais cara da tabela: 370.291 tokens de entrada para uma sessão cujo conteúdo durável são duas frases.

Isso responde a uma pergunta que a abertura deixou em aberto. Por que um transcript de 10.632 tokens mantém um fato que um registro de 853 tokens perde? Porque comprimento é a variável errada. O registro contém vinte e cinco ramais de quatro dígitos em vinte e cinco frases idênticas — vinte e quatro iscas quase perfeitas para aquilo que você quer. O transcript contém exatamente um número de funcionário e um nome de shard. Context rot é interferência antes de ser volume, e é por isso que 136 das 205 respostas erradas lá em cima eram o valor de um vizinho. A pergunta útil sobre uma window não é quanto ela é longa; é quantas coisas nela se parecem com a resposta.

A sliding window é 57 % mais barata e perdeu o incidente. O número de funcionário sobrevive só porque o agent o tinha repetido nos turnos recentes. O shard, declarado uma vez no turno 19, não está nas últimas doze mensagens — e o modelo não diz isso. Quando perguntado seis vezes, respondeu “o shard de pagamento afetado é shard 4417”, buscando o número de funcionário, o único outro identificador que restava em sua window, e duas vezes “pool”, tirado da string pool_exhausted em uma linha de log.

Compactação é barata e perdeu o mesmo fato. Sete resumos, escritos pelo modelo sob uma instrução explícita para manter identificadores, números, instruções permanentes e perguntas em aberto, e pay-shard-7 não está em nenhum dos que importavam; os seis palpites foram shard 1, pay_shard_1 e pool. Compactação não falha de forma barulhenta. Ela produz uma sessão fluente, plausível e muito mais curta que apagou uma linha em silêncio.

Três linhas marcaram 0/6 no fato do turno 19 — a sliding window, a compactação e a compactação com notas. Dezoito respostas erradas entre elas, e nenhuma delas foi “não sei.”

Então vem a linha que deveria ser constrangedora. Manter as próprias quarenta mensagens do usuário literalmente, mais os últimos quatro turnos completos e nada mais, custa 168.550 tokens — 54 % menos que o histórico completo — e responde às duas sondagens tão bem quanto o histórico completo, ou melhor. Sem summariser, sem anotador, sem segundo modelo: um filtro em role === "user". As palavras do usuário são os tokens baratos de maior valor na window de um agent, e a maioria dos designs as descarta junto com todo o resto.

As duas últimas linhas são a tabela de abertura de novo, dentro do agent. O mesmo bloco fixado, movido da mensagem de sistema para o fim do prompt: 5/6 vira 6/6. Em seis tentativas, isso não é uma diferença significativa e não é apresentado como tal — é apresentado como lembrete de que onde é um parâmetro que você está definindo, sabendo ou não.

As quatro estratégias abaixo são da Anthropic, na ordem dela, embora só as três últimas estejam em sua lista de longo horizonte.¹ Todas as quatro são variações de uma instrução: não carregue o que você pode buscar, e não carregue em bruto o que você pode carregar comprimido.

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

O sub-agent não está na tabela acima porque não roda por quarenta turnos: roda uma vez, em uma window que alguém delimitou para ele. Recebendo o system prompt, os turnos 17 a 19 e nada mais — 2.737 tokens — ele respondeu à sondagem do shard 6/6, melhor que todas as políticas da tabela, e à sondagem do funcionário 0/6, porque esse número não está nos três turnos que recebeu.

Isso são sub-agents em dois números: uma window limpa não é inteligência, é escopo, e o escopo é definido de antemão por código que já precisa saber quais turnos importam. Mais uma coisa nessas respostas merece ficar. Essa foi a única política que respondeu “None available” em vez de inventar algo. Um modelo com um contexto pequeno e coerente sabe do que sente falta; um modelo com um contexto grande e ruidoso, não.

Quase toda conversa confusa sobre memória de agent são três mecanismos usando uma palavra só. Eles têm tempos de vida, donos e modos de falha diferentes, e um sistema que os mantém no mesmo lugar tem um problema que ainda não percebeu.

O enquadramento acadêmico é do CoALA, que organiza language agents em torno de “componentes de memória modulares” e separa working memory de armazenamentos episódicos, semânticos e procedurais.⁴ O MemGPT leva a mesma ideia ao pé da letra, pegando memória virtual emprestada de sistemas operacionais: uma camada rápida dentro da window, uma camada lenta fora dela, e o próprio modelo movendo dados entre elas com function calls.⁵ Ambos forçam a pergunta que um produto precisa responder de qualquer forma — não quanto posso manter, mas a qual armazenamento isso pertence, e quando expira.

O teste prático é uma pergunta por fato: o que ainda deve ser verdade amanhã? Um resultado de ferramenta do turno 12, nada. Um resumo da sessão, até a sessão acabar. Que o número de funcionário do usuário é 4417, até ele mudar de emprego. Três respostas, três armazenamentos.

Agora você consegue medir o que há em uma window, decidir o que fica nela e distinguir um agent que esqueceu algo de um que estava carregando aquilo e não olhou.

A última das quatro estratégias é a que não cabe aqui. Um sub-agent não é uma política de contexto, é um segundo agent, e no momento em que há dois você precisa decidir o que passa entre eles e qual está no comando. O Capítulo 25 é isso: os cinco padrões de orquestração e de onde cada um de seus nomes realmente vem, as duas topologias que se confundem — pedir algo a um sub-agent e receber uma resposta de volta, versus entregar a conversa a ele e não recebê-la de volta — e o achado medido de que, na tarefa cujo custo ele calcula, o arranjo mais simples vence — seguido pelo teste de quando ele para de vencer.

Ele também herda exatamente o que este capítulo acabou de medir. Um sub-agent retorna um resumo. Um resumo é uma compactação que você não escreveu, produzida por um modelo cuja window você não consegue ver, e o pai não tem como diferenciar um resumo bom de um confiantemente errado — a mesma distinção que separou 84 % de 19 % no topo desta página, e que transformou dezoito fatos ausentes em dezoito invenções. Então: quando o sub-agent está errado, o que exatamente o pai pode examinar?

Todos os números aqui foram produzidos nesta máquina e nenhum foi estimado. O modelo é Qwen2.5-0.5B-Instruct em float32 na CPU com greedy decoding, servido por loopback por um pequeno endpoint Python que fala no formato chat-completions e expõe uma rota de contagem de tokens — de novo a costura do Capítulo 14, tensores do lado Python e o loop do lado TypeScript — então toda contagem é o tokenizer do próprio modelo aplicado ao seu próprio template de chat. A tabela de posição tem 288 chamadas, nove posições por trinta e duas tentativas com um ticket diferente em cada tentativa; a tabela de comprimento tem 140 chamadas; a execução do agent tem 57 chamadas de modelo ao longo de 43 minutos de relógio; a tabela de políticas é aquele único transcript reproduzido sob sete políticas. Os intervalos são de Wilson, do Capítulo 4. Nenhuma API paga foi chamada, e é também por isso que não há um preço sequer no capítulo: as contagens de tokens são exatas, e as taxas pelas quais você as multiplicaria são as do Capítulo 16.