Seu agente é um grafo com nome bonito

Quem decide o próximo passo: você ou o modelo?

Existe uma confusão de vocabulário que custa caro na arquitetura de sistemas com LLM. Chamamos de “agente” qualquer coisa que tenha um modelo dentro e, com isso, perdemos a única distinção que muda o projeto do sistema de verdade: como ele é testado, quanto custa e o que dá pra prometer sobre o comportamento dele.

Chain, grafo e agente não são três tecnologias diferentes. São três respostas para uma única pergunta:

Quem decide qual é o próximo passo: você ou o modelo?

Todo o resto (tools, MCP, RAG, memória) é andaime. A pergunta acima é a fundação.

Pra não argumentar no abstrato, o texto inteiro roda em cima de um problema só: um revisor automatizado de pull request. Ele recebe um diff, procura bugs, riscos de segurança e problemas de design, e comenta no PR. É um problema chato o bastante pra ter chain, ambíguo o bastante pra pedir grafo, e aberto o bastante pra tentar agente. As três arquiteturas dão conta dele. De formas muito diferentes.

O ponto de partida: o LLM é uma função não confiável

Um LLM faz uma coisa só: recebe uma sequência de tokens e devolve o próximo token, probabilisticamente. Uma função pura, sem memória, sem estado, sem garantia de repetibilidade. Não há inteligência de sistema ali dentro. Há uma função útil e não confiável.

Engenharia de LLM é, essencialmente, a arte de decidir onde colocar as restrições em volta dessa função. Chain, grafo e agente são três posições nesse eixo, da restrição máxima à autonomia máxima.

Chain: a ordem é sua, e é linear

Uma chain é uma sequência fixa. O passo 1 alimenta o passo 2, que alimenta o passo 3. Você escreveu a ordem no código, e ela não muda em tempo de execução.

extrai diff → monta prompt → chama LLM → valida schema → posta comentário

O modelo é chamado como uma função no meio de um pipeline comum. Ele não escolhe nada além do conteúdo do texto que devolve. Mesmo input, mesmo caminho de execução. Sempre.

Isso é entediante, e entediante é ótimo. Chain é barato, previsível, trivial de testar e de instrumentar. O problema é que a realidade raramente é linear.

Grafo: a ordem ainda é sua, mas pode ramificar

O grafo é a evolução natural. Você tem nós e arestas, e as arestas podem ser condicionais: dependendo do estado, o fluxo vai por um caminho ou por outro. Um PR que só toca .md não precisa passar pelo especialista de segurança. Um achado de severidade alta dispara um nó de revisão extra.

A tentação é chamar isso de agente, porque “o sistema decide”. E aqui a confusão fica legítima, porque o estado que alimenta a aresta pode vir do próprio modelo:

def route(state):
    # state.severity foi classificado pelo LLM no nó anterior
    if state.severity == "high":
        return "deep_review"
    return "judge"

O modelo influenciou o roteamento. Ele não escolheu o roteamento. A diferença cabe em uma frase: o modelo produziu um valor, e você escreveu o que fazer com cada valor possível. Ele não tinha como devolver "chama o time de plantão", porque esse destino não existe no seu código. O espaço de caminhos foi inteiramente enumerado por você, em tempo de escrita.

Essa condicional é sua. Está no seu código, é auditável, é testável com um teste unitário comum. O grafo é dinâmico em tempo de execução, mas dado o mesmo estado, o mesmo roteamento acontece. Sempre.

Repare no judge do snippet: ele é o nó que recebe achados e consolida. Agora amplie o desenho. Em vez de um caminho chegando nele, coloque cinco especialistas rodando em paralelo, cada um com seu prompt, todos convergindo ali. Você acabou de desenhar o diagrama que hoje se vende como “sistema multi-agente”.

Só que cada um desses especialistas recebe um diff e devolve achados. Entra input, sai output, e ele não escolhe nada além do texto que produz. É a mesma criatura da seção anterior: o modelo chamado como função no meio de um pipeline. Um nó de grafo com um prompt especializado e um nome bonito.

Um sistema multi-agente pode não ter um único agente dentro. O plural está no diagrama, não na arquitetura.

Isso não é demérito. É provavelmente a decisão certa. Mas é uma decisão, e vale ser honesto sobre ela.

Agente: o modelo decide

O agente inverte a autoridade. Você dá ao modelo um objetivo, um conjunto de tools e um contexto. Não a ordem de execução. O modelo entra em um loop:

modelo → escolhe uma tool → você executa → resultado volta pro contexto →
modelo reavalia → escolhe outra tool ou decide que terminou

O critério de parada também é dele. Essa é a diferença ontológica, não uma questão de grau de sofisticação.

Um exemplo concreto do que isso muda. Suponha um PR que remove a feature flag ENABLE_LEGACY_CHECKOUT e apaga o branch morto. O diff é limpo, coeso, e os testes passam.

Um grafo fixo roda os especialistas nele. Nenhum problema de segurança, nenhum bug óbvio, cobertura mantida. Devolve “nenhum achado”. Correto dentro do escopo que você definiu.

Um agente faz uma pergunta que não estava na tarefa: quem mais lê essa flag? Ele faz um grep no código e não acha nada. Poderia parar aqui, e um nó de grafo pararia. Mas flags são lidas por nome, como string, e nem sempre pelo código. Ele busca a string crua no repositório inteiro e encontra helm/values.yaml. Lê o arquivo: a flag está true em staging. Isso levanta uma pergunta que não existia trinta segundos atrás. Ele abre o pipeline de deploy pra entender o que acontece quando o serviço sobe com uma flag que ninguém mais consome, descobre que o parser de config rejeita chaves desconhecidas, e posta um achado que não estava no diff, não estava no código, e não estava no escopo.

Repare no mecanismo, não no resultado. Cada resposta gerou a pergunta seguinte. O agente não executou uma checagem de “consistência de flag”: ele executou uma investigação cuja profundidade e cujo formato dependiam do que cada passo devolvia.

“Mas bastava um nó check_flag_removal no grafo.” Bastava, pro primeiro nível. O terceiro nível não existe até o segundo devolver aquele valor específico. Você não pode desenhar uma aresta pra um estado que só passa a existir depois que o modelo leu um YAML que você não sabia que estava lá. Grafo enumera caminhos. Agente gera o caminho enquanto anda nele.

Isso é agenticidade: raciocinar além da tarefa imediata, usar tools pra reduzir a própria incerteza e revisar a conclusão à luz do que descobriu.

Não é binário, é um espectro

Três perguntas localizam qualquer sistema nesse eixo, e elas não têm o mesmo peso.

A primeira é definitiva: o modelo escolhe a sequência de passos? Se não, você tem um grafo, e o assunto acaba aí, por mais tools e prompts sofisticados que existam dentro dos nós.

A segunda é a que mais confunde, porque a resposta pode ser sim num sistema que não tem nada de agêntico. O modelo escolhe quais tools chamar? Um nó de grafo pode ter tools. O especialista de segurança pode buscar o histórico de um arquivo antes de opinar. Ter tool não é ter autonomia. Autonomia é escolher a ordem.

A terceira é a que decide: existe um loop cujo critério de parada é do modelo? É aqui que a categoria vira. Repare que ela absorve a pergunta que quase todo mundo faz separado, sobre reflexão. Um sistema que gera, critica e revisa em três nós fixos tem reflexão e nenhuma autonomia: você mandou refletir. O que é agêntico não é refletir, é o modelo decidir que ainda não terminou.

Daí que a arquitetura mais comum na prática não é chain, nem grafo, nem agente. É um grafo fixo no macro com nós agênticos no micro. Espinha dorsal determinística, autonomia concedida em pontos específicos. A pergunta que sobra é quais pontos.

Mas isso não é só modelo + harness?

Toda vez que essa distinção aparece, alguém devolve a mesma objeção: no fim, agente é só modelo + harness. É uma objeção justa, e vale levá-la a sério. Um agente de fato precisa de um harness: o loop, o despacho de ferramentas, a gestão de contexto, a memória, o critério de parada. O ponto é que um grafo também tem tudo isso. Se “modelo + harness” bastasse pra definir agente, uma chain de três passos com validação de schema entraria na mesma categoria, e a gente sente que não deveria.

O que reposiciona a objeção está na própria definição de harness. Nas descrições que praticantes usam, por exemplo o glossário de agentes da Hugging Face (2026), o control flow e a condição de parada aparecem como componentes do harness: retries, limites de passo, quando ramificar, quando desistir. Ou seja, o fluxo de controle é um item dentro do harness, não algo acima dele. E esse item pode ser escrito por você ou delegado ao modelo. A diferença mora aí, dentro do harness, e não na presença dele.

A distinção canônica diz a mesma coisa. Segundo a Anthropic, em “Building Effective Agents” (2024), workflows são sistemas em que LLMs e ferramentas são orquestrados por caminhos de código predefinidos, enquanto agentes são sistemas em que o modelo dirige o próprio processo e decide como usar as ferramentas. Barry Zhang, na palestra “How We Build Effective Agents” (2025), fecha em uma imagem: no workflow, o encanamento é seu; no agente, o encanamento é do modelo. Todo mundo tem encanamento. Nem todo mundo entrega o volante.

E o loop que caracteriza o agente não é um loop qualquer. Yao et al., em “ReAct: Synergizing Reasoning and Acting in Language Models” (2023), formalizaram a execução como um ciclo de pensamento, ação e observação em que o modelo interpreta o estado, decide a próxima ação e alimenta o passo seguinte com o resultado. O que faz disso um agente não é o ciclo existir. É o modelo ser dono de quando ele para.

O preço da autonomia

Cada grama de autonomia custa uma coisa óbvia e uma que quase ninguém menciona.

A óbvia chega em três faturas com nomes diferentes: dinheiro, latência e imprevisibilidade. Mas é uma só: você perde a capacidade de saber, antes de rodar, o que vai acontecer. O custo de uma chain você calcula na planilha antes de subir, e o tempo dela também. O de um agente, não. O loop roda até o modelo achar que terminou, e quantas vezes ele vai chamar a si mesmo é uma propriedade do input, não do seu código. Você não está comprando um sistema mais caro. Está comprando um sistema cujo custo você só descobre depois.

A que ninguém menciona: autonomia destrói sua capacidade de medir. Se você tem um golden dataset e quer saber se a mudança no prompt do especialista de segurança melhorou o recall, precisa que o resto do sistema fique parado. Se o caminho de execução varia sozinho entre as rodadas, você não consegue atribuir a variação de qualidade ao prompt em vez do roteamento. Você perde o experimento controlado e, com ele, a engenharia.

Então quando a autonomia vale a pena?

Todo o resto do texto foi descrição. Aqui está o único critério que eu levaria pra uma decisão de arquitetura:

Autonomia paga quando existe um verificador barato e objetivo que fecha o loop.

Um agente que implementa uma correção opera num mundo onde compilador, testes e linter dizem, de graça e sem ambiguidade, se ele acertou. Ele pode errar, receber o erro de volta e tentar de novo. O loop tem um sinal de realidade em cada iteração, e por isso a exploração converge.

Um agente que revisa código não tem isso. Não existe compilador de “essa observação é útil”. A única verificação é humana, cara e lenta. Sem verificador, o loop não converge: ele só queima tokens gerando variações não avaliadas.

E aqui a conta fica desconfortável, então é melhor fazer a conta na sua frente. O achado do values.yaml era real. O grafo teria perdido esse achado. Isso não é retórica pra vender o próximo parágrafo: é uma perda concreta, e escolher o grafo significa aceitar essa perda.

Você aceita mesmo assim porque a mesma autonomia que produziu aquele achado produz, na rodada seguinte, um agente que abriu quatro arquivos irrelevantes e postou uma preocupação confiante e errada sobre um deles. As duas rodadas custam parecido, demoram parecido e chegam com a mesma cara de segurança. Sem verificador, a única coisa capaz de separar uma da outra é um humano lendo as duas, que é exatamente o trabalho que você estava tentando automatizar.

Não é que o agente revisor seja ruim. É que ele é bom e ruim de formas que você não consegue distinguir em escala. Um sistema cujo valor você não consegue medir não é um sistema, é uma aposta.

Daí sai uma arquitetura híbrida que se defende sozinha: grafo determinístico para a revisão, agente para a implementação da correção. Não porque um é moderno e o outro é legado, mas porque a natureza do feedback disponível é diferente nos dois lados.

O resumo que vale gravar

Determinismo onde der, autonomia só onde for necessário.

Na hora de descrever o próprio sistema, um pouco de precisão vocabular rende mais do que hype. “Orquestração multi-etapa com LLM” ou “workflow agêntico” descreve um grafo fixo com honestidade. Reserve “agente autônomo” para quando o modelo realmente decide o próprio caminho.

Quem entende essa diferença e sabe justificá-la demonstra três coisas de uma vez: domínio do trade-off, disciplina de avaliação e consciência de custo. Quem chama tudo de agente demonstra que leu o anúncio.

Referências

Anthropic. “Building Effective Agents.” 2024. anthropic.com/engineering/building-effective-agents
Zhang, Barry. “How We Build Effective Agents.” AI Engineer Summit, 2025.
Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., Cao, Y. “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023. arXiv:2210.03629.
Hugging Face. “Agent Glossary.” 2026. / Masood, A. “Agent Harness Engineering: The Rise of the AI Control Plane.” 2026.