A inteligência artificial sugere uma solução elegante, mas usa uma biblioteca que o projeto não possui, ignora uma regra existente ou altera o módulo errado. A reação mais comum é reformular o pedido, trocar de modelo ou aumentar o esforço de raciocínio. Antes disso, vale uma pergunta: quais informações estavam disponíveis quando a resposta foi produzida?

Este é o segundo artigo da série IA na prática: do protótipo à operação responsável. Depois de separar experimentação e desenvolvimento controlado, o próximo passo é organizar aquilo que o modelo precisa saber. Vamos explicar engenharia de contexto, aplicar o conceito a uma tarefa Delphi e propor um modo de manter informações úteis sem transformar cada pedido em um arquivo gigantesco.

Quando a resposta parece boa, mas ignora o ambiente real, precisamos organizar mais do que a frase do pedido. IA Além da Conversa aprofunda a relação entre contexto, dados, recuperação, ferramentas e avaliação: as camadas que permitem transformar uma conversa em uma solução operável. Conheça a proposta e leia a degustação gratuita para avaliar esse percurso antes de escolher a próxima ferramenta. Para converter essas informações em regras, restrições e critérios de aceite no seu projeto, SDD em Delphi oferece uma leitura complementar.

O que é contexto e o que muda nesse paradigma

Contexto é o conjunto de informações disponibilizado ao modelo em uma solicitação: instruções, mensagens anteriores, trechos de código, documentos e resultados de ferramentas, conforme a integração utilizada. Não é sinônimo de todo o conhecimento da organização. Um arquivo existente no computador pode não ter sido lido, e um texto enviado anteriormente pode não estar integralmente disponível na etapa atual.

O prompt é a instrução ou solicitação apresentada ao modelo. Engenharia de contexto é o trabalho de selecionar, organizar e atualizar o conjunto de informações que acompanha essa solicitação. A Anthropic apresenta essa distinção como uma ampliação do foco: não basta ajustar a frase principal quando outras informações também influenciam a tarefa.

Um token é uma unidade utilizada pelo modelo para processar texto e outros conteúdos, conforme sua representação. Não corresponde necessariamente a uma palavra. A janela de contexto é o limite de informações que uma configuração consegue receber em determinado processamento. O limite efetivo depende do modelo e da integração; este artigo não assume uma capacidade comum entre fornecedores.

A mudança de paradigma é sair da ideia de uma pergunta isolada e pensar em um ambiente de trabalho informacional. O pedido continua importante, mas passa a ter uma base: objetivo, materiais relevantes, estado atual e critérios. A proposta não é encontrar uma frase que impeça qualquer erro. É diminuir ambiguidades que podemos identificar e controlar.

Uma analogia útil é a preparação de uma tarefa para outro desenvolvedor. Entregar uma demanda sem informar o ambiente dificulta o trabalho; entregar uma pasta inteira sem indicar o problema também não ajuda necessariamente. O limite da analogia é que o modelo não tem o mesmo entendimento ou responsabilidade de uma pessoa. Por isso, o resultado continua precisando de verificação.

Separe regras, evidências e estado da tarefa

Como organização inicial, proponho três camadas. A primeira reúne regras relativamente estáveis: versão do ambiente, convenções, restrições e comandos aprovados. A segunda contém evidências da tarefa: código relevante, mensagens de erro, dados fictícios de reprodução e documentação consultada. A terceira registra o estado do trabalho: hipóteses, decisões e verificações ainda pendentes.

Essas camadas não devem ser tratadas como equivalentes. Uma mensagem de erro é uma observação, não uma regra de negócio. Uma hipótese gerada pela IA ainda não é uma conclusão. Um comentário antigo pode explicar uma intenção, mas precisa ser confrontado com a implementação e com a especificação vigente.

Comece identificando a origem e a data de cada material quando isso alterar a compreensão. Se há duas versões de um contrato, declare qual vale para o exercício e preserve a divergência como informação. Não deixe o modelo decidir silenciosamente que o documento mais longo ou a mensagem mais recente tem autoridade sobre os demais.

Também registre o que falta. Uma tarefa pode estar bloqueada pela ausência do formato de arquivo ou pela impossibilidade de reproduzir uma falha. Nesse caso, uma entrega útil é formular a pergunta que permitirá avançar. Completar lacunas com suposições não deve ser confundido com produtividade.

Um pacote de contexto para uma manutenção Delphi

Retomemos o caso fictício de importação de pedidos apresentado na abertura da série sobre vibe coding. Agora a tarefa é investigar por que registros incompletos aparecem como válidos na prévia. Nenhum pedido será gravado: o escopo continua limitado ao demonstrador.

O pacote inicial pode informar o objetivo em um parágrafo: preservar a ordem dos registros e indicar campos obrigatórios ausentes sem modificar os dados originais. Em seguida, declare o ambiente do exercício, como Delphi 12 e uma aplicação VCL, biblioteca de interfaces para Windows. Essa versão é uma escolha do exemplo, não uma exigência geral da técnica.

Inclua o ponto de entrada da importação, o trecho que interpreta o registro e a função que decide sua situação. Explique como essas partes se relacionam. Se a classificação é feita antes de a tela receber os dados, enviar apenas o evento visual pode desviar a investigação. O material deve acompanhar o percurso do comportamento que falhou.

Forneça entradas inventadas e a saída esperada. Por exemplo, um campo obrigatório contendo apenas espaços deve ser considerado ausente, se essa for a regra acordada. Declare também o comportamento de uma linha cujo formato não pode ser interpretado. Essas regras são propostas para o caso fictício, não regras presumidas de qualquer ERP.

Por fim, apresente restrições: não alterar o formato do arquivo, não adicionar dependências e não modificar rotinas de gravação. Peça que a resposta separe evidência, hipótese e ajuste sugerido. O pacote não foi executado em um modelo neste artigo; trata-se de um roteiro ilustrativo para preparar uma avaliação reproduzível.

O ganho esperado é tornar a tarefa conferível. Se o modelo sugerir uma função ausente na versão escolhida, isso pode ser identificado. Se alterar persistência, ultrapassou o escopo. Se explicar a tela sem examinar a classificação, a investigação ficou incompleta. Critérios claros permitem discutir falhas específicas em vez de apenas classificar a resposta como “ruim”.

Carregar tudo não é uma estratégia de seleção

Uma base grande pode conter materiais úteis, mas também versões antigas, saídas repetidas e arquivos sem relação com o problema. A documentação da Anthropic citada anteriormente recomenda curadoria do contexto e discute estratégias de recuperação e compactação. Essas orientações são do fornecedor; não constituem uma medição de ganho para este projeto.

Minha proposta é começar com um mapa pequeno. Informe quais módulos participam do comportamento e disponibilize os arquivos correspondentes. Quando surgir uma dependência relevante, amplie o conjunto. O mapa deve orientar a investigação sem afirmar que relações não verificadas já foram comprovadas.

Se o agente pode ler arquivos, deixe claras as fronteiras de acesso. Identificar um caminho não equivale a disponibilizar seu conteúdo, e disponibilizar conteúdo não autoriza executar comandos arbitrários. O sistema ao redor do modelo precisa aplicar permissões; uma recomendação escrita pode orientar, mas não substitui um controle técnico.

Informações sensíveis exigem uma decisão anterior ao envio. Remova credenciais e dados reais de clientes do exemplo. Quando uma falha depender de características dos dados, preserve a estrutura relevante em registros fictícios. Se não for possível produzir uma reprodução adequada, documente a limitação e use um ambiente autorizado para a análise.

Buscar durante o trabalho e preservar o que foi encontrado

Uma API é uma interface que permite a comunicação entre programas. Um agente pode usá-la, ou outra ferramenta, para obter informações durante a tarefa. Essa recuperação pode acontecer conforme a necessidade, em vez de concentrar todos os documentos na primeira solicitação. O resultado consultado também passa a fazer parte do contexto disponível.

Buscar depois exige rastreabilidade. Registre o arquivo, a referência ou o trecho que sustenta uma conclusão. Se uma ferramenta devolveu uma lista incompleta, essa condição deve acompanhar o resultado. Não transforme “não encontrei na consulta realizada” em “não existe no sistema” sem verificar o alcance da busca.

Para a importação fictícia, uma consulta inicial pode revelar que a decisão de validade depende de outra função. O próximo passo é examinar essa função e seus usos, não pedir ao modelo que imagine sua implementação. O ciclo se torna: pergunta delimitada, consulta, evidência, hipótese e verificação.

O tema tem relação com o artigo sobre compactação de contexto no RadIA. Aqui, o foco não é uma versão do plugin, mas o critério editorial de preservar decisões e referências quando o trabalho precisa continuar por várias etapas.

Memória de trabalho não é histórico completo

Manter todas as mensagens pode criar uma falsa sensação de continuidade. A equipe precisa conseguir distinguir decisões vigentes de sugestões descartadas. Como procedimento, proponho um registro curto com objetivo, fatos confirmados, hipótese atual, ações realizadas e próximo teste. Isso é um artefato de trabalho, não uma garantia de que o modelo lembrará corretamente.

Quando uma hipótese for refutada, marque-a como refutada. Se a validação de espaços já foi conferida e não explica o erro, esse resultado deve impedir a repetição da mesma investigação sem motivo. Um resumo que preserva apenas a conclusão mais recente pode apagar justamente a evidência necessária para evitar esse retorno.

Compactação é a redução de um histórico ou conjunto de informações para uma representação menor. Um resumo pode omitir detalhes importantes; por isso, preserve acesso às fontes e indique quais decisões precisam ser mantidas literalmente. Para regras sensíveis, a referência original deve continuar disponível para conferência.

No caso fictício, o registro poderia informar que a prévia preserva a ordem, mas considera um campo preenchido quando contém somente espaços. O próximo teste seria conferir a função responsável por essa decisão. Se ainda não houve execução, escreva “verificação pendente”, não “erro confirmado”. O estado da tarefa precisa representar o que aconteceu, não o que parece provável.

Figura: organização autoral de um pacote de contexto. As camadas orientam a preparação; não garantem correção nem representam resultados medidos.

Contexto também precisa de fronteiras de confiança

A informação consultada pode conter instruções que não vieram do usuário. Um comentário de código ou um documento externo pode tentar mandar o agente ignorar regras e realizar outra ação. A OWASP descreve esse risco na discussão sobre prompt injection, isto é, injeção de instruções no processamento do modelo.

Marcar materiais como dados ajuda a organizar a intenção, mas não deve ser apresentado como proteção infalível. Para uma aplicação, restrinja ferramentas e valide argumentos fora do modelo. Para o trabalho cotidiano, revise ações propostas e não conceda automaticamente autorização porque uma fonte consultada pediu uma operação.

Na preparação de contexto, uma boa pergunta é: esta informação explica a tarefa ou pretende controlar a execução? O texto de um manual pode informar o formato esperado de uma entrada. Não pode, só por estar no manual, autorizar acesso a arquivos privados, envio de dados ou instalação de uma dependência.

A segurança será aprofundada no último artigo da trilha, mas começa aqui. Organizar contexto não é apenas escolher o que incluir. É preservar origem, validade, escopo e autoridade. Sem essa separação, uma base informativa maior pode aumentar a superfície de decisões indevidas.

Como avaliar se a preparação melhorou o trabalho

Escolha uma tarefa com critérios verificáveis e compare o pacote organizado com a instrução utilizada anteriormente. Registre materiais, configurações e resultado. Não é necessário anunciar uma porcentagem de ganho; basta identificar se a resposta passou a respeitar o ambiente, localizar a evidência relevante e produzir uma alteração revisável.

Observe também o custo de preparar e manter o material. Uma documentação que exige atualização manual extensa para cada pedido pode não compensar. Regras estáveis podem ser reutilizadas; evidências específicas devem acompanhar a tarefa. A próxima etapa da série mostrará como arquivos de instruções e habilidades reutilizáveis podem apoiar essa separação.

Para critérios de modelo e configuração, consulte a comparação final da série sobre modelos de IA. Contexto e capacidade precisam ser avaliados juntos: melhorar o material não torna qualquer modelo adequado, mas trocar o modelo também não elimina uma especificação incompleta.

Conclusão

Engenharia de contexto é preparar e manter as informações necessárias para uma tarefa, preservando a diferença entre regras, evidências e estado. O conceito amplia a atenção dada ao prompt: a pergunta principal importa, mas não atua sozinha quando o modelo recebe arquivos, histórico e respostas de ferramentas.

Para começar, monte um pacote pequeno com objetivo, ambiente, trechos relevantes e exemplos de resultado esperado. Registre o que foi comprovado e o que permanece pendente. Amplie o material quando uma dependência justificar isso, em vez de enviar tudo sem seleção.

O aprendizado central é que contexto útil não se mede somente pelo tamanho. Ele precisa permitir uma decisão rastreável e uma entrega que possa ser verificada. No próximo artigo, a trilha avança para instruções de projeto, AGENTS.md e skills, sem confundir orientação textual com autorização técnica.

Se a seleção de contexto se tornou uma dificuldade recorrente, IA Além da Conversa amplia a discussão para recuperação, memória, estado e operação. O aprofundamento ajuda a enxergar essas peças como decisões de arquitetura, não como uma conversa maior. Consulte o sumário e a degustação gratuita para avaliar quais partes desse percurso atendem ao seu projeto.

Referências

ANTHROPIC. Effective context engineering for AI agents. Publicação online, 29 set. 2025. Disponível em: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents. Acesso em: 2 out. 2026.

OWASP. LLM01:2025 Prompt Injection. Publicação online, [s. d.]. Disponível em: https://genai.owasp.org/llmrisk/llm01-prompt-injection/. Acesso em: 2 out. 2026.

SILVEIRA, Régys Borges da. Como escolher modelos de IA para programação: comparação final da série. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/como-escolher-modelos-de-ia-para-programacao-comparacao-final-da-serie/. Acesso em: 2 out. 2026.

SILVEIRA, Régys Borges da. IA Além da Conversa. Livros Régys Borges da Silveira, [s. d.]. Disponível em: https://livros.regys.com.br/ia-alem-da-conversa. Acesso em: 2 out. 2026.

SILVEIRA, Régys Borges da. RadIA 2.3.0: como compactar o contexto da IA pode mudar a forma de programar no Delphi. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/radia-2-3-0-como-compactar-o-contexto-da-ia-pode-mudar-a-forma-de-programar-no-delphi/. Acesso em: 2 out. 2026.

SILVEIRA, Régys Borges da. SDD em Delphi. Livros Régys Borges da Silveira, [s. d.]. Disponível em: https://livros.regys.com.br/sdd-em-delphi. Acesso em: 2 out. 2026.

SILVEIRA, Régys Borges da. Vibe coding: o que é, quando ajuda e quando vira um problema. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/vibe-coding-o-que-e-quando-ajuda-e-quando-vira-um-problema/. Acesso em: 2 out. 2026.