Arthur Guttilla Head of Product Marketing, Strattum Com passagens na Amazon Web Services e no Google, Guttilla trabalhou diretamente com fundadores de startups e empresas de capital de risco, compreendendo as necessidades de empresas tecnológicas em estágio inicial na interseção entre tecnologia e negócios.
Prompt engineering respondeu à primeira pergunta que aparece quando alguém começa a usar um modelo: como pedir.
À medida que agentes passam a ocupar o centro dos produtos, a pergunta que decide o resultado é outra. Que informação colocar diante do modelo, e em que momento.
É esse trabalho que se chama context engineering.
A diferença aparece quando um agente sai do protótipo. Dois times podem partir do mesmo modelo, do mesmo framework e da mesma base de documentos e chegar a resultados muito distantes. O que separa os dois é o que cada um decidiu colocar na janela de contexto de cada chamada.
Essas decisões são de engenharia e podem ser tratadas como tal. Têm critério, têm custo e podem ser medidas.
Retrieval-Augmented Generation foi um salto. Deu ao modelo uma forma de alcançar informação que não estava nos seus pesos e resolveu boa parte do problema de acesso.
Context engineering faz uma pergunta mais difícil. Dada uma janela de contexto limitada, qual é a melhor combinação possível de informação para o modelo executar esta tarefa, agora?
Recuperar trechos relevantes é uma das respostas possíveis. Ela divide o espaço da janela com tudo o mais que precisa estar lá.
Em um agente em produção, uma única chamada costuma acumular:
Cada um desses elementos ocupa espaço que os outros deixam de ter. A tarefa é escolher o conjunto certo, na ordem certa, no momento certo.
Encher a janela é a decisão mais fácil de tomar e a mais cara de manter.
Antes de qualquer recuperação acontecer, o modelo precisa saber o que existe à disposição.
O roteamento já é uma decisão de contexto. Definir se uma pergunta sobre receita vai para o data warehouse, para o CRM ou para a política financeira que está em documento determina tudo o que vem depois dela.
Quando essa escolha é deixada para o modelo sem que as fontes estejam descritas, ele adivinha. E adivinha de novo na execução seguinte, porque nada do que funcionou na primeira ficou registrado em algum lugar.
Descrever quais fontes existem, o que cada uma contém e quando cada uma é a correta é trabalho de contexto feito antes da primeira query.
Janelas de contexto são finitas e crescem mais devagar do que o volume de informação que uma empresa gostaria de colocar dentro delas.
Resumir o conteúdo recuperado, ordenar resultados por relevância ou por data, cortar trechos redundantes. Isoladamente são escolhas pequenas, e o efeito delas se acumula ao longo de uma execução inteira.
A ordem pesa mais do que costuma parecer. O mesmo conjunto de dez documentos produz respostas diferentes conforme qual deles aparece primeiro.
O mesmo vale para o que está desatualizado. Quatro versões de uma política na mesma janela obrigam o modelo a escolher entre elas, e ele vai escolher com o critério que tiver à mão.
Em agentes conversacionais, o que é guardado entre sessões pesa tanto quanto o que está na janela atual.
Isso exige decidir o que merece ser lembrado. Uma correção feita pelo usuário, uma preferência declarada, uma exceção que se repete: cada um desses sinais pode virar contexto durável ou pode se perder quando a conversa termina.
E exige decidir o que é recuperado, e quando. Memória que volta inteira a cada chamada deixa de funcionar como memória e passa a ocupar tokens sem devolver sinal.
Um agente que guarda e recupera bem melhora com o uso. É o mesmo mecanismo que faz uma pessoa nova no time render mais no segundo mês do que no primeiro.
Boa parte do ganho vem de dividir o trabalho.
Workflows bem desenhados quebram uma tarefa complexa em etapas, e cada etapa carrega o contexto enxuto de que precisa. Cada chamada fica com menos ruído, e um erro fica contido na etapa em que aconteceu.
Isso também torna o sistema observável. Quando uma resposta sai errada em uma chamada monolítica com tudo dentro, é difícil saber qual pedaço do contexto causou o problema. Em etapas, dá para apontar.
Sistemas construídos assim tendem a ser mais rápidos, mais baratos de operar e mais previsíveis quando algo muda.
Todas essas decisões se repetem a cada agente novo.
Quando cada projeto resolve a seleção de fontes, a compressão, a ordenação e a memória por conta própria, o segundo agente refaz o trabalho do primeiro com critérios diferentes. A empresa termina com duas versões do que é verdade sobre ela, e nenhuma das duas sabe da outra.
É por isso que parte dessas decisões pertence a uma camada compartilhada. Quais fontes existem, o que cada uma significa, qual versão de um documento está em vigor, quem pode ver o quê: isso é contexto empresarial, e pode ser construído uma vez.
Context engineering é o trabalho de decidir o que chega ao modelo. Ter esse trabalho feito uma vez e reutilizável é o que muda a economia de colocar o próximo agente em produção.
Agende uma conversa de 30 minutos. Mostramos a Strattum operando sobre sistemas como os seus.