Context engineering é trabalho de verdade. Aqui está o loop que o roda.

Um agent está triando tickets de suporte desde as nove da manhã. Às duas da tarde ele pergunta a um cliente qual é o tier da conta dele, informação que o cliente digitou na primeira mensagem, seis horas e quarenta tool calls atrás. Nada quebrou. Nenhum erro disparou. O modelo é exatamente tão capaz às duas quanto era às nove. O que mudou foi o que ele conseguia ver.

Isso não é um problema de prompt. É a lacuna que o campo agora chama de context engineering vs prompt engineering, e quando agents pararam de responder uma pergunta e passaram a rodar por horas, a segunda disciplina silenciosamente se tornou o trabalho inteiro.

Context engineering é a disciplina de curar exatamente quais tokens um modelo vê a cada passo de um run de longo horizonte, e é aí que a qualidade é ganha ou perdida, não no modelo. Este post defende essa frase: por que a leitura ingênua (escreva um prompt esperto, deixe o modelo cuidar do resto) desmorona no momento em que um run fica longo, o que os próprios números do campo dizem que de fato está quebrando, e os quatro movimentos, write, select, compress, isolate, que tratam contexto como o recurso finito e disputado que ele sempre foi, e, mais adiante, onde esses quatro movimentos precisam morar: não um hábito que engenheiros lembram de aplicar manualmente, mas um loop que algo roda a cada passo, o formato ao redor do qual os próprios agents da ApolloSpace AI são construídos.

Context engineering vs prompt engineering: dois trabalhos diferentes

O movimento ingênuo é tratar prompt engineering como o ofício inteiro: escrever o system prompt com cuidado, ajustar a redação, publicar, e assumir que o agent está resolvido. Esse instinto fazia sentido durante anos, porque durante anos uma chamada de LLM era um tiro só, uma entrada, uma saída, pronto, e acertar a redação era a maior parte do trabalho.

Isso falha no momento em que um agent para de ser uma chamada e passa a ser um run. O próprio time de engenharia da Anthropic traça a linha diretamente: prompt engineering “se refere a métodos para escrever e organizar instruções de LLM para resultados ótimos”, enquanto context engineering “se refere ao conjunto de estratégias para curar e manter o conjunto ótimo de tokens (informação) durante a inferência do LLM, incluindo toda a outra informação que pode aterrissar ali fora dos prompts”, ao longo de cada turno, não só do primeiro. Andrej Karpathy colocou a mesma ideia de forma mais direta: context engineering é “a arte e ciência delicada de preencher a context window com exatamente a informação certa para o próximo passo”. Nenhuma das duas definições menciona escrever uma frase melhor; as duas descrevem um orçamento que muda de forma a cada passo do run.

O mecanismo é simples depois que você o enxerga. Um prompt é estático, você o escreve uma vez. Uma context window no turno quarenta não é: é o system prompt mais o schema de cada ferramenta mais o histórico acumulado mais o que quer que tenha sido recuperado para este passo, tudo competindo pelo mesmo número fixo de tokens, e otimizar a redação do system prompt não faz nada quanto aos outros três inquilinos lotando aquele espaço.

O movimento ingênuo que só funciona por uma tarde

Então o próximo instinto ingênuo, assim que alguém percebe que a janela é o que de fato importa, é simplesmente colocar tudo nela. A janela agora é enorme, centenas de milhares de tokens. A cada turno, cole de volta o histórico completo, o spec completo de cada ferramenta, cada documento que o agent tocou. Por uma tarde, isso funciona lindamente. O agent parece lembrar de tudo.

Isso falha porque uma context window não é capacidade neutra, é espaço disputado, e cada inquilino espremido ali dentro tem um custo de oportunidade. A Anthropic descreve o efeito resultante como “context rot”: o recall degrada conforme a contagem de tokens sobe, porque atenção é um recurso finito espalhado por cada token presente, não só pelos que importam. Designs multi-agent compõem o custo de novo, coordenar sub-agents pode rodar até 15 vezes o volume de tokens de um agent único, como a própria Anthropic relatou, porque cada handoff re-serializa contexto que um design mais limpo teria deixado para trás. A janela enche, o sinal que importava seis horas atrás fica soterrado sob tudo que veio depois, e o agent perguntando o tier da conta de novo não está confuso, ele só está olhando para uma janela onde aquele fato não cabe mais.

Essa é uma falha diferente daquela que aparece quando um agent não tem memória durável nenhuma, que é por que a janela não é a mesma coisa que memória, para começo de conversa. Aquele problema anterior é sobre persistência: nada sobrevive entre runs a menos que você deliberadamente escreva num disco. Este aparece mesmo com um memory store perfeito bem ali, porque persistência só responde o que foi salvo, não o que anda na janela neste turno específico, competindo com os specs das ferramentas e o histórico ainda se acumulando ao vivo. Você pode resolver memória completamente e ainda assim perder a tarde, porque context engineering é uma decisão ao vivo, passo a passo, não uma escrita única.

Uma context window não é uma mesa maior. É a mesma mesa, e tudo que você não tira dela ainda está ocupando espaço.

Os quatro verbos: write, select, compress, isolate

O fix ingênuo para uma janela transbordando geralmente é um movimento só: adicionar retrieval, e chamar isso de resolvido. Retrieval genuinamente ajuda, pesquisa recente descobriu que aplicá-la só às descrições de ferramentas melhora a precisão de seleção de ferramentas em aproximadamente três vezes, porque o modelo para de escolher entre todos os schemas de ferramenta do sistema e passa a escolher só entre as relevantes para este passo, digamos, de quarenta ferramentas para cinco. Mas retrieval sozinha só responde select. Ela não diz nada sobre o histórico que continua crescendo turno a turno, ou sobre a subtarefa que está prestes a despejar todo o seu rastro de trabalho de volta no run principal.

É por isso que a LangChain enquadra context engineering como quatro alavancas separadas, não uma: write, salvar estado totalmente fora da janela, um scratchpad ou um dos vários tipos de memory store que um agent de fato precisa, para que não precise viver no orçamento de tokens de cada turno. Select, trazer de volta só a fatia relevante para o passo atual, o movimento de retrieval. Compress, resumir o que se acumulou para que o histórico pare de crescer sem limite, a mesma disciplina que o Claude Code aplica quando dispara compaction e mantém só o que ainda é load-bearing em vez da transcrição completa. Isolate, delegar uma subtarefa a um sub-agent que roda na própria janela limpa e retorna um resultado curto em vez de todo o seu rastro de trabalho. Vale dizer sem rodeios o enquadramento da Cognition AI: context engineering é “efetivamente o trabalho número um dos engenheiros que constroem agents de IA”, e os quatro verbos são a coisa mais próxima que o campo tem de uma resposta compartilhada para o que esse trabalho consiste.

Retrieval sozinha só responde select. Ela não diz nada sobre o histórico ainda se acumulando, ou sobre a subtarefa prestes a despejar seu rastro completo de volta no run.

Aplicados juntos, não escolhidos como favorito, eles impedem que os tokens se acumulem num só lugar: algo está sempre ou saindo da janela, via write ou compress, ou voltando menor do que saiu, via isolate.

Nomear quatro verbos é uma descrição, não um runtime: alguém ainda precisa construir a coisa que escreve, seleciona, comprime e isola, a cada turno, sem que um humano lembre de conectar isso toda vez. Essa é a camada que a a16z chamou de system of intelligence, a camada de raciocínio sobre os fatos de uma empresa, e a camada que a Bessemer Venture Partners chamou de system of action, software que executa e escreve o resultado de volta em vez de só recomendar. O agent loop da ApolloSpace AI é construído para rodar os quatro verbos exatamente através dessas camadas, não como quatro hábitos separados. O System of Record, a camada de memória da ApolloSpace AI, é construído para ser o alvo do write: o tier de uma conta ou uma preferência declarada é para ser escrito ali no momento em que é dito, fora do orçamento de qualquer turno específico, para que ainda esteja lá na hora seis. O System of Intelligence realiza select e compress: um agent é desenhado para consultar aquele record pela fatia que a tarefa precisa, não reproduzir o histórico inteiro da org, e para dobrar o que se acumulou num resumo antes do próximo turno. O System of Action é onde o isolate mora: uma subtarefa é desenhada para rodar sua própria passagem limpa para que só seu resultado curto e estruturado atravesse de volta, escrito do mesmo jeito que as camadas acima dela são, nunca o rastro completo do sub-agent. A ApolloSpace AI não está reivindicando os termos, a a16z e a Bessemer o fizeram, nem os verbos, a LangChain o fez; o que ela é construída para dominar é o tecido conectivo, record para intelligence para action fechando um loop em vez de três fornecedores nunca desenhados para passar trabalho um para o outro.

Context engineering é a disciplina de curar exatamente quais tokens um modelo vê a cada passo de um run de longo horizonte, e é aí que a qualidade é ganha ou perdida, não no modelo. Os quatro verbos não são quatro opções para escolher, são quatro formas separadas de impor essa disciplina a cada turno.

Onde a qualidade de fato quebra, pelos próprios números do campo

A última crença ingênua é a mais cara: que um problema de qualidade em produção significa que você precisa de um modelo mais inteligente. Faça upgrade para o próximo release de fronteira, vai o raciocínio, e o agent que se repete ou deixa cair um detalhe vai parar de fazer isso.

Isso falha porque os dados dizem o contrário. A própria pesquisa State of AI Agents da LangChain, mais de 1.300 praticantes, encontrou que 57% das organizações já têm agents rodando em produção, e 32% ainda apontam qualidade, não capacidade, como a maior barreira única para expandir o deployment, essencialmente inalterado em relação ao ano anterior. Isso não é um gap de benchmark; lançamentos de modelo aconteceram nessa janela, e a barreira não se moveu porque nunca foi realmente sobre o que o modelo conseguia raciocinar, mas sobre o que ele conseguia ver quando precisava raciocinar. Troque por um modelo melhor e entregue a ele o mesmo contexto transbordando e mal curado, e você obtém a mesma resposta errada, entregue de forma mais fluente.

Uma vez que qualidade é entendida como um problema de contexto em vez de um problema de capacidade, o fix não é um upgrade de modelo, é orçar o pipeline de contexto do jeito que você orçaria latência ou custo, e verificá-lo do mesmo jeito que você verificaria qualquer outra parte do sistema, a mesma disciplina por trás de tratar o próprio prompt como código versionado em vez de uma caixa de texto que você edita por instinto.

O que isso custa, honestamente

Nada disso é de graça, e fingir o contrário é seu próprio modo de falha. Write precisa de um store externo de verdade, e todo store precisa de uma decisão sobre o que vale a pena persistir, erre isso e você tem um aterro do qual ninguém consegue recuperar nada. Compress é uma aposta: todo resumo arrisca descartar o único detalhe que importava, e diferente de um crash, uma compressão ruim não se anuncia, ela só silenciosamente remove o fato de que o próximo passo precisava. Isolate adiciona coordenação, uma fronteira de sub-agent é latência real e seu próprio overhead de tokens, exatamente por isso designs multi-agent podem custar várias vezes os tokens de um agent único se o isolamento não estiver valendo a pena. Context engineering troca um problema óbvio por vários mais sutis, cada um exigindo julgamento contínuo em vez de um fix único.

Vale o custo mesmo assim, porque a alternativa não é mais barata, é adiada. Uma janela não gerenciada garante a falha eventualmente, é uma questão de qual turno, não se vai acontecer. Um pipeline engenheirado degrada de forma previsível em vez disso: você consegue ver a compressão ficando com perdas, medir a precisão do retrieval, orçar o overhead do isolamento contra o que ele economiza. Previsível e ajustável vence grátis e eventual, toda vez que um run fica longo o suficiente para importar.

A virada

Tire a linguagem de pipeline e o que de fato está acontecendo é um tipo de julgamento antigo e humano, movido para outro lugar. Decidir o que um sub-agent entrega de volta, o que é comprimido para fora, o que ganha um lugar na janela do próximo turno, é a mesma decisão que um bom editor toma sobre um rascunho: nem tudo que o escritor produziu pertence à frente do leitor, só o que o leitor precisa em seguida. A context window está no lugar do leitor aqui, e o modelo é quem tem que trabalhar com o que quer que tenha atravessado.

Esse julgamento não se automatiza conforme os modelos ficam mais inteligentes, ele fica mais importante, porque um modelo mais inteligente recebendo um contexto pior curado ainda raciocina sobre a fatia errada do mundo, só que de forma mais persuasiva. A habilidade nunca foi realmente sobre falar com o modelo. Era sobre decidir, momento a momento, o que o modelo tem permissão de ver, uma disciplina que uma empresa constrói e mantém, do mesmo jeito que ela constrói e mantém a memória estruturada que um agent precisa para raciocinar através do próprio histórico ou a prática mais ampla de engenheirar o comportamento de um agent de propósito em vez de por acidente.

Context engineering é a disciplina de curar exatamente quais tokens um modelo vê a cada passo de um run de longo horizonte, e é aí que a qualidade é ganha ou perdida, não no modelo. Essa é a frase que vale a pena lembrar da próxima vez que um upgrade de modelo é lançado e o mesmo bug de seis horas ainda está lá, sem conserto.

---

Curadoria, não acumulação, é o padrão pelo qual este post inteiro tem argumentado, e é o que o agent loop da ApolloSpace AI é construído para rodar de propósito em vez de redescobrir da forma difícil, record, intelligence, e action, a cada passo. Da próxima vez que um agent perguntar a um cliente algo que já foi dito a ele seis horas atrás, o bug não está no modelo que respondeu. Está em o que quer que tenha decidido, silenciosamente, o que aquele modelo tinha permissão de ver.