Prompt Engineering vs Loop Engineering vs Graph Engineering: o que muda em cada camada

A pirâmide da engenharia de agentes

Três termos disputam espaço nas descrições de vagas de engenharia de IA. Prompt engineering é o veterano. Loop engineering entrou no vocabulário no final de 2025 e dominou a discussão entre desenvolvedores ao longo de junho de 2026. Graph engineering chegou cerca de seis semanas depois. Usados como sinônimos. Deveriam ser?

Os três não são técnicas concorrentes. São três unidades de controle empilhadas. Um prompt controla uma resposta do modelo. Um loop controla o ciclo de comportamento de um agente. Um grafo controla a organização de múltiplos agentes. Cada camada preserva a camada abaixo dela. Um prompt não desaparece quando um loop é construído ao seu redor — ele apenas deixa de ser digitado manualmente.

Este artigo separa os três níveis: o que é projetado em cada camada, quando as camadas superiores se pagam e onde o ceticismo é justificado.

A pilha, em ordem

Cada etapa da progressão recebeu nome na prática antes de aparecer na documentação dos fornecedores.

1. Prompt engineering: escrever e estruturar a instrução para uma única chamada. A orientação da Anthropic é separar o prompt de sistema em seções rotuladas — contexto, instruções, orientação de ferramentas, descrição da saída — delimitadas com tags XML ou cabeçalhos Markdown. Forneça o conjunto mínimo de informações que especifica completamente o comportamento esperado.
2. Context engineering: a progressão natural do prompt engineering segundo a Anthropic. A pergunta muda de “encontrar as palavras certas” para “decidir qual configuração de tokens pertence à janela”. Contexto é um recurso finito, e o problema de engenharia é otimizar a utilidade desses tokens contra as restrições do modelo.
3. Harness engineering: o ambiente onde um único agente opera — arquivos, ferramentas, memória, feedback.
4. Loop engineering: um andar acima do harness. O artigo Buildrix (arXiv, junho/2026) sobre IA agêntica estabelece a mesma progressão de quatro etapas — prompt, contexto, harness, loop — com a camada final definindo como um sistema observa, age, verifica e se recupera repetidamente.
5. Graph engineering: o rótulo mais novo e menos consolidado. A prática subjacente — orquestração baseada em grafos — tem linhagem documentada na pesquisa de sistemas multiagentes.

Camada 1: Prompt Engineering

A premissa definidora é que um humano está presente em cada iteração. Um prompt é escrito, o modelo responde, a saída é avaliada, o prompt é revisado.

Essa premissa é o que quebra. Alto volume. Tarefas com múltiplas etapas. Nenhum humano disponível para avaliar a saída. Resultados que alimentam a próxima etapa automaticamente. Qualquer uma dessas condições, e o prompt sozinho deixa de ser suficiente.

Nada piorou no prompt. As condições ao redor mudaram. O prompt engineering também não desaparece nas camadas superiores — a Anthropic relata que o prompt foi a alavanca principal para corrigir falhas de coordenação em sistemas multiagentes. Versões iniciais geravam 50 subagentes para consultas simples, e a correção veio do prompting, não da topologia.

Camada 2: Loop Engineering

O enquadramento é que um agente de código é uma ferramenta de força bruta para encontrar soluções. A arte está em projetar o objetivo, as ferramentas e o loop — não apenas o prompt.

O termo chegou à discussão mainstream em junho de 2026, após um post amplamente compartilhado argumentar que engenheiros deveriam parar de “promptar” agentes de código e começar a projetar os loops que os “promptam”. A equipe do Claude Code na Anthropic descreveu a mesma mudança naquela semana.

A análise pública mais detalhada identifica cinco primitivos, mais um sexto elemento que os mantém unidos:

1. Automações: um agendamento ou evento que executa descoberta e triagem sem supervisão
2. Worktrees: isolamento para que agentes paralelos não editem os mesmos arquivos
3. Skills: conhecimento do projeto escrito uma vez em um SKILL.md, em vez de reexplicado a cada sessão
4. Plugins e conectores: acesso via MCP ao issue tracker, banco de dados ou API de staging
5. Subagentes: divisão maker/checker, já que o modelo que escreveu o código o avalia com generosidade excessiva
6. Estado: um arquivo markdown ou quadro fora da conversa, porque o modelo esquece entre execuções

Dois recursos em sessão são cruciais. /loop reexecuta em cadência. /goal executa até que uma condição escrita seja verdadeira, com um modelo pequeno separado verificando após cada turno — o agente que escreveu o código não é o agente que o avalia. Tanto o Claude Code quanto o Codex implementam equivalentes.

O ciclo não é a parte difícil. A condição de parada é. Um loop que não consegue distinguir mecanicamente “concluído” de “travado” não falha ruidosamente. Continua gastando tokens.

Camada 3: Graph Engineering

Em julho de 2026, a discussão passou dos loops para os grafos. Loops tornaram o comportamento dos agentes programável. Grafos tornam as organizações de agentes programáveis.

O ponto estrutural mais frequentemente ignorado é que sistemas multiagentes em produção executam dois grafos ao mesmo tempo. O grafo organizacional é estável — agentes de longa duração ocupam papéis nomeados, possuem uma zona e acumulam contexto ao longo do tempo. O grafo de trabalho é efêmero — nós de tarefa existem apenas enquanto o trabalho existe, arestas se dividem para caminhos paralelos e desaparecem quando a evidência torna um ramo desnecessário. O grafo organizacional responde “quem”. O grafo de trabalho responde “o quê, agora”.

LangGraph já tinha uma API de grafos muito antes de o termo existir. Os cinco padrões de fluxo de trabalho da Anthropic de dezembro de 2024 — encadeamento de prompts, roteamento, paralelização, orquestrador-trabalhadores, avaliador-otimizador — são topologias de grafo descritas em prosa. O que é novo é um nome compartilhado para decisões que esses frameworks sempre forçaram: quais são os nós, quais são as arestas, o que está no estado.

Como escolher a camada

Percorra as perguntas em ordem. O primeiro “não” costuma ser a resposta:

• Uma pessoa lê cada saída antes que algo aja sobre ela? Se sim, a camada de prompt é suficiente. Um loop compra execução não supervisionada, não autonomia.
• “Concluído” pode ser verificado por algo além de um humano? Testes, um schema, uma rubrica, um segundo modelo. Se não, não há condição de parada — apenas um orçamento.
• A tarefa cabe no contexto e no domínio de um único agente? Se sim, construa o loop. Um único traço de raciocínio é a forma mais barata de manter premissas consistentes.
• Ramos independentes precisam executar ao mesmo tempo? Se sim, é um problema de grafo: declare os nós, as arestas, o estado compartilhado e as rotas de falha.

O alerta final

Dois engenheiros podem construir um loop idêntico e obter resultados opostos. Um avança mais rápido no trabalho que entende profundamente. O outro evita entender o trabalho. O sistema não consegue distinguir. É isso que torna as camadas superiores mais difíceis de projetar que prompts — não mais fáceis.

Dados publicados estabelecem o preço: +90,2% em um eval interno de pesquisa, mas cerca de 15× os tokens de um chat, com o gasto de tokens sozinho explicando 80% da variância. A maioria das tarefas nunca chega ao topo da pilha.