Agentes em produção - loop ReAct e grafos de controle

Se você está construindo agentes de inteligência artificial baseados apenas na intuição do modelo, você tem uma bomba-relógio em mãos. Deixar um Large Language Model (LLM) totalmente livre para decidir o que fazer no seu ecossistema corporativo é o caminho mais rápido para estourar custos na nuvem ou, pior, quebrar integrações críticas.

Mover o ponteiro da IA aplicada exige trocar o improviso por arquitetura de software. Para criar sistemas autônomos que realmente funcionam em produção, precisamos entender o funcionamento do loop ReAct e como controlá-lo usando grafos de agentes.

O loop ReAct

O padrão ReAct (Reason + Act) é o que transforma um modelo de linguagem estático em um sistema dinâmico. Sem ele, o LLM apenas gera texto linearmente. Com ele, a IA ganha a capacidade de interagir com o mundo real através de um ciclo interativo dividido em três etapas lógicas:

Thought (Pensamento): O agente analisa o objetivo atual e decide o que precisa fazer.
Action (Ação): O agente escolhe uma ferramenta específica (como uma API ou uma consulta ao banco) e define os parâmetros de entrada.
Observation (Observação): O sistema executa a ferramenta, colhe o resultado real e o devolve para o contexto do LLM.

Esse ciclo se repete de forma contínua até que o agente julgue ter a informação necessária para entregar a resposta final.

O desafio do estado

Para sustentar esse loop, o prompt do sistema precisa ser extremamente estrito. Instruímos o LLM a responder em formatos rígidos, geralmente usando JSON ou tags estruturadas (como <thought> e <action>).

O grande problema de produção é a natureza estocástica dos LLMs: se o modelo falhar na formatação de um único caractere do JSON, o seu parser quebra, o loop é interrompido e a experiência do usuário vai por água abaixo.

Orquestração com grafos

Embora o loop ReAct básico funcione bem para tarefas isoladas, ele se torna caótico em fluxos complexos. Para introduzir determinismo e governança, a engenharia de software evoluiu o padrão para grafos de agentes (utilizando ferramentas como o LangGraph).

Em vez de dar liberdade total ao agente, nós modelamos o comportamento do sistema como um grafo estruturado, composto por três elementos:

Nós (Nodes): Representam funções de código isoladas ou chamadas de LLM (ex: um nó para busca, um nó para validação de segurança).
Arestas (Edges): Definem os caminhos possíveis de um nó para o outro, podendo ser condicionais baseadas nas decisões do sistema.
Estado (State): Um objeto centralizado e persistente que armazena o histórico da conversa, variáveis e dados coletados. Cada nó pode ler e modificar esse estado de forma segura.

O fator controle

A grande vantagem dessa abordagem é a capacidade de gerenciar falhas. Se o agente errar ao tentar executar uma tarefa, a máquina de estados intercepta o erro imediatamente. O fluxo é desviado para um nó de recuperação ou transicionado para um suporte humano, impedindo loops infinitos e desperdício de infraestrutura.

Cenário de estresse em produção

Para entender a importância dessa arquitetura combinada (ReAct dentro de um grafo), imagine um caso real: um agente precisa atualizar o endereço de um cliente via API.

Durante o loop ReAct, o LLM alucina e decide inventar um parâmetro inexistente na API, tentando passar o campo cpf onde o endpoint só aceita id_cliente.

Se você confia apenas no loop ReAct puro, a API vai retornar um erro 400 Bad Request, o LLM pode entrar em pânico, tentar a mesma coisa cinco vezes e travar a aplicação.

Com a arquitetura de grafos, o cenário muda:

O nó de execução de API intercepta o erro de validação.
O grafo atualiza o Estado com o log do erro e desvia o fluxo para um nó de “Correção”.
Esse nó específico pode disparar um prompt de contexto curto para o LLM dizendo: “Você errou o parâmetro. A API aceita id_cliente e não cpf. Corrija o input”.
Se o erro persistir na segunda tentativa, o grafo quebra o loop de forma determinística e joga para a esteira de tratamento de erros do sistema.

Construir agentes prontos para a realidade corporativa não é sobre tornar o modelo perfeito, mas sim sobre construir as barreiras arquiteturais certas para quando ele falhar.

Portfólio, code e blog