12 ottobre 2026

State machine e agent AI: determinismo al centro, libertà (controllata) ai bordi

Come progettare workflow agentici che non “deragliano”, rispettano vincoli di business e restano osservabili e debuggabili.

Gli agent AI sono potenti proprio perché non deterministici. Ma quando entrano in processi reali—email, approvazioni, compliance, tool che agiscono su sistemi—serve una struttura che garantisca vincoli, auditabilità e controllo. Le state machine (e le statechart) offrono un modello matematico per orchestrare l’autonomia: determinismo nel flusso, non-determinismo confinato nei singoli step. Vediamo cosa significa in pratica, come si implementa e perché migliora sicurezza, debug e osservabilità.

Gli agent AI sono, per definizione, non deterministici: a parità di input possono produrre risultati diversi, possono fallire in modi inattesi e—se hanno accesso ad azioni “reali” (invio email, pagamenti, modifiche a dati)—possono anche fare danni.

Eppure, molti dei casi d’uso più interessanti in azienda richiedono l’opposto: vincoli forti, passaggi obbligatori, approvazioni, invarianti di sicurezza, audit trail. Qui entra in gioco un’idea vecchia quanto l’informatica, ma sorprendentemente attuale: modellare il flusso con una state machine.

L’intuizione chiave è semplice:

Determinismo nel core, non-determinismo ai bordi.

Ovvero: lasciamo l’agente “libero” dentro singoli step ben delimitati, ma facciamo sì che il percorso complessivo sia governato da una macchina a stati. Il risultato è un workflow agentico che mantiene flessibilità senza perdere controllo.

Perché una state machine per qualcosa di non deterministico?

A prima vista sembra una contraddizione: una state machine è un modello deterministico, un agente è imprevedibile. In realtà è proprio il punto.

Una state machine ti dà una garanzia strutturale: non puoi essere in uno stato impossibile e non puoi compiere una transizione non prevista. Non è una “best practice” o un consiglio nel prompt: è una proprietà del modello.

Quando un agente deve rispettare regole di business o vincoli di sicurezza, affidarsi a istruzioni del tipo “non farlo mai” è fragile. Può funzionare in test o evaluation, ma non è una garanzia.

Con una macchina a stati, invece, il vincolo diventa architetturale: se la transizione DRAFTED -> SENT richiede un evento APPROVED_BY_USER, allora senza quell’evento non si invia nulla, indipendentemente da cosa “vorrebbe” fare il modello.

Un esempio concreto: email drafting con approvazione umana

Caso tipico: un agente prepara una bozza di email (magari attingendo a CRM, ticket o contesto interno), ma non deve inviarla senza approvazione.

Una modellazione possibile:

  • Idle (nessuna richiesta)
  • CollectingContext (recupero dati/brief)
  • Drafting (l’agente scrive la bozza)
  • WaitingForApproval (mostra bozza, attende input umano)
  • Sending (invio solo se approvato)
  • Done / Error

Qui l’agente opera soprattutto in Drafting, ma lo “spazio d’azione” è confinato. Lo stato Sending può essere raggiunto solo tramite eventi e condizioni che tu controlli.

Questa è l’essenza del pattern: l’agente fa il lavoro cognitivo, la state machine fa rispettare il contratto.

Osservabilità e debug: dal caos dei log a una mappa leggibile

Un problema ricorrente nei sistemi agentici è capire cosa stiano facendo davvero. Se hai solo una sequenza di messaggi e tool call, ricostruire il comportamento è spesso un incubo: manca una struttura su cui proiettare i segnali.

Con una state machine puoi invece:

  • mappare le trace sulle transizioni
  • capire dove l’agente si blocca o ripete cicli
  • vedere quali percorsi sono più frequenti
  • costruire una heatmap del flusso (quali stati/transizioni consumano più tempo o falliscono di più)

Questo cambia anche il modo di ottimizzare:

  • se un “quadrante basso” della heatmap è troppo caldo, forse lì serve un prompt migliore, un modello diverso, un tool più affidabile o una logica di retry
  • se un certo ramo non dovrebbe essere così frequentato, forse la UX sta spingendo gli utenti verso il percorso sbagliato

In breve: la macchina a stati diventa una spina dorsale osservabile.

Come si implementa davvero (senza magia)

Le state machine non sono una cosa “speciale” legata a una libreria: sono un pattern fondamentale e si possono implementare in qualunque linguaggio.

La forma minimale è:

  1. Stato iniziale
  2. loop: finché non sei in uno stato finale
    • leggi il prossimo evento
    • calcoli il prossimo stato (in base a stato corrente + evento)
    • esegui gli effetti (side effect: chiamate a tool, chiamate al modello, IO)

In molti workflow agentici questo schema è già presente, anche se “sparso” in if/else, callback, code review difficili e regole implicite. Formalizzarlo come macchina a stati rende tutto più esplicito.

Dove sta l’AI nel loop?

Tipicamente:

  • lo stato decide quando chiamare il modello
  • il modello produce un output non deterministico
  • la macchina a stati decide come interpretarlo e quale transizione sia lecita

Ed è qui che entrano in gioco strumenti tipici delle statechart.

Gestire output non deterministici: guard, schema e mitigazioni

La domanda pratica è inevitabile: se l’AI può rispondere “in modo creativo”, come scelgo la transizione corretta?

La risposta architetturale è: non ti fidi dell’output “grezzo”. Lo validi e lo classifichi.

1) Guard e validazione

Usa guard/condizioni per consentire una transizione solo se i dati:

  • rispettano uno schema (es. JSON Schema / Zod)
  • contengono campi obbligatori
  • ricadono in un insieme di valori permessi (enum)

Se non passa, non “vai avanti lo stesso”: transizioni verso error handling.

2) Stati di recupero

Quando qualcosa va storto, conviene avere stati espliciti:

  • RetryingModelCall (con backoff e limiti)
  • RePrompting (prompt più vincolante)
  • Fallback (modello alternativo / percorso manuale)
  • EscalationToHuman (handoff)

Questo approccio ti costringe a pensare alle possibilità reali e a non nascondere l’errore sotto al tappeto.

Multi-agent, sub-agent, graph engineering: tutto converge

Negli ultimi anni sono spuntate etichette diverse: loop engineering, graph engineering, sub-agents, deep agents… spesso cambiano i nomi, ma l’ossatura concettuale tende a convergere su due pilastri:

  • Actor model: più entità concorrenti che comunicano tramite messaggi (coordinazione tra agenti/componenti)
  • State machines/statechart: definiscono il comportamento nel tempo di ciascuna entità (cosa può accadere e quando)

In altre parole: puoi avere più agenti che “parlano” tra loro (attori), ma è la macchina a stati che evita che il sistema diventi una conversazione infinita senza regole.

Quanto scala questo approccio?

Non tutti i casi d’uso lo richiedono.

  • Se stai chiedendo al modello di scrivere una poesia, spesso una state machine è eccessiva.
  • Se stai orchestrando azioni, vincoli, approvazioni, compliance, audit o passi multipli, diventa rapidamente una scelta pragmatica.

In produzione si vedono macchine piccole (2–3 stati) e macchine molto grandi. Quando inizi a modellare processi aziendali reali—rami, eccezioni, recuperi, varianti—non è raro arrivare a decine o centinaia di stati. A quel punto strumenti di visualizzazione e refactoring diventano fondamentali per mantenere la complessità gestibile.

Implicazione pratica per chi fa frontend

Nel frontend gli agenti entrano spesso sotto forma di:

  • assistenti che preparano contenuti (email, ticket, report)
  • automazioni che chiamano API e compongono step UI
  • esperienze guidate (wizard “intelligenti”) con recupero errori

Una state machine ti permette di:

  • rendere espliciti i passaggi UI (e i punti in cui serve conferma)
  • gestire in modo robusto loading/error/retry
  • mantenere allineati UI state e workflow backend
  • ottenere telemetria leggibile: non solo “è fallito”, ma dove e in quale transizione

Se già usi macchine a stati per UI complesse, applicare lo stesso modello ai workflow agentici è un’estensione naturale.

Sintesi

Gli agent AI sono potenti perché esplorano possibilità; sono rischiosi perché possono fare la cosa sbagliata nel momento sbagliato. Una state machine risolve questa tensione separando responsabilità:

  • l’AI genera opzioni e contenuti dentro step delimitati
  • la state machine governa il flusso, impone vincoli, gestisce errori e rende il sistema osservabile

Per workflow reali (approvazioni, azioni irreversibili, compliance, processi multi-step) la domanda non è “se” serva controllo, ma dove metterlo. Metterlo nella struttura—anziché sperare che un prompt basti—è spesso la differenza tra un prototipo interessante e un sistema affidabile.