⚖️ Agentic × Loop × Graph

A camada que todo mundo conhece: a instrucao que voce escreve pro modelo. E onde a maioria comeca — e onde a maioria empaca.

Porque quase todo problema de "a IA nao fez o que eu queria" e resolvido tentando melhorar o prompt, mesmo quando o defeito esta numa camada mais acima.

Prompt e a camada mais barata de mudar e a mais limitada. Sozinha, nunca resolve o que exige memoria, ferramentas ou repeticao.

Arquivos, historico, documentacao — tudo que entra na janela de contexto antes do modelo decidir o proximo passo.

Contexto errado produz decisao errada mesmo com prompt perfeito. E contexto demais entope a janela e degrada a atencao do modelo.

Janela de contexto e um recurso finito. O que entope ela — logs brutos, rascunhos velhos, raciocinio antigo — e o inimigo silencioso desta camada.

A infraestrutura em volta do modelo: ferramentas disponiveis, permissoes, captura de saida, retentativa, orcamento de token.

O harness define o teto de capacidade do agente. Um modelo brilhante sem ferramenta certa nao executa nada — so descreve o que faria.

Harness e a fronteira entre "o modelo pensou" e "o modelo agiu". E onde permissao, seguranca e custo entram na conta.

Quantas vezes o agente tenta e como sabe que terminou. E a Trilha 2 inteira, resumida numa frase.

Sem loop, cada tentativa e isolada — nao ha correcao. Com loop, o sistema pode errar, medir e tentar de novo.

O loop precisa de um verificador e de uma condicao de parada. Sem os dois, nao e loop — e repeticao cega.

Um conjunto de loops conectados por arestas explicitas — a camada que so faz sentido depois de dominar as quatro anteriores.

Subir pro grafo sem um loop solido embaixo so multiplica o problema: agora voce tem varios loops ruins conversando entre si.

Grafo nao substitui as camadas de baixo — ele as organiza. Cada no do grafo ainda precisa de prompt, contexto, harness e loop proprios.

O harness de loop cabe num script: entrada, contexto, orcamento, retry, saida. O de grafo se parece mais com um runtime distribuido: roteamento de mensagem entre nos, isolamento de falha de um no, consistencia de estado, criacao dinamica de no, observabilidade de quem rodou, quando e com qual latencia.

E por isso que frameworks ganham tracao quando a conversa vai de loop pra grafo — o problema de infraestrutura muda de categoria, nao so de tamanho.

Nao e "mais loop": e um problema de sistema distribuido. Falha parcial, estado compartilhado e observabilidade viram obrigatorios, nao opcionais.

Voce descreve o objetivo, da ferramentas, e o modelo decide o que fazer. Sem ciclo desenhado nem teste de saida explicito.

E o ponto de partida mais comum e o mais rapido de montar — e tambem o mais dificil de prever ou depurar quando da errado.

Julgamento do modelo substitui estrutura desenhada por voce. Funciona bem em tarefa curta; degrada em tarefa longa ou repetida.

Voce para de escrever prompt e passa a projetar o ciclo e a condicao de parada — descobrir, planejar, agir, verificar, parar.

E o salto de qualidade mais barato que existe: o mesmo modelo, com um ciclo desenhado, erra menos e converge mais rapido.

O verificador vira o teto de qualidade — tema inteiro da Trilha 2. Aqui ele so reaparece como peca do comparativo.

Varios nos, cada um um loop, com o caminho entre eles escrito antes de rodar — nao inferido pelo modelo em tempo real.

E o unico dos tres formatos que permite paralelismo real e contextos separados por papel. E tambem o mais caro de manter.

Aresta explicita e a diferenca central: o fluxo de controle vira algo que voce le num diagrama, nao algo que voce reconstroi de um transcript.

Como loop unico, um agente faz tudo numa janela so, le as fontes uma a uma e revisa o proprio texto no mesmo contexto (carimba). Como grafo: pesquisador (abre em N fontes em paralelo) → escritor (so as notas, contexto limpo) → revisor (contexto novo, ve so o texto e o criterio, e tem aresta de volta "reprovado").

Ver o mesmo caso nos tres formatos e o unico jeito de comparar sem retorica — os numeros e as falhas ficam visiveis lado a lado.

Fan-out (pesquisador em paralelo) e contexto limpo por papel (escritor so ve notas, revisor so ve texto e criterio) sao as duas diferencas que realmente importam.

Nos paralelos especializados com contextos limpos e separados; fan-out e fan-in como movimento de primeira classe; fluxo de controle legivel como diagrama em vez de reconstruido de um transcript.

Sao os tres ganhos que um loop, por mais bem escrito, nao consegue reproduzir — porque loop e sequencial por definicao.

Nenhum desses ganhos e retorica: cada um resolve uma falha estrutural especifica do loop unico vista na Trilha 2.

Tres prompts pra manter em vez de um; um state schema entre nos (o que exatamente o pesquisador entrega pro escritor?); e modos de falha novos — merge que engole uma fonte, roteamento que fica indo e voltando, estado que vaza de um no pro outro.

Pra tarefa que roda todo dia, compensa; pra tarefa que roda uma vez, e imposto puro. Saber isso evita adotar grafo por moda.

O caso degenerado: um grafo de UM no com todas as ferramentas e loop reinventado — a estrutura nao esta fazendo nada.

Loop nao morreu: virou o no do grafo. Voce nao gradua de loop pra grafo, voce compoe loops em grafos quando um loop deixa de bastar.

Esse mito faz gente descartar loop antes de dominar — e loop mal dominado embaixo garante grafo ruim em cima.

Composicao, nao substituicao. Todo no de grafo, quando aberto, e um loop com seu proprio verificador e condicao de parada.

Um e grafo de INFORMACAO que o agente consulta; o outro e grafo de EXECUCAO, quem roda em que ordem. O mercado mistura os dois o tempo todo.

Confundir os dois faz voce comprar a ferramenta errada pro problema que tem — GraphRAG nao orquestra agente, e o contrario tambem.

Grafo de conhecimento responde "o que sei". Grafo de execucao responde "quem faz o que, em que ordem". Sao dois grafos diferentes com o mesmo nome de marketing.

DSPy otimiza programas de modelo de linguagem — prompts e parametros — nao grafos de conhecimento. E uma atribuicao errada comum na discussao sobre graph engineering.

Repetir a atribuicao errada faz voce buscar DSPy pra um problema que ele nao resolve, e ignorar as ferramentas que resolveriam.

DSPy = otimizacao de programa. Nao confundir com armazenamento ou consulta de grafo — sao categorias diferentes de ferramenta.

Anthropic nao anunciou disciplina nenhuma chamada graph engineering — usa orquestracao escrita em codigo, o que e diferente de lancar uma metodologia com esse nome.

Citar "a Anthropic lancou graph engineering" como fonte de autoridade e um erro factual especifico que circula bastante — bom saber apontar.

Orquestrar agentes com codigo (grafos, filas, roteamento) e uma pratica de engenharia antiga. O rotulo "graph engineering" e recente; a pratica nao e.

Vieram de um estudo especifico sobre diagramas industriais, nao de um benchmark geral de agentes. Repetir isso como se valesse pra qualquer sistema e desonesto.

E o exemplo mais claro de numero de marketing viajando sem contexto — util pra reconhecer o padrao em qualquer outro numero solto que aparecer.

Sempre pergunte: benchmark de que tarefa, comparado com que baseline, medido por quem. Sem isso, o numero e so ruido com aparencia de dado.

Maquina de estados, XState, orquestracao em grafo em LangGraph, AutoGen e Google ADK sao anteriores ao termo. O que e novo em 2026 e o VOCABULARIO.

Julgue o padrao, nao o rotulo. E a conclusao pratica: a maioria dos agentes ainda nao precisa de grafo — muita tarefa continua sendo um modelo, um ciclo de ferramentas e uma boa condicao de parada.

Maquina de estados finita e o antepassado direto. Nomear de novo nao torna a ideia nova — mas tambem nao torna a ideia inutil.