"Prompt engineer" nunca foi um cargo preciso, mas por um tempo não precisou ser. Se todo o seu trabalho era conseguir uma única boa resposta de uma única chamada de inferência, um único conjunto de habilidades bastava: formular bem a instrução, dar alguns exemplos, talvez acrescentar algum texto recuperado, pronto. Esse conjunto de habilidades ainda importa. Mas ele já não cobre o que significa "construir um agente" em meados de 2026, e essa lacuna vem aparecendo como um modo de falha específico e reconhecível: agentes que funcionam muito bem numa demonstração e depois se degradam silenciosamente, se contradizem, ou esquecem o que o usuário lhes disse duas sessões atrás.
Um artigo recente do Machine Learning Mastery nomeia essa lacuna diretamente, e vale a pena parar para pensar nisso, porque ela se encaixa perfeitamente em dois trabalhos diferentes para os quais você poderia, de fato, ser contratado. Engenharia de contexto é o que acontece dentro de uma única chamada de inferência: decidir o que entra na janela de contexto, onde entra estruturalmente, e o que é comprimido ou descartado para que o modelo não se afogue em tokens irrelevantes. Engenharia de memória é um problema diferente que só existe entre chamadas: o que é registrado depois que uma sessão termina, onde é armazenado, como é recuperado da próxima vez, e como é mantido (atualizado, deduplicado, expirado) para que não apodreça. Segundo esse artigo, as falhas que aparecem em fluxos de trabalho de agentes longos e multissessão quase sempre remontam a confundir esses dois trabalhos, ou pular um deles — especialmente no que eles chamam de "fronteira de recuperação", o momento em que um agente precisa decidir se algo de que precisa já está diante dele ou precisa ser buscado no armazenamento.
Por que confundi-los é o verdadeiro problema, não um detalhe
Pense no que cada disciplina está otimizando. A engenharia de contexto otimiza uma janela única, limitada e descartável — colocar a fatia certa de informação diante do modelo agora, para esta única troca, e depois jogar o resto fora. A engenharia de memória otimiza um repositório durável que precisa sobreviver entre sessões, permanecer consistente à medida que chegam novas informações, e responder a uma pergunta muito mais difícil: não "o que é relevante para este prompt", mas "o que vale a pena guardar, e por quanto tempo".
Esses são problemas de design diferentes, com modos de falha diferentes. Um erro de engenharia de contexto piora uma resposta. Um erro de engenharia de memória se acumula — escritas ruins se acumulam, fatos desatualizados são recuperados como se fossem atuais, e ninguém percebe até que o agente repita com confiança algo que foi corrigido três sessões atrás. Se uma pessoa (ou um modelo de prompt) está fazendo silenciosamente os dois trabalhos sem distingui-los, a camada de memória tende a herdar hábitos de engenharia de contexto que não deveria: encher demais o armazenamento da mesma forma que se encheria demais uma janela, ou tratar a recuperação como um problema de ranqueamento de relevância quando na verdade é um problema de curadoria e manutenção. É essa confusão que o resumo de pesquisa aponta, e ela se alinha com algo que os praticantes já descrevem anedoticamente: agentes que impressionam numa única sessão e se tornam pouco confiáveis por volta da quinta sessão.
Como cada trabalho realmente é no dia a dia
Se você está tentando descobrir qual desses dois já faz, ou qual gostaria de construir, o trabalho do dia a dia é diferente o suficiente para se distinguir:
Engenharia de contexto, na prática: decidir qual subconjunto de informações disponíveis (documentos, saídas de ferramentas, turnos anteriores) realmente pertence a esta chamada; escolher onde no prompt isso entra, já que a posição afeta como os modelos o ponderam; escrever etapas de compressão ou resumo para que um rastro longo de ferramenta não consuma todo o orçamento; e ajustar isso por tarefa, já que um agente de depuração e um agente de escrita querem formatos de contexto diferentes mesmo no mesmo modelo subjacente.
Engenharia de memória, na prática: definir uma política de escrita (o que vale a pena persistir depois de uma sessão — nem tudo vale); escolher uma camada de armazenamento (um banco de dados vetorial, um banco de dados estruturado, arquivos simples, algum híbrido) e ser honesto sobre as vantagens e desvantagens de cada um; construir a estratégia de recuperação que decide o que volta e quando; e fazer manutenção contínua — podar, mesclar fatos duplicados, lidar com contradições quando o usuário muda de ideia. Essa última parte, a manutenção, é a que mais frequentemente as pessoas pulam, porque não fica visível até que um agente esteja rodando há semanas.
Dá para ver a indústria começando a separar essas preocupações estruturalmente, não apenas conceitualmente. O passo a passo da Lenny's Newsletter sobre a construção de um harness de depuração no Claude Agent SDK trata permissões, adaptadores de ferramentas e o "harness" ao redor como uma superfície de engenharia própria, distinta da criação de prompts que acontece dentro dele — o mesmo instinto, aplicado a uma costura diferente. E os novos recursos "Managed Agents" da API Gemini do Google — execução em segundo plano, renovação de credenciais entre interações — são, na prática, o fornecedor da plataforma admitindo que o estado persistente entre sessões agora é infraestrutura que precisa ser projetada, não um efeito colateral de uma janela de contexto suficientemente longa. Alguém precisa assumir esse design. Agora mesmo, em muitas equipes, ninguém explicitamente o faz.
Por que isso importa para o seu cargo, não só para o seu código
Se você está no início ou no meio da carreira e "prompt engineer" ou "AI engineer" está no seu currículo, vale a pena perguntar a qual desses dois trabalhos você consegue realmente apontar evidências de ter feito — porque os cargos generalistas de agente de IA estão começando a se fragmentar em outros mais específicos, da mesma forma que "webmaster" acabou se dividindo em frontend, backend e DevOps. Isso é uma ressalva, não uma manchete: ainda não vi dados concretos de contratação confirmando "memory engineer" como um cargo autônomo, então trate isso como uma leitura de para onde o trabalho está indo, não uma afirmação de que os quadros de vagas já estão organizados dessa forma. Mas a pressão subjacente é real e rastreável até o resumo acima: equipes de agentes estão esbarrando numa falha específica e nomeável (degradação multissessão) que tem uma causa específica e nomeável (confundir duas disciplinas), e essa combinação costuma ser o que transforma um cargo nebuloso em dois bem definidos.
A atitude prática não é inventar um cargo para si mesmo. É conseguir responder, concretamente, qual problema você já resolveu de fato. Você já entregou algo em que projetou uma política de escrita — uma regra para o que um agente registra na memória e o que descarta? Você já depurou uma falha na fronteira de recuperação, em que um agente precisava de algo do armazenamento e ou não o buscou ou buscou a versão errada? Essas são afirmações verificáveis que você pode fazer numa entrevista, respaldadas por um repositório ou um post-mortem, e elas dizem algo que um genérico "eu escrevo bons prompts" não diz: que você entende a diferença entre melhorar uma resposta e tornar um agente confiável ao longo do tempo.
Uma ressalva
Não se autodenomine "memory engineer" só porque uma vez adicionou um banco de dados vetorial a um projeto. A disciplina que a pesquisa aponta inclui a metade nada glamorosa — manutenção, expiração, tratamento de contradições — e é essa metade que realmente evita o modo de falha descrito acima. Se o seu projeto de portfólio é um sistema que escreve na memória, mas nada nunca é podado ou corrigido, você construiu metade do trabalho de um engenheiro de memória, e o problema de falhar depois da terceira sessão ainda o espera na outra metade.