Il modello è la parte più facile da sostituire in un sistema di agenti.
Il dibattito pubblico resta fermo sulla classifica: quale LLM ragiona meglio, quale costa meno per token. Ma un modello si cambia in un pomeriggio. Ciò che non si cambia è l’harness intorno: dove vive lo stato, come è isolata la memoria tra un task e l’altro, chi possiede l’ambiente di esecuzione.
I tre pattern che oggi si contendono la produzione - esecuzione gestita dal vendor, esecuzione durevole su infrastruttura propria, orchestrazione multi-agente per ruoli - non si distinguono per qualità del modello. Si distinguono per chi paga il costo operativo e per cosa succede quando un processo lungo cade a metà.
Quell’ultimo punto separa una demo da un sistema. Un agente che gira per ore deve sopravvivere a un riavvio: checkpoint, stato persistente, operazioni idempotenti. Non è un problema nuovo e non è nemmeno specifico degli agenti: è orchestrazione di workflow, lo stesso lavoro che l’ingegneria backend fa da anni con macchine a stati e code durevoli. Cambia il nome, non la sostanza.
La decisione che regge il sistema, quindi, non è la scelta del modello. È dove tieni lo stato, come isoli la memoria, dove metti i confini di compute. Ed è anche la decisione che i team prendono per ultima, dopo aver scelto il modello che si vede in classifica.
Trattare gli agenti come forza lavoro stabile significa trattarne l’infrastruttura come un sistema di produzione. L’affidabilità non esce dal modello: esce dall’architettura che lo contiene.
