A maior conta do seu agente é a que você não vê

Todo agente tem um mecanismo que decide o que o modelo enxerga a cada turno. Na maioria dos sistemas em produção, essa decisão foi congelada lá no protótipo e nunca mais foi revisitada. Isso é um problema, porque normalmente é justamente aí que mora a maior parte do custo operacional — e, silenciosamente, boa parte das respostas decepcionantes.

Olha só a sutileza: essa é a única parte do agente que melhora sozinha. O modelo continua tão capaz quanto no dia em que você o escolheu. As instruções só mudam quando alguém reescreve. Mas o que o agente sabe, o que ele acessa e o que ele lembra cresce conforme ele roda. Gerenciar esse crescimento é o que chamamos de engenharia de contexto.

Um modelo não tem memória própria. A cada turno, a janela de contexto entrega tudo que ele pode usar: instruções, ferramentas, documentos recuperados, histórico da conversa. Quando o turno acaba, aquilo tudo some e precisa ser reenviado no próximo. Para um chatbot respondendo uma pergunta, tranquilo. Para um agente trabalhando dezenas de turnos atrás de um resultado, isso vira o maior gasto — e conteúdo desnecessário é cobrado repetidamente.

O custo menos óbvio é o de qualidade. Mais contexto não significa resposta melhor. Um fato relevante enterrado em 40 páginas é mais difícil de usar, e uma lista de ferramentas gigante aumenta a chance de o modelo escolher a errada. Cada erro adiciona turnos — e custo — pra se recuperar. Diferente de trocar por um modelo mais barato (que sacrifica qualidade) ou encurtar instruções (que pode enfraquecer a resposta), remover contexto desnecessário baixa o custo sem baixar a qualidade. Por isso é a otimização mais fácil de defender internamente.

(Contexto original: the economics of agent optimization)

Enterprise AI agent architecture diagram showing context window inputs like knowledge, tools, skills and memory flowing into a language model Dev Environment Setup

As quatro perguntas que definem a engenharia de contexto

Engenharia de contexto não é uma decisão de design tomada uma vez — praticada continuamente, é assim que o agente melhora, porque cada turno revela o que ele realmente usou. Quatro perguntas cobrem o trabalho, e a maioria dos times ataca nessa ordem.

1. O que o agente deve saber?

Muito time começa com busca ampla que joga documentos inteiros no prompt. Fácil de construir, caro de rodar. Uma camada gerenciada de conhecimento resolve isso decompondo a query em subqueries, buscando fontes em paralelo, fazendo reranking semântico e devolvendo apenas trechos fundamentados com citação. Em benchmarks internos no BrowseComp-Plus, essa abordagem melhorou o recall de evidências em até 54% e cortou o custo de tokens de recuperação em 34%.

2. O que o agente deve alcançar?

O overhead de ferramentas é traiçoeiro. Adicionar uma ferramenta é uma linha de código, mas a descrição completa dela viaja no prompt em todo turno — precisando ou não. Quando a toolbox cresce pra centenas de ferramentas, esse imposto de descrição domina a conta. A solução é tool search: em vez de expor a lista inteira, o modelo recebe uma forma de descrever em linguagem natural o que precisa, e uma forma de chamar o que voltar. O custo da lista de ferramentas fica plano, não importa o tamanho da toolbox.

# Ingênuo: toda descrição de ferramenta vai em todo turno
tools = [search_tool, code_tool, sql_tool, ...]  # 200+ ferramentas
response = model.chat(prompt, tools=tools)  # 💸 imposto total a cada chamada

# Melhor: expõe uma única entrada de tool-search
tool_search = {
    "name": "find_tool",
    "description": "Descreva em linguagem natural a capacidade que você precisa."
}
response = model.chat(prompt, tools=[tool_search])
# O modelo pede uma capacidade, você resolve no servidor,
# e só o schema da ferramenta escolhida entra no próximo turno.

Em benchmark interno contra um dataset público de tool-retrieval, o consumo médio de tokens de entrada caiu cerca de 97% em bibliotecas grandes — impacto direto no custo de inferência.

3. Como o agente deve fazer o trabalho?

Conhecimento e ferramentas cobrem o que o agente acha e faz. Nenhum dos dois cobre como sua empresa espera que o trabalho seja feito — o caminho de escalonamento que um agente de suporte segue, o checklist que uma revisão de código aplica. Essa orientação normalmente vive nas instruções, é copiada e colada entre agentes e vai em toda requisição, mesmo quando irrelevante. A solução é uma skill: um procedimento nomeado, gerenciado centralmente, que o agente só carrega quando for relevante. Ele vê primeiro o nome e uma descrição curta; as instruções completas carregam sob demanda.

Cloud platform dashboard visualizing token cost reduction through agentic retrieval and semantic reranking for enterprise AI agents Coding Session Visual

O que o agente deve lembrar — e os limites disso tudo

Agentes precisam de continuidade, mas não precisam carregar cada detalhe de cada interação. Reenviar a conversa inteira pro modelo adiciona custo e queima contexto, mesmo quando só alguns detalhes ainda importam. Um modelo prático de memória se divide em três camadas:

  • Memória de sessão — a conversa atual.
  • Memória de usuário — preferências e fatos que persistem entre sessões.
  • Memória procedural — fluxos aprendidos e padrões de execução de tarefa.

A memória procedural complementa muito bem as skills gerenciadas centralmente: a skill define o procedimento aprovado, enquanto a memória procedural deixa o agente aprender com a própria execução. Em avaliações internas, habilitar memória procedural gerou cerca de 5% de melhora no STATE-Bench e no Tau-Bench.

⚠️ Onde isso fica difícil

Engenharia de contexto não é almoço grátis. Alguns avisos honestos:

  1. Você precisa de observabilidade primeiro. Não dá pra podar o que você não enxerga. Se você não loga o que entra na janela de contexto a cada turno, você está chutando.
  2. Qualidade de retrieval é um teto. Se sua base de conhecimento está desatualizada ou o reranker é fraco, nenhuma poda salva a qualidade da resposta.
  3. Memória é superfície de compliance. Memória de usuário e procedural armazenam dados. Política de retenção, TTL e isolamento por usuário não são opcionais — são o preço de entrada em indústria regulada.
  4. Lock-in de vendor é real. Camadas gerenciadas de conhecimento, toolboxes e serviços de memória são convenientes, mas desenhe o agente pra que retrieval, ferramentas e memória sejam trocáveis atrás de interfaces. Frameworks como LangGraph, Microsoft Agent Framework, GitHub Copilot SDK e Claude Agent SDK são alvos razoáveis — não acople sua lógica de negócio ao SDK de um vendor só.
  5. Benchmarks são direcionais, não promessas. Uma redução de 97% de tokens num dataset público de tool-retrieval é sinal, não garantia. Meça na sua carga de trabalho.

Próximos passos pra estudar

  • Profile um agente em produção: logue o breakdown de tokens entre instruções, ferramentas, docs recuperados e histórico por turno. A maior fatia é seu primeiro alvo.
  • Troque listas estáticas de ferramentas por tool-search em qualquer agente com mais de ~20 ferramentas.
  • Tire procedimentos repetidos das instruções e coloque em skills versionadas e gerenciadas centralmente.
  • Adicione memória de sessão/usuário só depois de ter política de retenção e TTL no lugar.
  • Estude agentic retrieval e reranking semântico — são as duas maiores alavancas do lado do conhecimento.

Data analytics view comparing agent input token consumption before and after tool search optimization in a large tool library Developer Related Image

Resumindo

Engenharia de contexto não é sobre encolher prompt. É sobre construir agentes que ficam melhores com o uso. Quando o conhecimento que eles puxam, as ferramentas que descobrem, os procedimentos que seguem e as memórias que retêm melhoram com o tempo, o agente fica mais capaz e mais eficiente — sem rebuild.

O recado prático pra qualquer time que está colocando agente em produção: antes de trocar de modelo ou reescrever prompt, olha o que entra na janela de contexto a cada turno. Na maioria dos sistemas em produção, é ali que o dinheiro está indo embora.

Leitura relacionada

Este conteúdo foi elaborado com o auxílio de ferramentas de IA, com base em fontes confiáveis, e revisado pela nossa equipe editorial antes da publicação. Não substitui o aconselhamento de um profissional especializado.