Systems Design Meditation · Edition 1
L'agente non è il sistema
Perché l'IA sta diventando un problema di infrastruttura
Edward Calderón
Architetto del Software
L'IA sta iniziando a scomparire nell'infrastruttura.
Non perché conti di meno. Perché si sta spostando più in profondità nello stack.
Per diversi anni la conversazione pubblica si è concentrata sul modello. Quale modello ragiona meglio? Quale modello ha il contesto più ampio? Quale modello scrive codice migliore? Queste domande restano utili. Ma non sono più sufficienti.
Un modello risponde. Un agente può agire. Una volta che il sistema è in grado di agire, l'architettura diventa importante quanto l'intelligenza.
L'unità di analisi è cambiata
Un modello linguistico mappa un input su un output probabilistico. Un agente operativo circonda quel modello con memoria, strumenti, identità, policy, code, database e feedback. Può leggere un ticket, interrogare la telemetria di produzione, modificare una configurazione e notificare un cliente. Ogni passo attraversa un confine di fiducia. La qualità della frase generata è solo una piccola parte del risultato.
Ecco perché il modello non è il sistema. Il modello è un partecipante all'interno del sistema.
Le domande utili, oggi, risultano familiari a chiunque abbia gestito infrastrutture cloud o distribuite: a cosa può accedere l'agente? Chi ne ha delegato l'autorità? Cosa può modificare? Che stato mantiene? Come viene osservata l'azione? Cosa succede se è sbagliata? L'azione può essere annullata? Chi è responsabile?
L'accesso agli strumenti trasforma un errore di ragionamento in una possibile transizione di stato. Se un chatbot inventa una politica di rimborso, l'output è sbagliato. Se un agente esegue il rimborso, aggiorna il libro mastro e chiude il caso, è cambiata l'organizzazione che lo circonda. Il modello di guasto non è più confinato al testo.
Progettare per un'azione limitata
Un'infrastruttura affidabile per gli agenti richiede diversi confini. L'identità dovrebbe essere specifica del workload, non una chiave API condivisa. L'autorizzazione dovrebbe essere ristretta, di breve durata ed esplicita riguardo alle risorse e alle azioni consentite. Le operazioni ad alto impatto richiedono gate di approvazione. Ogni invocazione di uno strumento richiede dati di audit strutturati: attore, delegante, input, decisione della policy, output e stato risultante.
Anche l'osservabilità deve andare oltre il consueto tracciamento delle richieste. Una traccia può dirci che una chiamata è andata a buon fine mentre l'azione di business era errata. Dobbiamo collegare le decisioni del modello alle chiamate agli strumenti e le chiamate agli strumenti ai loro effetti durevoli. La misura rilevante non è solo la latenza o l'uso di token. È capire se l'invariante previsto è ancora rispettato.
Il rollback è altrettanto concreto. Alcune azioni possono essere compensate: un deployment può tornare a una revisione precedente. Altre non possono davvero essere annullate: un'email è stata inviata, un segreto è stato esposto, un pagamento è stato regolato. L'architettura dovrebbe classificare le azioni prima che un agente le riceva, non dopo un incidente.
Si pensi a un agente che assiste nelle modifiche all'infrastruttura. Può esaminare le metriche in tutta sicurezza e proporre una patch. Applicare quella patch a un ambiente sandbox potrebbe richiedere una credenziale con ambito limitato. La produzione richiede la valutazione delle policy, un'approvazione umana per le modifiche rischiose, un rollout progressivo, health check e una condizione di arresto automatico. L'agente può partecipare a tutto il processo senza diventare un amministratore dai poteri illimitati.
Questo pattern ricorda il DevSecOps maturo perché il problema sottostante è noto: far transitare un cambiamento attraverso un sistema senza perdere il controllo del rischio. Gli agenti rendono l'interfaccia più flessibile, ma la flessibilità non elimina la disciplina operativa.
La capacità non è affidabilità
Un modello molto capace all'interno di un'infrastruttura progettata male produce un prodotto fragile. Un modello leggermente meno capace all'interno di un'architettura eccellente può produrre un sistema molto più affidabile. Il secondo sistema è in grado di contenere l'incertezza, rilevare i guasti e ripristinarsi.
È anche per questo che l'adozione aziendale sarà disomogenea. Le dimostrazioni ottimizzano la capacità visibile. I sistemi di produzione devono gestire il ciclo di vita delle identità, i confini dei dati, la risposta agli incidenti, i controlli dei costi, le evidenze per la conformità normativa e le dipendenze degradate. Questi livelli non sono mere tubature periferiche. Sono loro a determinare se all'intelligenza si possa affidare del lavoro.
Gli standard emergenti in materia di agenti sono utili, ma nessun protocollo può sostituire l'architettura. Un framework per agenti non può decidere la tolleranza al rischio di un'organizzazione. Un fornitore di modelli non può definire quali transizioni di stato siano reversibili. Quelle decisioni appartengono al sistema che circonda il modello.
La direzione pratica, quindi, non è l'autonomia ovunque. È un'autonomia graduata: osservare, raccomandare, agire entro un confine ristretto, guadagnarsi un'autorità più ampia grazie a un'affidabilità misurata. Questo offre ai team un modo per imparare senza fingere che i componenti probabilistici siano deterministici.
L'intelligenza da sola non crea infrastrutture affidabili.
L'architettura sì.