A maioria dos agentes em produção opera sobre fluxos que têm estados, transições e condições de guarda, mas que nunca foram modelados para isto. O fluxo existe implicitamente dentro do prompt, distribuído entre instruções condicionais que orientam o modelo a seguir caminhos diferentes conforme o contexto acumulado. O modelo interpreta essas instruções a cada turno, reconstrói a posição no fluxo a partir do histórico e decide o próximo passo por inferência probabilística. Enquanto o fluxo ainda é linear e curto, essa abordagem funciona. A partir do momento em que o fluxo contém ramificações, loops condicionais ou estados de espera, a reconstrução implícita da posição no grafo se torna a principal fonte de erro comportamental do agente.
O que uma state machine faz por um agente é separar duas responsabilidades que costumam estar sobrepostas: decidir o que fazer dentro de um estado e decidir pra qual estado transicionar. No modelo implícito, o LLM executa ambas simultaneamente, o que significa que a qualidade da transição depende da qualidade da compreensão do contexto completo pelo modelo naquele momento. No modelo explícito, a máquina de estados controla as transições e o LLM opera apenas dentro do escopo de cada estado, com prompt, ferramentas e critérios de saída específicos pra aquele ponto do fluxo. O efeito prático é que o modelo recebe menos responsabilidade por turno e opera sobre um contexto mais estreito, o que produz saídas mais fáceis de validar porque o conjunto de saídas aceitáveis em cada estado é finito e pré-definido.
O StateFlow, publicado por pesquisadores ligados ao projeto AutoGen, formalizou essa separação ao modelar a resolução de tarefas como uma máquina de estados onde cada estado executa ações específicas e as transições são controladas por regras heurísticas ou por decisões do modelo sob restrições explícitas. O resultado nos benchmarks foi consistente: melhor desempenho com menor custo, até porque o modelo opera sobre um problema menor em cada estado e as transições incorretas são capturadas pelo grafo antes de propagarem erro. O LangGraph seguiu direção semelhante ao modelar workflows como grafos dirigidos com estado tipado. A convergência dessas abordagens independentes confirma o que a prática em produção já indicava: fluxos agênticos complexos precisam de um modelo de controle externo ao LLM.
Modelar um fluxo agêntico como state machine começa pela identificação dos estados reais do processo. Um agente que processa pedidos de reembolso pode ter estados como recebimento_do_pedido, verificacao_de_politica, solicitacao_de_documentos, analise_de_documentos, decisao e comunicacao_ao_cliente. Cada estado define quais ferramentas estão disponíveis, qual prompt o modelo recebe, quais saídas são válidas e quais transições são permitidas. O estado verificacao_de_politica pode transicionar pra solicitacao_de_documentos ou pra decisao, mas não diretamente pra comunicacao_ao_cliente, e essa restrição é imposta pelo grafo. O modelo não precisa saber que a transição é proibida, porque a máquina de estados nunca a oferece como opção.
Considero que o benefício mais imediato dessa modelagem aparece na observabilidade. Cada execução produz uma sequência de transições que pode ser comparada contra os caminhos esperados do grafo. Desvios são detectáveis por inspeção direta: se o agente transitou de verificacao_de_politica pra comunicacao_ao_cliente sem passar por decisao, isso indica um bug no grafo ou uma transição mal configurada. Sem um modelo de estados, o mesmo desvio só vai se manifestar como uma resposta final incorreta, cuja origem identificável exigiria reconstrução manual do raciocínio ao longo de múltiplos turnos.
O trade-off principal é o custo de modelagem antecipada. Uma state machine exige que o grafo de estados e transições esteja definido antes da execução, o que impõe um investimento de design que não existe no modelo implícito, onde o fluxo emerge do prompt e se adapta organicamente ao que o modelo encontra no contexto. Pra fluxos exploratórios, onde o espaço de estados não é conhecido antecipadamente, a máquina de estados é prematura. Pra fluxos operacionais, onde o processo tem regras de negócio definidas e caminhos previsíveis, o investimento em modelagem se paga na primeira semana de produção, quando a primeira anomalia é detectada pelo grafo em vez de pelo cliente.
Rigidez é o outro custo. Uma state machine bem definida impede o modelo de tomar atalhos criativos que, em alguns casos, produziriam resultados corretos por caminhos não previstos. Apesar disso, essa rigidez se traduz pra mim como benefício em produção: o atalho criativo que funciona em 90% dos casos e falha silenciosamente em 10% é exatamente o tipo de comportamento que a máquina de estados existe pra eliminar. A previsibilidade do fluxo vale o custo de abrir mão de uma eficiência marginal.
Na prática, a implementação não exige frameworks específicos. O XState, com a extensão statelyai/agent, oferece integração direta entre máquinas de estados e chamadas a LLMs. O LangGraph oferece primitivas semelhantes com estado tipado via TypedDict, checkpointing automático e execução paralela de branches. A escolha entre frameworks é secundária em relação à decisão de modelar o fluxo como um grafo explícito. Até mesmo uma implementação manual com um dicionário de estados, funções de transição e validação de saída por estado já captura o benefício principal: o LLM opera em escopo reduzido, as transições são verificáveis e o estado do processo é recuperável a partir de qualquer ponto. Ponto.
Minha conclusão é que o padrão em arquiteturas agênticas que amadurecem passa inevitavelmente pela migração progressiva de lógica de controle pra fora do prompt e pra dentro de estruturas formais de orquestração. A state machine é a mais direta dessas estruturas, mas não a única, e raramente suficiente isoladamente. O que ela resolve de forma definitiva é o problema da posição no fluxo: o agente sempre sabe onde está, o que pode fazer e pra onde pode ir, sem depender da capacidade do modelo de reconstituir essa informação a partir de um histórico de contexto que cresce a cada turno, é podado constantemente, e que compete por atenção com o conteúdo da tarefa em si.