Da Engenharia de Prompt à Engenharia de Contexto: o que ainda falta?

Tempo de Leitura: 11 min

Durante algum tempo, parecia que boa parte da qualidade de uma interação com inteligência artificial dependia de saber formular um bom prompt. Isso fazia sentido. Os primeiros modelos exigiam instruções muito mais cuidadosas, e quem aprendia a definir papéis, explicar objetivos, estabelecer restrições, oferecer exemplos e antecipar exceções conseguia resultados claramente melhores. A Engenharia de Prompt ganhou então uma importância quase inevitável, tanto no uso cotidiano quanto na construção das primeiras aplicações e agentes.

Esse aprendizado continua válido, mas o centro da discussão começou a se deslocar.

À medida que os modelos evoluíram e as aplicações se tornaram mais complexas, ficou mais evidente que uma boa instrução, por mais bem escrita que fosse, não resolveria sozinha o problema. A qualidade de uma resposta passou a depender cada vez mais daquilo que o modelo consegue saber naquele momento: documentos, dados, histórico, decisões anteriores, ferramentas disponíveis, memória, resultados de outras etapas e informações recuperadas dinamicamente.

É por isso que dizer simplesmente que a Engenharia de Prompt “morreu” talvez seja exagerado. Ela não desapareceu. O que aconteceu foi que deixou de ocupar sozinha o centro da arquitetura. A pergunta “como instruir melhor o modelo?” continua importante, mas passou a conviver com outra, mais ampla: que informação a IA precisa receber, no momento certo, para atuar bem?

É nesse deslocamento que a Engenharia de Contexto começa a ganhar protagonismo.

Quando o problema deixa de ser apenas a instrução

A mudança é mais profunda do que parece. Em vez de tentar condensar toda a inteligência necessária em um grande prompt, começamos a construir ambientes capazes de fornecer contexto conforme a necessidade. Uma aplicação pode recuperar documentos específicos, consultar uma base, receber o resultado de uma etapa anterior, acessar uma ferramenta ou carregar apenas a parte relevante da memória para aquela interação.

Isso aproxima muito mais a IA das condições reais do trabalho profissional. Afinal, uma pessoa também não desempenha bem uma função apenas porque recebeu uma boa instrução. Ela precisa conhecer o caso, compreender o ambiente, saber quais critérios estão em jogo, reconhecer decisões já tomadas e distinguir aquilo que é relevante daquilo que é apenas informação disponível.

A Engenharia de Contexto representa, portanto, um avanço importante. Mas ela também traz um novo risco: podemos substituir a antiga obsessão pelo “prompt perfeito” por uma nova obsessão pelo “contexto máximo”.

Ter mais contexto não significa necessariamente estar melhor contextualizado.

Um profissional pode receber cinquenta páginas de histórico antes de tomar uma decisão e continuar sem saber o que realmente importa. Um modelo pode ter acesso a uma enorme base documental e ainda assim não conseguir distinguir uma evidência decisiva de uma informação periférica. Em determinadas situações, receber uma conclusão anterior pode inclusive prejudicar o trabalho seguinte, porque cria uma ancoragem justamente quando seria desejável preservar um julgamento independente.

Foi ao observar esse tipo de problema que uma pergunta se tornou cada vez mais importante para mim: contexto para quê?

Essa pergunta parece simples, mas muda a ordem do raciocínio.

Antes de decidir o contexto, precisamos compreender o momento

Na abordagem P3HD, partimos do trabalho real para descobrir onde a qualidade do pensamento ainda pode alterar significativamente o resultado. Esses pontos são chamados de Momentos Cognitivos.

Um Momento Cognitivo não é simplesmente uma etapa de processo. É uma situação em que compreender, interpretar, relacionar informações, comparar alternativas, formular critérios, confrontar hipóteses, julgar ou escolher pode produzir uma diferença material no resultado.

Essa distinção se torna especialmente útil quando pensamos em Engenharia de Contexto porque desloca a unidade de análise. Em vez de começarmos perguntando quais documentos uma IA deve receber ou quais ferramentas um agente deve acessar, começamos tentando compreender o que precisa cognitivamente acontecer naquele ponto do trabalho.

Talvez o profissional precise interpretar uma exceção. Em outro momento, precise comparar alternativas. Em outro, formular um critério antes de qualquer recomendação. Em uma revisão, talvez seja importante que uma segunda pessoa construa sua própria leitura sem conhecer antecipadamente a conclusão anterior. Em uma tarefa mais operacional, o desafio pode ser apenas localizar uma informação objetiva e seguir adiante.

Cada uma dessas situações pede um contexto diferente.

Isso nos leva a uma formulação que considero especialmente importante para a relação entre P3HD e Engenharia de Contexto: o contexto não deveria ser desenhado apenas a partir daquilo que temos disponível, mas a partir daquilo que a próxima função cognitiva precisa conseguir fazer.

A partir daí, o contexto deixa de ser um acervo e passa a ser parte da arquitetura do trabalho.

Context Pack: contexto preparado para continuar pensando

É nesse ponto que o conceito de Context Pack ganha utilidade.

Na P3HD, um Context Pack pode ser entendido como o conjunto de contexto adequado para sustentar uma próxima função cognitiva. Isso não significa carregar tudo o que aconteceu anteriormente, nem transportar integralmente todos os documentos disponíveis. Significa selecionar aquilo que permitirá à próxima pessoa, IA ou combinação humano-digital compreender o suficiente para continuar bem o trabalho.

Imagine que uma primeira etapa tenha produzido uma análise extensa. Um gestor que receberá o caso depois talvez precise conhecer a decisão, os critérios utilizados, as principais evidências e as incertezas ainda abertas. Um revisor independente pode precisar receber as evidências e os critérios, mas não a recomendação anterior. Um agente encarregado de verificar requisitos objetivos talvez precise de um subconjunto ainda menor e muito mais estruturado.

O histórico é o mesmo, mas a necessidade cognitiva é diferente.

Essa percepção ajuda a evitar uma ideia bastante comum quando começamos a construir sistemas com IA: a de que a melhor solução é disponibilizar tudo para todos o tempo inteiro. Em muitos casos, uma arquitetura de contexto de qualidade depende tanto daquilo que decidimos entregar quanto daquilo que deliberadamente não entregamos.

Por isso, a Engenharia de Contexto não deveria ser apenas uma questão de recuperação de informação. Ela também exige uma Política de Contexto: o que deve chegar, quando, para quem, com qual origem, em que nível de confiança e sob quais restrições.

Contextualizar também é decidir o que não deve influenciar

Esse ponto se torna ainda mais importante quando existe julgamento humano envolvido.

Suponha que uma pessoa precise revisar uma decisão anterior de forma independente. Se o sistema entrega imediatamente uma síntese muito bem argumentada da primeira análise, pode tornar o trabalho mais rápido, mas também pode reduzir sua independência. O contexto, nesse caso, passa a exercer influência cognitiva sobre a revisão.

A mesma questão aparece com IA. Se um modelo recebe uma hipótese já formulada como se fosse fato, sua exploração posterior tende a partir daquele enquadramento. Se recebe uma conclusão anterior sem uma indicação clara de sua origem ou grau de confiança, pode tratá-la como contexto legítimo e reforçar um erro.

Isso mostra que projetar contexto não é simplesmente otimizar acesso à informação. É também desenhar as condições em que o raciocínio acontecerá.

Na P3HD, essa decisão está diretamente relacionada ao que chamamos de Projeto Humano-Digital. Depois de reconhecer um Momento Cognitivo, precisamos decidir qual papel cabe às capacidades humanas e digitais naquele ponto. Em alguns casos, faz sentido delegar. Em outros, a melhor relação é de cocriação. E há situações em que o julgamento deve permanecer explicitamente humano.

Essas escolhas alteram a própria arquitetura de contexto.

Uma IA que apenas verificará uma condição objetiva precisa de um tipo de contexto. Uma IA que ajudará a explorar hipóteses precisa de outro. Uma IA que prepara material para uma decisão humana pode precisar ser deliberadamente impedida de fechar aquela decisão por conta própria.

Por isso, não basta perguntar como aumentar a capacidade do modelo. É preciso perguntar que relação entre pessoa e tecnologia estamos tentando sustentar naquele momento.

OCP e Context Pack não são a mesma coisa

Essa discussão também ajuda a esclarecer a relação entre dois conceitos que usamos na P3HD.

Um Objeto Cognitivo Portátil, ou OCP, preserva uma estrutura de clareza construída em uma sessão ou Jornada. Ele pode registrar perguntas, critérios, hipóteses, evidências, decisões, incertezas e outros elementos que tornem aquele raciocínio recuperável fora do momento em que foi produzido.

O OCP, portanto, serve à portabilidade do pensamento.

Mas ele não precisa ser entregue integralmente à próxima pessoa ou à próxima IA. Pode funcionar como uma fonte qualificada para a construção de um Context Pack específico.

Essa diferença é importante porque resolve duas necessidades que muitas vezes são confundidas. De um lado, queremos preservar aquilo que foi aprendido ou decidido para que não desapareça dentro de uma conversa. De outro, não queremos transportar automaticamente todo esse conteúdo para qualquer situação futura.

A continuidade exige preservação. A contextualização exige seleção.

Quanto mais sistemas com IA passarem a atuar em cadeias de trabalho reais, mais importante essa diferença se tornará.

O problema seguinte: como o trabalho continua pensando?

A Engenharia de Contexto normalmente aparece em torno de uma interação: como preparar o modelo para responder bem agora?

Mas o trabalho profissional raramente termina em uma única interação.

Uma pessoa interpreta uma situação, uma IA ajuda a organizar informações, uma decisão é tomada, um artefato é produzido, outra pessoa recebe esse resultado, um sistema executa alguma consequência e uma nova decisão surge depois. A qualidade do trabalho depende tanto do que acontece dentro de cada etapa quanto daquilo que consegue atravessar as passagens entre elas.

É aí que entramos no território da Continuidade Cognitiva.

Continuidade Cognitiva é a capacidade de preservar e transformar contexto, critérios, decisões e aprendizagem à medida que o trabalho avança entre pessoas, etapas e sistemas. O desafio deixa de ser apenas oferecer o contexto correto para uma chamada e passa a ser garantir que aquilo que foi compreendido não precise ser reconstruído continuamente.

Essa diferença pode parecer conceitual, mas tem uma consequência muito prática. A IA está reduzindo drasticamente o custo de produção de textos, análises, sínteses, alternativas e artefatos. Em contrapartida, se não soubermos preservar e transportar o que realmente importa, podemos criar um novo tipo de desperdício: produzir muito mais e continuar reconstruindo o pensamento sempre que o trabalho muda de mãos ou de ferramenta.

Nesse sentido, uma boa Engenharia de Contexto melhora uma interação. Uma boa arquitetura de Continuidade Cognitiva permite que o trabalho continue pensando.

Quando o contexto passa a fazer parte de uma arquitetura de execução

Há ainda outro movimento acontecendo. À medida que deixamos de usar IA apenas como interlocutor e começamos a construir agentes capazes de utilizar ferramentas, consultar fontes, repetir ações, avaliar resultados e tomar decisões intermediárias, o problema passa novamente a ter uma escala maior.

Não basta definir o que o modelo deve saber. Precisamos também projetar o ambiente em que ele poderá agir.

É nesse território que começa a aparecer o termo Harness Engineering, associado ao desenho do sistema que envolve o modelo: quando ele deve chamar uma ferramenta, quando precisa recuperar informação adicional, quando deve verificar a própria saída, quando precisa parar, quando requer confirmação humana e como o estado deve ser preservado entre diferentes iterações.

Essa evolução é interessante porque mostra que o próprio mercado está gradualmente se afastando da ideia de que a inteligência da aplicação está concentrada no modelo. O modelo passa a ser um componente dentro de uma arquitetura informacional e operacional maior.

O que me parece faltar, em muitos casos, é tornar explícita a arquitetura cognitiva que deveria orientar essas escolhas.

É possível construir um excelente mecanismo de recuperação de contexto e ainda fornecer a informação errada no momento errado. É possível criar um loop sofisticado de agentes e ferramentas e automatizar justamente o ponto em que o julgamento profissional deveria ter sido preservado. É possível construir memória persistente e, com isso, perpetuar interpretações que deveriam ter sido revistas.

É por isso que vejo Prompt Engineering, Context Engineering, Harness Engineering e P3HD menos como alternativas entre si e mais como diferentes camadas de um mesmo problema.

A Engenharia de Prompt continua cuidando da qualidade das instruções. A Engenharia de Contexto amplia o foco para o ambiente informacional. A Harness Engineering organiza o ambiente operacional em que o modelo executa suas ações. A P3HD procura investigar o território de trabalho para descobrir que arquitetura cognitiva deveria orientar essas decisões.

Antes da arquitetura da IA, a arquitetura do trabalho

Esse talvez seja o ponto que mais me interessa nessa discussão.

Quando começamos um projeto pela tecnologia, é natural perguntar qual modelo usar, quais ferramentas disponibilizar, que dados integrar ou como organizar agentes. Todas essas perguntas serão necessárias em algum momento. O problema surge quando ainda não sabemos claramente que decisões o trabalho precisa sustentar, que contexto deveria chegar a elas ou onde a intervenção da tecnologia pode ampliar ou empobrecer o julgamento profissional.

Na P3HD, a investigação começa antes.

Qual é o propósito daquele trabalho? Qual problema estamos tentando atravessar? Onde existe Densidade Cognitiva? Em quais situações pensar melhor ainda altera significativamente o resultado? O que precisa permanecer sob julgamento humano e onde a capacidade digital pode assumir esforço, ampliar repertório ou ajudar na exploração? Que contexto precisa sobreviver de uma passagem para outra?

Só depois dessas perguntas a discussão sobre memória, documentos, ferramentas, agentes ou automação ganha uma referência mais sólida.

Essa é a camada cognitiva que existe entre a realidade do trabalho e sua implementação computacional.

Ela não substitui a Engenharia de Contexto. Ao contrário, pode ajudá-la a se tornar mais precisa.

Talvez a grande mudança não seja o fim dos prompts

Talvez, daqui a alguns anos, olhemos para a fase da Engenharia de Prompt não como algo que desapareceu, mas como um primeiro momento de uma aprendizagem mais ampla sobre a relação entre pessoas e modelos de IA.

Primeiro percebemos que a forma de pedir importava. Depois descobrimos que aquilo que o modelo tinha disponível no contexto importava tanto ou mais. Agora estamos percebendo que também precisamos desenhar os ambientes em que esses modelos atuam, as ferramentas que podem utilizar, os limites que precisam respeitar e as formas pelas quais seu trabalho se conecta ao trabalho das pessoas.

O próximo passo pode ser reconhecer que todas essas escolhas dependem de uma compreensão anterior daquilo que o trabalho precisa cognitivamente sustentar.

Isso muda bastante a pergunta.

Em vez de buscar apenas uma IA que tenha mais contexto, começamos a buscar uma arquitetura capaz de entregar o contexto adequado à função cognitiva adequada, no momento adequado e dentro de uma relação humano-digital deliberadamente escolhida.

É dessa forma que vejo a contribuição da P3HD para a Engenharia de Contexto.

Não se trata de propor uma nova técnica para alimentar modelos, mas de investigar o trabalho antes de decidir como contextualizá-los. O Context Pack deixa de nascer apenas daquilo que o sistema consegue recuperar e passa a nascer daquilo que a próxima função precisa compreender. A Continuidade Cognitiva deixa de ser simples persistência de memória e passa a cuidar daquilo que precisa sobreviver para que pessoas e sistemas consigam continuar pensando.

No fundo, a questão continua sendo aquela que orienta a investigação P3HD:

onde pensar melhor ainda pode mudar significativamente o resultado?

A Engenharia de Contexto acrescenta então uma segunda pergunta que me parece cada vez mais importante:

que contexto precisamos construir ao redor desses momentos para que capacidades humanas e digitais consigam desempenhar adequadamente seus papéis?

Talvez seja aí que a evolução da Engenharia de Prompt se torne realmente interessante: quando deixamos de procurar apenas maneiras melhores de conversar com a IA e começamos a projetar condições melhores para que o trabalho, como um todo, consiga pensar com ela.