Prompt não é instrução. Contexto é o recurso que o modelo usa para raciocinar

A maior parte das pessoas ainda aborda prompts como comandos. Você instrui o modelo, o modelo executa. Quanto mais claro o comando, melhor o resultado. Essa intuição não está errada, mas está incompleta de uma forma que importa quando você está construindo sistemas que precisam ser confiáveis.

O modelo não executa instruções. Ele raciocina sobre o que está no contexto.

O que isso muda na prática

Quando você passa uma instrução sem contexto, o modelo preenche os espaços em branco com o que tem disponível no treinamento. Às vezes isso é o suficiente. Na maioria das situações onde o output precisa ser preciso, consistente, e específico para um domínio, não é.

O que determina a qualidade do output não é a clareza da instrução. É a riqueza do contexto que o modelo tem para raciocinar sobre o problema.

Isso é fácil de demonstrar: pegue a mesma pergunta sobre um processo interno da sua empresa e faça ao modelo com e sem o documento que descreve esse processo. O modelo com instrução clara mas sem contexto vai gerar uma resposta genérica razoável. O modelo com contexto específico vai gerar uma resposta que reflete o processo real, as exceções, as nuances que estão na documentação.

Context engineering é diferente de prompt engineering

O que ficou conhecido como prompt engineering é em grande parte a arte de escrever instruções mais claras. Isso tem valor, mas tem teto.

Context engineering é diferente: é a decisão de o que colocar no contexto, em que formato, em que ponto do raciocínio, para qual modelo. Essas decisões têm impacto muito maior na qualidade do output do que a formulação da instrução.

No Athena, o sistema que gera queries SQL para o TOTVS Protheus, a maior parte do trabalho de engenharia não foi na instrução. Foi na construção do contexto: quais tabelas são relevantes para cada tipo de pergunta, como as regras de negócio de cada empresa afetam os filtros, qual o formato de representação de schema que o modelo usa melhor para gerar queries corretas. A instrução final é simples. O contexto que ela opera sobre é denso e estruturado.

Quando o sistema começou a gerar queries incorretas, a solução raramente era reformular a instrução. Quase sempre era adicionar ou reorganizar o contexto: incluir um exemplo da query correta para casos semelhantes, adicionar a regra de negócio que estava faltando, reestruturar como as informações de tabela eram apresentadas.

O que o modelo faz com contexto vs. sem contexto

Um experimento simples ilustra a diferença:

Pergunta: "Como aprovar uma solicitação de férias?"

• Sem contexto: resposta genérica sobre processos de RH
• Com o manual de RH no contexto: resposta específica ao processo da empresa, incluindo quem aprova, qual sistema, quais exceções existem
• Com o manual e exemplos de aprovações anteriores: resposta que também antecipa casos especiais que aparecem na prática

Cada camada de contexto não está seguindo uma instrução mais precisa. Está dando ao modelo mais material para raciocinar.

O limite de contexto como restrição real

O que torna context engineering uma disciplina técnica, e não só uma prática de escrever mais, é que contexto é finito e caro.

Cada token no contexto tem custo: latência, custo de API, espaço que poderia ser ocupado por outro dado. Colocar tudo que você tem no contexto não é a estratégia correta. A decisão certa é colocar o que é mais relevante para o problema específico que o modelo está resolvendo naquela chamada.

Isso leva a perguntas que se tornam fundamentais no design de agentes em produção: como você decide o que entra no contexto de cada chamada? Como você representa informação de forma que o modelo usa bem? Como você mantém contexto consistente em conversas longas sem que a informação antiga polua as respostas novas?

Essas não são perguntas de prompt. São perguntas de arquitetura.

O que você está incluindo no contexto dos modelos que você usa hoje que não está contribuindo para a qualidade do output?