Il modo più veloce per sprecare un trimestre di ingegneria è costruire un agente quando sarebbe bastato un workflow. Il modo più lento per spedire qualcosa di utile è costruire un workflow quando il lavoro chiede davvero un agente.
Abbiamo spedito entrambi, e abbiamo spedito quello sbagliato. Questa è la forma della domanda che ora ci facciamo prima di toccare qualsiasi riga di codice.
I workflow sono il default
Un workflow è una serie di passi con ramificazione esplicita. Tu scrivi la logica. Il sistema la esegue allo stesso modo ogni volta. Quando qualcosa si rompe, puoi puntare la riga.
Se puoi descrivere il lavoro come un diagramma di flusso e il diagramma non è imbarazzantemente grande, costruisci un workflow. Sono più economici da scrivere, più economici da debuggare, e le persone che ti sostituiranno tra tre anni ti ringrazieranno.
La fregatura è che "descrivibile come diagramma di flusso" richiede
onestà vera. Un diagramma con 47 rami e quattro casi default che
significano per lo più "chiedi a Sarah" non è un workflow — è un
workflow che cerca di scappare dalla propria pelle.
Gli agenti sono per il giudizio irriducibile
Si ricorre a un agente quando il lavoro ha due proprietà:
- Lo spazio degli input è troppo grande da enumerare in anticipo.
- C'è una decisione di giudizio nel loop che non si comprime in regole.
Il customer support è l'esempio classico. Puoi scrivere regole per i novanta casi ovvi. L'altro dieci per cento è il motivo per cui il team è esausto. Un agente si guadagna il posto in quel dieci per cento — e nel novanta noioso, lo avvolgi in un workflow.
La via di mezzo che la gente si perde
La maggior parte di quello che costruiamo non è né un workflow puro né un agente puro. È un workflow con un piccolo agente dentro un passo: il passo che richiede giudizio, retrieval o riformulazione.
Quella forma ibrida ha due enormi vantaggi:
- L'osservabilità resta sana. Puoi ancora puntare la riga dove le cose si sono rotte. L'agente non sta decidendo cosa fare dopo — sta decidendo una cosa specifica dentro un passo conosciuto.
- Puoi sostituire l'agente più tardi. Quando il modello migliora, o quando il tuo giudizio si comprime in regole, scambi il passo.
Se puoi rompere il lavoro in un workflow dove l'agente gestisce solo uno o due passi, fallo. Il loop di agente puro raramente è la risposta giusta.
Le domande che facciamo per prime
Quando un team viene da noi, prima di suggerire qualsiasi cosa, attraversiamo:
- Puoi darmi le regole? Se sì, è un workflow. Se "beh, dipende dalla situazione" — siamo più vicini ad avere bisogno di un agente.
- Qual è il costo di una risposta sbagliata? Costi più alti significano più guardrail, più human-in-the-loop, forma più deterministica.
- Quanto spesso cambia il lavoro? Regole volatili → agenti (generalizzano). Regole stabili → workflow (sono economici da mantenere).
- Chi ne sarà proprietario dopo che noi ce ne andiamo? Se il team non può mantenere un servizio Python, non dovremmo costruirne uno. Lo strumento giusto è quello che possono far girare un martedì mattina.
Un'euristica utile
Se riesci a immaginare un Notion che descrive l'intero processo in meno di una pagina, è un workflow.
Se il processo continua a sfuggire dal documento — se ogni trimestre il team chiede "aspetta, lo facciamo ancora così?" — c'è un problema in forma di agente nascosto dentro. Trovalo.