Prompt engineering não morreu. Subiu uma camada.

*O que realmente substitui o prompt por turno em sistemas agênticos — e para onde vai o risco quando ninguém mais revisa a redação.*

Resumo executivo

O vocabulário da IA agêntica — definição de objetivos, guardrails, orquestração de ferramentas — descreve uma mudança real, mas "prompt engineering vai acabar" é a manchete errada. O prompt deixa de ser algo que um usuário escreve a cada sessão e passa a ser algo que um arquiteto escreve uma vez, no deploy, e governa como um documento de política. Essa mudança de lugar muda também quem é dono do risco: em vez de um e-mail ruim causado pela redação de um analista de marketing, uma goal spec mal configurada ou um guardrail incompleto pode disparar cem ações autônomas antes que alguém perceba. Orce essa governança agora, não depois do primeiro incidente.

O vocabulário está certo; a história que ele conta está deslocada em uma camada

Uma matéria recente da Gadget Review listou nove termos — IA agêntica, agentes de IA, definição de objetivos, guardrails, valores e alinhamento, integração de ferramentas e o ciclo "perceber-raciocinar-agir-aprender" — como conceitos que substituem o prompt engineering. Os termos estão corretos. A afirmação de que o prompt simplesmente desaparece, não — e errar nisso é exatamente o que um arquiteto não pode se permitir.

O prompt tradicional é um contrato requisição-resposta: um humano escreve texto, um modelo devolve texto, e o humano é a única coisa que impede que um pedido ruim vire um resultado ruim. A promessa da IA agêntica é que o sistema assume o ciclo inteiro — perceber o que mudou, decidir o que fazer e executar — sem alguém redigitar instruções a cada passo.

Verdade no nível da conversa; falso no nível do sistema. Alguém continua especificando o que é "pronto", o que o agente pode tocar e o que conta como violação que justifica parar — isso só acontece uma vez, em uma configuração, em vez de toda vez que alguém abre uma janela de chat.

A goal spec é um prompt com outro público

Um objetivo como "aumentar reconhecimento de marca com R$ 250 mil de orçamento" não se executa sozinho. Ele precisa virar um objetivo estruturado — critérios de sucesso, horizonte de tempo, teto orçamentário — que um orquestrador consiga decompor em um grafo de tarefas e rotear para as ferramentas certas. Escrever bem essa tradução é prompt engineering; só que direcionado a um planejador em vez de uma pessoa, e revisado em cadência de release em vez de por mensagem.

A consequência prática é uma mudança real em onde o esforço de revisão se concentra. Uma área de marketing que passava cada peça por jurídico e brand agora passa muito menos artefatos por esse portão — mas cada um autoriza muito mais ação a jusante. De forma ilustrativa: quarenta prompts de campanha revisados por trimestre viram quatro goal specs por trimestre, e cada uma dessas quatro controla o que antes exigia quarenta aprovações humanas separadas. Menos ciclos de revisão, mais em jogo por ciclo — uma troca que só compensa se os quatro documentos forem revisados com o mesmo rigor que os quarenta recebiam.

Guardrails são aplicados por ação, não por conversa

Este é o mecanismo que a maior parte da cobertura de negócios sobre "guardrails" ignora: um guardrail que merece o nome não é uma frase no system prompt pedindo bom comportamento. É um *policy engine* entre a decisão do agente e a chamada de ferramenta que a executa, verificando a ação proposta contra uma allow-list, um teto de gasto ou uma regra regulatória antes de a chamada de API disparar. Pense em um agente de aprovação de descontos: uma regra contra conceder mais de 15% sem alçada não significa nada como frase nas instruções do modelo, porque uma conversa suficientemente incomum convence o modelo a passar por cima. A mesma regra aplicada no ponto em que a API de pagamento rejeita qualquer cupom acima do teto é um controle, não uma sugestão — e é auditável, porque cada liberação e cada bloqueio deixam registro, independentemente do que o modelo "quis dizer".

Essa distinção decide todo o raio de impacto. Um prompt mal redigido a um chatbot produz uma saída ruim que um humano ainda precisa executar. Uma goal spec com lacuna nos guardrails pode autorizar um laço de ações antes que qualquer humano veja alguma delas. Se um erro de precificação custa uma transação ou mil depende inteiramente de qual camada segura a restrição — a redação, ou o policy engine que checa cada chamada que a redação produz.

O passo "aprender" faz mais trabalho retórico do que técnico

O ciclo perceber-raciocinar-agir-aprender toma emprestado um padrão real — a arquitetura ReAct, de Yao et al., intercala traços de raciocínio com ações para que o modelo revise o plano no meio da tarefa a partir do que observa. Isso é legítimo, e é por isso que agentes se recuperam de uma chamada de API falha em vez de simplesmente parar. Mas "aprender", na maioria dos sistemas em produção hoje, não significa que o modelo atualiza os próprios pesos. Significa que um harness de avaliação registra resultados, um humano ou uma rotina agendada os compara com uma métrica-alvo, e alguém edita a goal spec, o conjunto de ferramentas ou os limiares dos guardrails. A ambiguidade importa: "um agente que aprende" soa como algo que dispensa modelo operacional, enquanto uma configuração de política revisada a cada duas semanas exige exatamente um. Orce o segundo, não o mito do primeiro.

Figura 1. *A goal spec e o policy engine são os dois lugares onde o esforço de escrita de prompt realmente aterrissa em um agente de produção — tudo depois do portão de política é código, não conversa.*

Caso de uso real: reposição em uma rede regional de supermercados

O desafio

Imagine uma rede regional com 180 lojas (escala ilustrativa) em que compradores de categoria conduziam a reposição semanal de laticínios e hortifrúti por planilha e um assistente de chat reinstruído SKU a SKU: "repõe leite de aveia para o caminhão de terça, sem estourar o orçamento, não pede demais como no mês passado". Cada nuance da restrição vivia na redação daquele dia. Um comprador doente, um prompt apressado antes do feriado ou um novato sem familiaridade com a lista de fornecedores produziam sempre as mesmas duas falhas: ruptura nos SKUs de giro rápido e desperdício em perecíveis pedidos acima do que a loja conseguia vender.

A abordagem

Substituir o prompt por categoria por uma goal spec permanente — "manter 98% de disponibilidade em gôndola para laticínios mantendo a perda por vencimento abaixo de 4% da receita da categoria" (meta ilustrativa) — tira a restrição da redação diária e a coloca em um documento revisado mensalmente pelo diretor de categoria. Um orquestrador traduz esse objetivo em propostas de reposição loja a loja; um policy engine confere cada pedido proposto contra o teto orçamentário e a lista de fornecedores homologados antes de chegar à API de pedidos do ERP. O que exceder o limiar por pedido — um pico vindo de previsão promocional, por exemplo — não dispara em silêncio. Para, e espera a confirmação de um comprador humano.

Figura 2. *O caminho de falha que importa não é o modelo estar errado — é uma proposta tecnicamente válida mas fora da política, e a resposta do sistema é escalar com fallback por timeout, não executar em silêncio.*

O resultado

Não existe dado de resultado auditado para este cenário — é uma ilustração composta, não um caso de cliente. Direcionalmente, redes que saem da reposição ad hoc para automação limitada por política relatam menos rupturas e menos baixas por perda, porque a restrição que dependia de um comprador lembrar passa a rodar em todo pedido. A afirmação honesta não é um percentual; é que o modo de falha muda de "alguém esqueceu uma restrição" para "a restrição foi mal calibrada e ninguém revisou no prazo" — um problema de governança, não de memória.

Estratégia de implantação

1. 1.Escreva a goal spec primeiro. *(dono: líder de categoria/produto · ~2 semanas)* — Métrica de sucesso, teto orçamentário e condições explícitas de "pare e pergunte", em linguagem simples, antes de qualquer integração de ferramenta. Não consegue enunciar as condições de parada? Não está pronto para dar acesso a ferramentas.
2. 2.Construa o policy engine antes de o orquestrador ganhar acesso real às ferramentas. *(dono: engenharia de plataforma/segurança · ~3–4 semanas)* — Toda chamada de ferramenta passa por uma checagem capaz de dizer não independentemente da confiança do modelo. Registre cada liberação e cada bloqueio.
3. 3.Rode em shadow mode antes de conceder escrita. *(dono: engenharia de dados/ML · ~2–3 semanas)* — O agente propõe ações; um humano executa manualmente. É aqui que se descobre se a goal spec captura o que os prompts antigos carregavam informalmente.
4. 4.Defina a cadência de revisão antes de chamar qualquer coisa de "aprendizado". *(dono: quem responde pela métrica do passo 1)* — Decida quem revisa o painel de avaliação e com que frequência a goal spec, os guardrails ou o conjunto de ferramentas são revisados. Esse é o passo "aprender" — um compromisso na agenda, não uma capacidade do modelo.

Onde mora o risco: a falha mais comum não é um agente rebelde — é um policy engine com uma lacuna que ninguém notou porque a goal spec nunca enumerou o caso de borda. Uma lista de guardrails escrita uma vez no lançamento e nunca revisitada degrada como uma regra de firewall sem patch: silenciosamente, até a única vez em que importa.

A proposta de valor

Do lado do tempo: levar mudanças de restrição a uma revisão mensal de política, em vez de reinstruir todo dia, libera a equipe de categoria para tratamento de exceções e negociação com fornecedores — o trabalho de julgamento que um policy engine não faz. Do lado do risco: limitar cada chamada de ferramenta na camada de política, em vez de confiar na redação, restringe a exposição de uma decisão ruim a uma ação registrada, em vez de uma sequência sem limite que ninguém revisou até a nota fiscal chegar. O custo honesto: isso exige investimento permanente em policy engine, harness de avaliação e um revisor nomeado — governança que algumas organizações obtinham de graça porque havia um humano no loop de cada saída.

Chamada para ação

Antes de adotar um framework de agentes, escreva a goal spec e a lista de "pare e pergunte" — trate as duas com o mesmo rigor de revisão de um contrato de API em produção.

A escolha do framework é a decisão fácil. A difícil é o que você aceita deixar um agente decidir sem supervisão, e essa resposta pertence a um documento que alguém assina, não à redação que pareceu razoável às 16h de uma sexta-feira.

Fontes e notas

• Fonte original: 9 Agentic AI Terms That Replace Prompt Engineering, Gadget Review, 4 de agosto de 2026.
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023 — o padrão de raciocínio e ação intercalados por trás da maioria dos laços "perceber-raciocinar-agir".
• Contexto sobre a distinção arquitetural entre workflow e agente: Anthropic, Building Effective Agents.
• *Todos os números do caso de reposição (quantidade de lojas, meta de disponibilidade, limite de perda, cadência de revisão, valores) são composições ilustrativas, não resultado reportado de cliente.*
• As figuras são diagramas originais deste artigo.