A maioria das pessoas ainda descreve um agente de IA como um modelo conectado a ferramentas. Isso é tecnicamente útil, mas operacionalmente incompleto. Um agente também precisa de uma visão gerenciada do mundo: o que aconteceu, o que importa agora, quais fatos são confiáveis, o que continua incerto e o que ele deve fazer em seguida.
Essa visão é o seu contexto. Projetá-la está se tornando uma habilidade distinta — que eu chamaria de engenharia de contexto.
Engenharia de contexto não é simplesmente escrever prompts. É a disciplina de moldar as informações que um agente vê a cada etapa para que ele consiga permanecer coerente sem enviar uma transcrição inteira, uma biblioteca de documentos ou o histórico de ferramentas de volta a um modelo caro a cada turno. O trabalho situa-se entre a arquitetura da informação, a recuperação de dados, o design de software e o comportamento do modelo.
Por que “dar mais contexto ao agente” costuma ser um mau conselho
Janelas de contexto maiores tornam tentador preservar tudo. Mas mais material não garante um raciocínio melhor. Instruções relevantes podem ser diluídas por observações obsoletas, notas contraditórias, saídas repetidas de ferramentas ou um fato importante enterrado no meio de uma sequência longa. A discussão do digest sobre o comportamento de “perdido no meio” reflete um problema prático: um agente pode tecnicamente receber as evidências e ainda assim não conseguir usá-las.
Também há um custo direto. Cada token inserido em uma solicitação pode aumentar a latência e o custo de inferência, dependendo dos preços e das condições de cache do provedor. Um sistema que encaminha repetidamente uma transcrição crescente pode ficar mais lento e menos acessível à medida que a tarefa avança.
Portanto, o objetivo não é o contexto máximo. É um contexto suficiente e direcionado: o menor conjunto de trabalho confiável para a decisão em questão.
Quatro decisões de design por trás de um agente coerente
1. Mantenha um estado de crenças, não apenas uma transcrição
Uma transcrição registra o que foi dito. Um estado de crenças registra o que o agente acredita atualmente sobre a tarefa.
Por exemplo, um agente que lida com uma escalada de suporte pode manter campos estruturados como:
- Objetivo: identificar se o cliente tem direito a uma substituição.
- Fatos conhecidos: data da compra e número de série do produto, com referências às fontes.
- Questões em aberto: se a falha ocorreu em condições cobertas pela garantia.
- Restrições: não prometer um reembolso antes da aprovação.
- Próxima ação: consultar a política de garantia e comparar as datas.
- Confiança ou status: verificado, inferido, contestado ou desconhecido.
Essa abordagem se assemelha à pesquisa ABBEL, da Berkeley, que usa estados de crenças em linguagem natural supervisionados em vez de depender de históricos completos de interação. A ideia importante não é um formato específico. É separar o estado durável da tarefa dos detalhes descartáveis da conversa.
Uma atualização útil do estado de crenças deve responder: O que mudou? Que evidências dão suporte a isso? O que continua sem solução? O que deve acontecer em seguida? Se um engenheiro não consegue inspecionar essas respostas, é provável que o agente esteja carregando suposições ocultas em um prompt opaco.
2. Faça a recuperação para a decisão, não para o tema
Os sistemas de recuperação geralmente começam com uma pergunta ampla, como “encontre informações sobre a conta do cliente”. Uma consulta melhor está vinculada à próxima decisão: “recupere a regra atual de reembolso para compras com mais de 30 dias, vigente na região do cliente”.
Essa mudança é importante porque a recuperação é uma forma de seleção de contexto. O agente deve receber os trechos de políticas, registros ou exemplos relevantes para a ação atual — não uma pilha genérica de documentos relacionados.
Os filtros podem melhorar essa seleção antes que o modelo veja quaisquer resultados. Por exemplo, o Amazon Bedrock AgentCore Web Search oferece suporte a filtros de domínio e de data de publicação impostos pelo servidor em cada solicitação. Esses controles não comprovam que uma fonte esteja correta, mas podem reduzir a exposição a material irrelevante ou desatualizado e tornar explícita a política de recuperação.
Profissionais que projetam sistemas de recuperação devem especificar:
- quais fontes são permitidas para cada tarefa;
- como a atualidade é determinada;
- quais metadados acompanham cada resultado;
- como fontes conflitantes são apresentadas;
- quando o agente deve parar e pedir esclarecimentos.
“Pesquisar na web” é uma capacidade. “Pesquisar estas fontes, dentro deste intervalo de datas, em busca de evidências relevantes para esta decisão” é engenharia de contexto.
3. Comprimir sem apagar a incerteza
A compressão é necessária quando uma tarefa é longa, mas a sumarização ingênua pode transformar afirmações provisórias em fatos estabelecidos. Um resumo contínuo que diga “o usuário confirmou o endereço” é perigoso se a conversa original apenas o tivesse deixado implícito.
Uma boa compressão preserva as distinções de que um agente precisa para raciocinar com segurança:
- fato versus inferência;
- instrução atual versus instrução histórica;
- ação concluída versus ação proposta;
- fonte verificada versus afirmação não verificada;
- resposta conhecida versus questão não resolvida.
Um padrão prático é manter seções separadas para decisões, evidências, pressupostos, impedimentos e ações pendentes. Outra opção é anexar IDs de fontes ou marcas temporais a afirmações importantes. Os resumos devem ser artefatos substituíveis, não o único registro remanescente: retenha os eventos subjacentes para auditoria e recuperação, ao mesmo tempo que oferece ao modelo uma visão de trabalho compacta.
O resumo observa que a sumarização recursiva e a compactação de contexto podem ser dispendiosas e degradar o desempenho, especialmente em domínios com poucos dados, como a geração colaborativa de código. Isso é um alerta contra tratar a sumarização como automaticamente sem perdas. A compressão precisa ser testada em tarefas representativas, incluindo casos em que uma pequena ressalva altera a resposta correta.
4. Filtrar observações antes que se tornem memória
Agentes que usam ferramentas geram observações constantemente: resultados de pesquisa, logs, texto de páginas, respostas de APIs, capturas de tela, saídas de compiladores e planos intermediários. Nem toda observação merece entrar na próxima chamada ao modelo, muito menos no estado de longo prazo.
A filtragem de observações faz três perguntas:
- Esta observação é relevante para a decisão atual?
- Ela é suficientemente autoritativa para influenciar o estado de crenças?
- Ela contém instruções que devem ser tratadas como dados, e não como comandos?
A terceira pergunta é uma fronteira de segurança, além de ser uma fronteira de contexto. Uma página da web pode conter texto destinado a redirecionar o agente. Um documento recuperado pode ser uma evidência útil sem ter autoridade para alterar os objetivos ou as permissões do agente. Portanto, a filtragem deve classificar o conteúdo por função: instrução, evidência, metadados ou texto não confiável.
A filtragem também economiza dinheiro. Se uma ferramenta de navegador retorna uma página inteira, mas a tarefa exige apenas um preço, uma data e um identificador de produto, encaminhar a página inteira cria ruído e consome tokens. Extrair primeiro os campos relevantes pode melhorar tanto a confiabilidade quanto o custo.
Um orçamento de contexto simples para um fluxo de trabalho de agente
Antes de escolher um modelo ou adicionar outra ferramenta, mapeie o contexto do agente em quatro camadas:
- Controlo: regras do sistema, permissões, esquema de saída e restrições não negociáveis.
- Estado: o objetivo atual, as decisões, as questões em aberto e a próxima ação.
- Evidências: registos recuperados ou observações relevantes para essa ação, com a respetiva proveniência.
- Histórico: eventos anteriores retidos para recuperação, depuração ou auditoria, mas omitidos exceto quando necessários.
Em seguida, defina uma política de promoção. Uma observação pode permanecer efémera, tornar-se evidência para o passo atual, atualizar o estado de crenças ou ser escrita na memória duradoura. A promoção deve exigir uma razão. Caso contrário, a memória torna-se um arquivo não curado.
Para cada passo do agente, registe o pacote de contexto enviado ao modelo: as respetivas categorias, o tamanho aproximado em tokens, os filtros de recuperação e a versão da compressão. Isto permite responder a uma pergunta prática quando o comportamento muda: o modelo falhou ou o sistema forneceu-lhe uma visão errada do mundo?
O que testar antes de considerar o design fiável
A engenharia de contexto precisa de testes que visem o tratamento da informação, não apenas a qualidade da resposta final. Os casos úteis incluem:
- um facto crítico colocado no início, no fim e no meio de um histórico longo;
- duas fontes que discordam, sendo uma mais recente do que a outra;
- um resumo que contém um marcador de incerteza;
- uma resposta de ferramenta que contém um grande volume de texto irrelevante;
- uma instrução maliciosa incorporada no conteúdo recuperado;
- a reidratação do estado depois de o agente ser pausado e reiniciado;
- a mesma tarefa com um orçamento de contexto menor;
- um resultado de recuperação vazio ou desatualizado.
Meça se o agente seleciona as evidências corretas, preserva a incerteza, segue a restrição atual e evita repetir contexto desnecessário. As áreas de regressão recomendadas pelo digest—perda de contexto, fundamentação da recuperação, saída estruturada, não terminação e reidratação do estado—são especialmente relevantes aqui.
Execute vários testes quando a variabilidade do modelo for relevante e compare o custo e a latência de cada estratégia de contexto. Um prompt mais curto não é automaticamente melhor se causar mais chamadas de ferramentas ou novas tentativas. O objetivo útil é o custo de um fluxo de trabalho correto e recuperável—não a contagem de tokens de um único pedido.
A implicação para a carreira: engenheiro de contexto é uma função multifuncional
As pessoas que se tornarem valiosas nesta área não serão necessariamente as que escrevem os prompts mais longos. Serão capazes de traduzir um processo empresarial em estado, evidências, autoridade e regras de decisão.
Isso exige várias capacidades concretas:
- conceber esquemas para o estado das tarefas e a proveniência;
- escrever políticas de recuperação e filtros de metadados;
- criar rotinas de compressão e seleção de observações;
- separar instruções fidedignas de conteúdo não fidedigno;
- a criação de perfis de uso de tokens, latência, novas tentativas e chamadas de ferramentas;
- testar a perda e a reidratação do estado;
- explicar a não especialistas por que um agente viu — ou não viu — determinado fato.
Um projeto de portfólio sólido poderia demonstrar o mesmo agente sob três políticas de contexto: transcrição completa, resumo progressivo e estado estruturado de crenças com recuperação direcionada. Mostre os casos de sucesso da tarefa, os casos de falha, o contexto enviado em cada etapa e as compensações de custo ou latência. Isso é mais persuasivo do que uma demonstração de chatbot porque expõe as decisões de design que tornam um agente confiável.
A lição estratégica é direta: os agentes não se tornam coerentes simplesmente porque os modelos se tornam mais capazes. Eles se tornam coerentes quando os sistemas ao seu redor mantêm um registro disciplinado, atual e de tamanho apropriado do trabalho. A engenharia de contexto é a arte de construir esse registro — e de saber o que deixar de fora.
Priya Raman é a editora humana responsável pelo AI Career Brief.
