Janelas de contexto são orçamento, não feature

Agentes em produção falham por inchaço de contexto muito antes de atingir o limite rígido do provedor. O sintoma parece confusão: o agente repete uma pergunta respondida dez turnos atrás, ignora uma restrição enterrada em um colar de 40 páginas ou alucina um caminho de arquivo que existiu só em uma saída de ferramenta truncada. A correção raramente é uma janela maior. A correção é um orçamento de janela de contexto — um plano de alocação por turno que decide o que entra na inferência, o que fica em memória externa e o que é expulso antes do próximo passo. Contexto não é memória ilimitada. É um recurso escasso com latência, custo e trade-offs de atenção em cada token.

Modelos frontier em 2026 anunciam janelas de 200K a mais de 1M tokens. Essa capacidade é real. Também é uma armadilha. Encher a janela não torna o agente mais inteligente — torna a inferência mais lenta, mais cara e mais vulnerável ao efeito lost-in-the-middle, em que fatos críticos no centro de um prompt longo perdem prioridade na atenção do modelo. Quem envia agentes confiáveis trata o limite anunciado como teto, não como alvo. A maioria dos turnos em produção mira 60–75% de utilização, reservando margem para respostas de ferramentas e saída do modelo que chegam depois da chamada inicial.

Falhas de orçamento de contexto aparecem como amnésia do agente

Falhas de contexto são silenciosas. Diferente de um erro de rate limit ou timeout de ferramenta, uma janela inchada produz respostas plausíveis porém erradas. O agente continua rodando. Os logs parecem limpos. O custo sobe gradualmente. Só quando um humano reproduz a sessão o padrão emerge: a informação estava em algum lugar do transcript, mas perdeu prioridade diante de conteúdo mais novo e ruidoso.

Três modos de falha dominam incidentes de produção rastreados até gestão de contexto.

Prompts que despejam tudo. Equipes colam repositórios inteiros, backlogs completos ou exports JSON de vários megabytes no primeiro turno porque a janela "cabe". O modelo recebe os dados. Não atende de forma confiável a todos. Restrições críticas do turno um competem com 200 resultados de ferramentas no turno quinze.

Saída de ferramentas sem limite. Cada loop do agente reenvia entradas e saídas anteriores de ferramentas. Um único grep em um monorepo ou uma query que retorna dez mil linhas pode consumir mais tokens que todo o histórico de conversa. Traços de ferramentas crescem mais rápido que mensagens de chat porque se acumulam textualmente.

Truncamento cego. Quando o contexto se aproxima do limite, janelas deslizantes ingênuas descartam as mensagens mais antigas — muitas vezes instruções de sistema, o objetivo original do usuário ou a lista de restrições do início da sessão. Sumarização sem estrutura preserva narrativa mas perde identificadores: números de ticket, caminhos de arquivo, códigos de erro, valores.

Uma janela de contexto maior convida a agentes mais lentos, mais caros e menos focados.

O custo não é só gasto em inferência. Latência se compõe com o tamanho do input. Um turno que processa 400K tokens pode adicionar segundos de prefill antes do primeiro token de saída — inaceitável para fluxos interativos. O design do orçamento de janela de contexto é como equipes limitam esse crescimento antes de virar problema de arquitetura.

Um orçamento de janela de contexto aloca capacidade em quatro camadas

Um orçamento de janela de contexto não é o máximo do provedor. É uma decisão de produto: quantos tokens este turno pode gastar e em quais camadas. Tratar alocação como plano de capacidade, não como detalhe posterior.

Esses intervalos variam por fluxo. Um agente de código com quarenta ferramentas MCP precisa de camada de ferramentas maior e retrieval menor. Um agente de suporte com toolset estreito gasta mais em artigos de base de conhecimento recuperados. O ponto é reserva explícita — não preenchimento acidental.

Definir dois limiares por sessão. Um limiar suave em ~70% do orçamento dispara compactação: resumir turnos antigos em um bloco de estado estruturado, comprimir traços de ferramentas em um ledger de tópicos, expulsar chunks RAG obsoletos. Um limiar rígido em ~90% interrompe retrieval novo até completar compactação. Esperar um erro 400 da API significa que a sessão já perdeu continuidade.

context_budget:
  max_input_tokens: 120000        # teto de produto, não máximo do provedor
  soft_threshold: 0.70
  hard_threshold: 0.90
  layers:
    system:
      pinned: true
      max_tokens: 18000
    tools:
      max_tokens: 24000
      cache_stable: true
    working_memory:
      max_tokens: 42000
      verbatim_tail_turns: 6
    retrieval:
      max_tokens: 36000
      strategy: just_in_time

Instrumentar cada camada. Se a saída de ferramentas consistentemente excede sua alocação, o problema é design de ferramentas — não escolha de modelo. O artigo sobre servidores MCP como infraestrutura de produção cobre por que respostas verbosas de ferramentas são problema de controle de acesso e design de API, não só de prompt.

Conteúdo estável vai para cache; volátil, fora da janela

Nem tudo que vale saber pertence à janela ativa. Agentes em produção separam estado quente (necessário para decidir este turno) de estado frio (durável mas recuperável sob demanda).

Estado quente permanece em contexto: mensagem atual do usuário, últimos seis turnos textuais, restrições ativas, subtarefa aberta e resultados de ferramentas da cadeia de raciocínio atual. Estado frio vive fora: arquivos completos de conversa, vector stores, sistemas de arquivos, bancos de dados e notas estruturadas que o agente escreve entre turnos.

Prompt caching amortiza conteúdo quente estável. Instruções de sistema, políticas de segurança e schemas de ferramentas que não mudam entre turnos devem ser marcados como cacheáveis onde o provedor suporta — tokens de input em cache costumam ser cobrados a uma fração do custo de input fresco. O ganho exige disciplina: mutar o system prompt a cada turno anula o cache por completo.

Anotações estruturadas estendem estado frio sem inflar o quente. O agente escreve um artefato compacto de progresso — todos abertos, caminhos de arquivo fixados, estratégias falhas a evitar, decisões já tomadas — em armazenamento externo. O próximo turno injeta só esse artefato mais a cauda recente. Esse padrão espelha como specs funcionam como contratos de execução: o artefato durável é pequeno, versionado e autoritativo; o ruído gerado ao redor é descartável.

Compactação deve preservar entidades, não vibes. Um resumo que diz "o usuário tinha dúvidas de faturamento" é inútil. Um que diz "fatura #8842, status vencido, reembolso limitado a $240 conforme política REF-12, tentativa anterior falhou por timeout de gateway" sobrevive mais dez turnos. Validar a saída de compactação com spot checks: regex para IDs, valores, datas e caminhos de arquivo antes de aceitar o resumo na memória de trabalho.

Saída de ferramentas domina o crescimento de contexto em loops de agente

Agentes estilo ReAct reenviam o traço completo a cada iteração. Cada chamada de ferramenta adiciona tokens de input (a chamada) e de output (a resposta). Dez iterações com saídas verbosas podem exceder o system prompt, os schemas de ferramentas e o histórico do usuário combinados.

Comprimir saída de ferramentas na fronteira antes de injetar. Uma query que retorna 10.000 linhas vira contagem, amostra de três linhas e nomes de colunas. Uma busca de logs de 500 linhas vira as cinco linhas ao redor da assinatura de erro mais a query usada. Uma leitura de arquivo retorna a função relevante, não o módulo inteiro — a menos que a tarefa exija contexto de arquivo completo.

Atribuir prioridade de expulsão quando acima do orçamento:

• Mensagem do usuário e política de sistema fixada: prioridade 100 — nunca expulsar
• Estado de subtarefa ativa e restrições abertas: prioridade 90
• Resultados falhos de ferramentas (erros informam retentativas): prioridade 80
• Resultados bem-sucedidos da cadeia atual: prioridade 60
• Resultados bem-sucedidos de subtarefas concluídas: prioridade 40 — comprimir para ledger
• Chunks RAG obsoletos de subtarefas anteriores: prioridade 20 — expulsar primeiro

Reiniciar contexto de trabalho nos limites de subobjetivo. Quando um agente termina "diagnosticar latência de pagamentos" e começa "redigir PR de remediação", o traço de diagnóstico comprime para um ledger de cinco linhas. Estado persiste em memória externa; o próximo subobjetivo começa com camada de trabalho limpa. Os runbooks que governam agentes em produção codificam esses limites explicitamente — cada passo define qual evidência entra no contexto e o que é arquivado.

Como equipes devem desenhar um orçamento de janela de contexto?

O design do orçamento de janela de contexto é tarefa de engenharia de primeira classe para qualquer agente que saia do demo. As perguntas abaixo cobrem as decisões que separam agentes confiáveis de chatbots caros.

O que pertence dentro da janela de contexto versus memória externa?

Dentro da janela: tudo necessário para escolher a próxima ação — intenção atual do usuário, restrições ativas, turnos recentes textuais, resultados de ferramentas da cadeia aberta e chunks de retrieval diretamente relevantes a este passo. Fora da janela: históricos completos, documentos grandes, logs brutos, datasets completos e qualquer coisa recuperável por ID ou query. O teste é custo de retrieval versus custo de atenção. Se buscar um trecho de 2K tokens sob demanda vence manter 50K tokens carregados "por precaução", mantenha externo.

Quando um agente deve disparar compactação de contexto?

Disparar compactação no limiar suave do orçamento (~70%), não no limite rígido do provedor. Triggers adicionais: a cada K turnos em sessões longas, ao concluir um subobjetivo, quando tokens de traço de ferramentas excedem a alocação de memória de trabalho, e antes de injetar um payload grande de retrieval. Compactação deve produzir estado estruturado — todos, entidades fixadas, estratégias falhas — não prosa narrativa. Rodar compactação com um modelo menor se latência importa; validar que identificadores de entidade sobreviveram.

Uma janela de contexto maior elimina a necessidade de orçamentar?

Não. Janelas maiores aumentam custo por turno, latência de prefill e risco de lost-in-the-middle. Modelos com capacidade de 1M tokens rendem melhor quando o prompt contém tokens de alta sinal. O orçamento é como equipes impõem densidade de sinal. O tamanho da janela define o teto; o orçamento define o alvo.

Um ponto de vista oposto

Um argumento frequente sustenta que limites de janela de contexto são restrição temporária de infraestrutura — que modelos com 2M ou 10M tokens tornarão o orçamento obsoleto, e equipes deveriam carregar tudo e deixar os mecanismos de atenção ordenar.

Esse argumento funciona para trabalhos de análise em lote com uma única passagem sobre documentos estáticos. Falha para agentes interativos que executam dezenas de turnos com traços de ferramentas acumulados, subobjetivos mutáveis e restrições de custo em tempo real. Pesquisa sobre retrieval em contexto longo mostra consistentemente pior recall para informação no meio de prompts muito longos — tamanho de janela não elimina a economia da atenção.

Janelas maiores também elevam o custo da falha silenciosa. Um agente que "esquece" uma restrição a 128K tokens é obviamente quebrado. Um que perde a mesma restrição dentro de 800K tokens de ruído parece nunca ter tido a informação. Orçamentar força decisões explícitas sobre o que importa agora — que é o trabalho real da engenharia de contexto.

O que vale a pena lembrar

• Um orçamento de janela de contexto é um plano de alocação por turno — não o máximo anunciado do provedor.
• Mirar 60–75% de utilização; reservar margem para respostas de ferramentas e saída do modelo em cada turno.
• Alocar explicitamente entre camadas de sistema, ferramentas, memória de trabalho e retrieval com regras de expulsão.
• Saída de ferramentas acumula mais rápido que histórico de chat — comprimir na fronteira antes de injetar.
• Compactar em 70% preserva entidades e restrições; truncamento cego destrói continuidade de sessão.
• Conteúdo estável (system prompts, schemas de ferramentas) vai para cache; estado volátil vai para memória externa.
• Janelas maiores aumentam custo e latência — não removem a necessidade de orçamentar.

Conclusão

A mudança de prompt engineering para context engineering é, na prática, uma mudança de redação para alocação. A pergunta deixa de ser "o que o system prompt deve dizer?" e passa a ser "o que merece um token neste turno, e o que fica recuperável até precisar?" Equipes que respondem com um orçamento escrito — tetos por camada, triggers de compactação, prioridades de expulsão, instrumentação — enviam agentes que mantêm coerência em sessões longas sem crescimento linear de custo. As que tratam a janela de contexto como checkbox de feature enviam demos que funcionam cinco turnos e degradam em silêncio depois de vinte.

A próxima decisão de design não é qual modelo tem a maior janela. É quais artefatos são pequenos o bastante para fixar, quais saídas de ferramentas são resumidas por padrão e qual estado sobrevive a uma passagem de compactação. Deixar essas decisões explícitas antes do agente tocar produção — porque quando a falha de contexto aparece nas métricas, a sessão já perdeu o fio.

Brief da imagem de capa

Subject: a horizontal bar chart divided into four labeled segments (system, tools, memory, retrieval) with one segment highlighted as over capacity and a secondary gauge showing 72% utilization.

Composition: left-weighted budget bar on 65% of canvas; right 35% reserved for title overlay at H1 weight. Thin tick marks at 70% and 90% threshold lines.

Palette: #0F172A (slate-900 background), #22D3EE (cyan-400 for active layer), #F97316 (orange-500 for over-budget warning), #94A3B8 (slate-400 for inactive layers), #F8FAFC (slate-50 text).

Mood: precise, restrained.

Style guardrails: no 3D charts, no stock photography, no robot mascots, no glowing brain imagery. Flat vector with 1 px hairlines and monospace labels for layer names.

Format: 1200 × 630 PNG, exported at 2× for Retina, under 300 KB.