Che cosa significa davvero Agentic AI Architecture?

L’espressione inglese è ambigua. Letta superficialmente, può suggerire un’“architettura agentica” — forse perfino un’architettura intelligente —, come se l’architettura stessa possedesse intelligenza, autonomia o capacità di agire. Non è questo il significato che uso qui. La formula va sciolta come architecture of agentic AI systems: l’architettura di sistemi di intelligenza artificiale le cui componenti decisive sono agenti evoluti.

Un’architettura non diventa intelligente soltanto perché include componenti intelligenti. Può essere adattabile, riconfigurabile, context-aware o capace di sostenere l’autonomia, ma queste sono proprietà architetturali che devono essere definite e verificate separatamente. L’intelligenza appartiene al comportamento del sistema e, anzitutto, ai suoi agenti: interpretano obiettivi, costruiscono piani, scelgono strumenti, consultano memoria e conoscenza, valutano i risultati e modificano il proprio percorso durante l’esecuzione.

La differenza rispetto alle architetture con agenti che ho studiato quindici o vent’anni fa non consiste nella semplice presenza degli agenti. Neppure l’autonomia limitata, la cooperazione, la negoziazione, l’organizzazione multi-agente, gli obiettivi o il contesto sono idee nuove. La novità è il tipo di componente introdotto nell’architettura: un agente costruito intorno a un modello generativo capace di lavorare con il linguaggio naturale, combinare conoscenze eterogenee, generare dinamicamente piani e codice, utilizzare strumenti esterni e rivedere le proprie decisioni sulla base dei risultati intermedi.

Una semplice constatazione: l’interoperabilità — sia essa semantica oppure riguardi la sicurezza, l’autorizzazione o la fiducia —, che vent’anni fa ci procurava tanti problemi, sembra oggi quasi assorbita nella definizione stessa dell’agente. Un agente deve dichiarare le proprie capacità, essere in grado di scoprire e utilizzare strumenti e comunicare con altri agenti attraverso interfacce e protocolli comuni. I problemi non sono scomparsi, ma si sono spostati a un altro livello.

Questo nuovo agente non annulla la storia dei sistemi multi-agente; la continua su una base tecnologica radicalmente diversa. Proprio questa differenza giustifica la comparsa di una nuova famiglia nella lunga successione delle architetture software. Non perché l’architettura sia diventata essa stessa intelligente, ma perché deve organizzare, limitare e rendere intelligibile il comportamento di componenti dotati di capacità cognitive incomparabilmente maggiori e meno prevedibili rispetto agli agenti programmati mediante regole, piani o modelli BDI espliciti.

Una correzione al mio stesso pessimismo

Nelle pagine dedicate alla storia e al futuro dell’Ingegneria del software ho parlato del declino della sua forma classica. Non era il software a essere in declino, ma l’immagine di una disciplina autonoma, con confini relativamente chiari, metodi prescritti e un percorso ideale dalla specifica all’implementazione. Agile ha indebolito il prestigio delle metodologie pesanti, DevOps ha assorbito lo sviluppo nelle operazioni, il cloud ha trasformato l’applicazione in un servizio permanente e l’intelligenza artificiale generativa è sembrata ridurre la programmazione alla formulazione di un’intenzione in linguaggio naturale.

La lettura di Agentic AI Architecture non annulla questa interpretazione, ma la completa. La forma classica della disciplina si dissolve, mentre il problema ingegneristico ritorna più difficile di prima. Un modello linguistico può proporre un piano, scegliere uno strumento, generare codice e valutare un risultato. Ma proprio perché tutto ciò avviene in modo probabilistico e, talvolta, imprevedibile, il sistema che lo circonda deve essere progettato con maggiore rigore. Dio ci guardi dallo sviluppare, con una simile architettura, un’applicazione per guidare i razzi spaziali!

Cambia dunque il luogo in cui risiede la difficoltà. Non basta più progettare l’algoritmo e la struttura dei dati. Occorre progettare lo spazio nel quale un sistema può prendere decisioni, usare strumenti, modificare la propria strategia e apprendere dai risultati senza oltrepassare i limiti accettabili di sicurezza, costo e responsabilità.

Dalla scomposizione delle funzionalità alla scomposizione delle decisioni

L’idea più feconda del numero di InfoQ mi sembra la distinzione fra microservizi e agenti. I microservizi hanno scomposto la funzionalità: ogni servizio riceveva una responsabilità, controllava determinati dati e comunicava mediante interfacce ben definite. Per quanto complesso diventasse l’insieme, il percorso di una richiesta era, in linea di principio, noto e codificato in anticipo.

Un sistema di IA agentica scompone qualcos’altro: la decisione. Non gli viene prescritto l’intero cammino da seguire. In funzione dell’obiettivo, del contesto, dei risultati intermedi e delle valutazioni, decide a runtime quale agente o quale strumento usare, in quale ordine, se sia necessario un nuovo tentativo e quando il risultato possa essere accettato.

Si tratta di un cambiamento profondo dell’oggetto della progettazione. Nei sistemi classici progettavamo flussi di controllo; nei sistemi di IA agentica progettiamo le condizioni nelle quali il flusso di controllo può essere costruito dinamicamente. L’architetto non traccia più ogni percorso possibile, ma definisce lo spazio dei percorsi consentiti, gli strumenti disponibili, i criteri di valutazione e i confini oltre i quali l’agente non può passare.

Che cosa cambia rispetto ai microservizi?

La nuova architettura non sostituisce i microservizi e il cloud. Gli agenti continuano a usare come strumenti (micro)servizi, basi di dati, code di messaggi, API e infrastrutture di osservabilità. La novità è il livello decisionale aggiunto sopra di essi. La transizione non sarà quindi una rottura improvvisa, ma una sovrapposizione: queste architetture cresceranno sulle fondamenta dei sistemi distribuiti già esistenti.

Un nucleo probabilistico in un involucro deterministico

Un modello linguistico non è un servizio deterministico. La stessa richiesta può produrre risposte diverse e un risultato linguisticamente convincente può essere falso, incompleto o incompatibile con le regole del sistema. Per questo motivo, l’uscita dell’LLM non deve essere trattata né come una verità né come un comando direttamente eseguibile, ma come l’ingresso di un verificatore.

L’approccio sostenuto dagli autori dell’eMag è ingegneristico: il modello probabilistico deve essere inserito in un meccanismo controllato. L’agente può proporre un piano, ma l’esecuzione deve avvenire mediante strumenti con interfacce esplicite, autorizzazioni limitate e risultati verificabili. Il codice generato deve essere eseguito in un ambiente isolato; i risultati devono essere testati; ogni passo importante deve essere registrato; i tentativi devono essere limitati; e quando la fiducia diminuisce, il sistema deve tornare a un percorso deterministico oppure a un operatore umano.

In questa formula riconosco un ritorno dello spirito dell’Ingegneria del software. Non chiediamo al modello di diventare deterministico, perché ciò significherebbe annullarne il vantaggio. Usiamo la sua flessibilità dove è utile e circondiamo il non determinismo con strutture che rendono il sistema testabile, verificabile, recuperabile e, per quanto possibile, prevedibile.

Dalle catene ai grafi e poi al codice

L'evoluzione dei meccanismi che circondano gli agenti è essa stessa una piccola storia della maturazione ingegneristica. Le prime applicazioni collegavano più prompt in una catena lineare: classificazione, recupero dell'informazione, generazione. Erano facili da costruire ma fragili. Un errore iniziale si propagava fino alla fine senza reali meccanismi di recupero.

I grafi hanno introdotto diramazioni, nuovi tentativi, parallelismo, stati espliciti e validazioni. Il flusso è diventato ispezionabile e modificabile, e agenti specializzati hanno potuto essere coordinati da un orchestratore. Ma con la crescita degli scenari, i grafi hanno rischiato di diventare a loro volta complicati, rigidi e difficili da mantenere.

La fase successiva tratta il codice come meccanismo di ragionamento e verifica. L'agente può generare SQL, Python o altre forme eseguibili, eseguirle in una sandbox, osservare il fallimento e correggere la soluzione. Ciò non significa che ogni codice sintatticamente corretto sia anche semanticamente corretto. Ma compilazione, test, asserzioni e simulazione offrono cicli di feedback molto più rigorosi della valutazione di un testo libero.

Quattro elementi di un meccanismo robusto

• Sandbox di esecuzione: uno spazio isolato nel quale il codice può essere eseguito senza compromettere il sistema reale.
• Strumentazione e logging: registrazione dei passi, dei risultati, degli errori e degli stati intermedi.
• Meccanismo di validazione: test, asserzioni, regole di business, vincoli di sicurezza e conformità.
• Ciclo di raffinamento: correzione controllata della soluzione, con limiti di tempo, costo e numero di tentativi.

È significativo che la maturazione degli agenti non conduca dall'Ingegneria del software verso la magia, ma dall'improvvisazione dei prompt verso architettura, stati, protocolli, validazione e meccanismi di recupero. Il mestiere si sposta da prompt designer a system architect.

Il contesto come nucleo dello stato dell’universo dell’agente

Nel numero di InfoQ, il contesto è trattato come infrastruttura per il ragionamento: informazione selezionata, filtrata, ordinata e aggiornata prima di arrivare al modello. Questa formulazione mi è familiare, ma il legame con le mie ricerche è più forte di quanto avessi inizialmente affermato. Nella progettazione basata su agenti, il contesto è il nucleo dello stato dell’universo che l’agente deve percepire, interpretare e sul quale deve poter agire. L’agente non opera sulla realtà integrale, ma su una sua rappresentazione rilevante.

Nei lavori del 2003 su Agent-Based Modeling of Virtual Environments e sugli agenti basati sulla percezione virtuale, il problema era già quello della costruzione del mondo accessibile all’agente. Il campo percettivo, il nimbo delle entità, il degrado dell’informazione con la distanza e la trasformazione delle percezioni in concetti d’azione delimitavano l’universo effettivo dell’agente. Non tutto ciò che esisteva nell’ambiente virtuale come riflesso della realtà entrava automaticamente nel suo stato interno.

Più tardi, in Strengthening Context-Awareness of Virtual Species in Digital Ecosystems, il contesto è stato esteso a più facce della realtà modellata — clinica, ambientale, emotiva/BDI e sociale — ed è stato ottenuto mediante agenti di raccolta e un agente integratore. Il contesto non era dunque più una semplice appendice informativa, ma una costruzione distribuita, prodotta e mantenuta dai meccanismi previsti dall’architettura.

Contesto adattabile e spazio di stato mutabile

L’adattamento non significa soltanto aggiornare i valori delle variabili di stato entro uno schema fisso. La realtà cambia, ma cambiano anche gli obiettivi dell’agente. Quando l’obiettivo cambia, alcune informazioni diventano inutili, altre indispensabili, e lo spazio delle variabili di stato deve essere esso stesso riconfigurato. Si tratta di adattamento strutturale, non soltanto parametrico.

In Supporting Adaptability in Agent-Based Digital Healthcare Ecosystem, l’adattabilità era collegata al rapporto continuo fra realtà e sua rappresentazione digitale, nel paradigma R2V2R, nonché all’evoluzione degli organismi virtuali in un ecosistema multi-agente. In Evolution of Digital Species by Using Mutable Contexts, l’idea diventa esplicita già nel titolo: le specie di un ecosistema digitale possono evolvere usando contesti mutabili.

Questa distinzione è importante per l’attuale architettura dei sistemi di IA agentica. Un context engine che si limita a sostituire dati vecchi con dati nuovi rimane insufficiente. Deve poter modificare il modello del contesto: aggiungere fonti, variabili, relazioni e vincoli richiesti dal nuovo obiettivo ed eliminare gli elementi che non contribuiscono più alla decisione. Altrimenti l’agente resta prigioniero di un’ontologia del problema stabilita troppo presto.

Chi modifica l’universo rilevante dell’agente?

La domanda architetturale decisiva è chi realizza questa ristrutturazione. La prima possibilità è l’agente adattabile: osserva i propri risultati, rileva l’insufficienza del contesto, cerca nuove fonti, modifica la propria rappresentazione interna e si procura gli strumenti necessari al nuovo universo. Questa soluzione offre autonomia, ma rende più difficile la tracciabilità, perché l’agente diventa contemporaneamente utente e progettista del proprio mondo informativo.

La seconda possibilità è un context manager, collocato a un livello architetturale superiore. Esso conosce gli obiettivi, le politiche, i diritti di accesso, le fonti disponibili e le regole di scadenza; costruisce il contesto adeguato per ogni agente e lo modifica quando cambiano la realtà o gli scopi. In un’architettura multi-agente, il context manager può essere esso stesso un meta-agente oppure un servizio comune dell’ecosistema.

La soluzione realistica sarà probabilmente ibrida. L’agente può proporre modifiche del contesto, ma un livello superiore le valida, le autorizza e conserva la memoria della trasformazione. Ritroviamo qui la separazione fra controllo strategico e controllo operativo presente nelle mie ricerche sul processo software: l’agente decide all’interno di un quadro, mentre il livello architetturale superiore controlla il modo in cui il quadro stesso può evolvere.

Dall’agente all’ecosistema digitale

Un altro legame diretto con i miei lavori è l’idea di ecosistema digitale. Un sistema di IA agentica non è soltanto un programma suddiviso in più moduli intelligenti. Gli agenti formano una popolazione di entità autonome, con ruoli, obiettivi, risorse e contesti propri. Cooperano, si sostengono, negoziano, delegano attività, possono entrare in conflitto e possono produrre soluzioni differenti per la stessa situazione.

In Conceptual Modeling of the Healthcare Ecosystem e in Towards an Agent-Oriented Architecture of the Digital Healthcare Ecosystem, il passaggio dal sistema all’ecosistema significava precisamente abbandonare un’infrastruttura rigida e centralizzata a favore di un ambiente dinamico di cooperazione fra attori, servizi, organizzazioni e risorse digitali.

In Agentification of Electronic Healthcare Record Systems, questa idea è stata proseguita attraverso organizzazioni virtuali create intorno ai processi di cura dei pazienti, con un manager capace di costituirle, coordinarle e scioglierle. Gli agenti diventavano context-aware e goal-oriented, mentre gli avatar degli attori umani potevano partecipare alla cooperazione, alla negoziazione, alla mediazione e all’adattamento.

L’attuale architettura dei sistemi di IA agentica riprende lo stesso problema su una nuova scala tecnologica. Un orchestratore non deve essere soltanto il dispatcher delle chiamate ai modelli, ma il governatore temporaneo di un’organizzazione di agenti. Deve gestire collaborazione, contraddizione, consenso, reputazione, competenze, autorità e responsabilità degli agenti. In questo senso, la nozione di ecosistema è più espressiva di quella di semplice architettura multi-agente.

Lo strumentario integrato: dall’ambiente software all’agentic framework

La terza continuità riguarda lo strumentario. Nel libro Integrating Tools for Software Development, il processo software era modellato come un universo coerente di oggetti, attività, agenti e strumenti. L’integrazione non significava soltanto poter avviare più programmi dalla stessa interfaccia. Richiedeva linguaggi comuni di descrizione, stati e relazioni espliciti, controllo strategico e operativo, librerie di strumenti, regole di attivazione, meccanismi di eccezione e una macchina capace di eseguire il processo.

INTERFORM era precisamente il tentativo di trasformare la modellazione in un sistema esecutivo configurabile: vedeva gli oggetti attraverso facce, eseguiva attività, assegnava agenti, lanciava strumenti, modificava stati e gestiva eccezioni. Vista da questa prospettiva, l’attuale nozione di agentic harness è troppo modesta quando indica soltanto una successione di prompt o un grafo di chiamate. Per le applicazioni serie è necessario un framework integrato per l’esecuzione e il controllo degli agenti di IA.

Un simile framework non deve integrare soltanto gli strumenti, ma anche memoria, conoscenza, contesto, valutazione e regole organizzative. Diventa l’infrastruttura nella quale il non determinismo del modello viene trasformato in un processo osservabile e controllabile. Questo è, credo, il legame più diretto fra il mio libro del 1992 e il problema attuale: non l’integrazione di strumenti isolati, ma l’integrazione dell’intero universo di esecuzione del processo.

Quando il sistema funziona ma decide peggio

I sistemi distribuiti classici ci hanno abituato a fallimenti relativamente visibili: un servizio non risponde, un’operazione scade, una risposta è in ritardo, i dati diventano incoerenti. In un sistema di IA agentica basato su LLM, l’infrastruttura può rimanere perfettamente sana mentre la qualità del risultato si degrada.

Un agente può scegliere una fonte più debole, interpretare male un risultato intermedio o trasmettere a un altro agente un contesto incompleto. La decisione iniziale errata influenza i passi successivi e il degrado si propaga senza produrre necessariamente un’eccezione tecnica. La latenza rimane normale e il tasso di errore è basso, ma il sistema risponde peggio.

Nuove modalità di fallimento

• Degrado a cascata delle decisioni: una scelta iniziale errata riduce la qualità di tutte le fasi successive.
• Amplificazione dei nuovi tentativi: il meccanismo di valutazione richiede altri tentativi, aumentando costo e latenza senza garantire la convergenza.
• Degrado silenzioso: le metriche dell’infrastruttura restano buone, mentre diminuisce l’utilità per l’utente.
• Deriva dello stato e del contesto: gli agenti lavorano con versioni differenti o contraddittorie della realtà.
• Coordinamento eccessivo: il numero degli agenti e delle interazioni produce costo, latenza e nuovi punti di fallimento.

Di conseguenza, l’osservabilità deve seguire non soltanto la salute dell’infrastruttura, ma anche la salute della decisione: quali strumenti sono stati scelti, quali informazioni sono state usate, quali alternative sono state respinte, quanti nuovi tentativi si sono prodotti e mediante quale valutazione il risultato è stato accettato.

Autonomia limitata e osservabilità estesa

Il termine “agente autonomo” può creare l'impressione di una libertà totale. Nelle applicazioni reali, l'autonomia utile deve essere limitata. L'agente riceve uno spazio nel quale può scegliere, non il diritto di fare qualsiasi cosa. I budget di tempo e costo, il numero massimo di nuovi tentativi, la profondità del ragionamento, le autorizzazioni sugli strumenti e i dati accessibili devono essere definiti architetturalmente.

Il numero di InfoQ propone un'evoluzione prudente dell'impresa: prima l'infrastruttura di controllo, poi l'autonomia strutturata dei flussi e soltanto alla fine agenti capaci di costruire autonomamente la propria strategia. È un'idea con cui concordo. L'autonomia non deve precedere la governance. Sicurezza, tracciabilità, protezione dei dati, valutazione continua e intervento umano devono esistere prima di estendere la libertà del sistema.

Questa prudenza è tanto più necessaria in medicina, finanza, industria, infrastrutture e amministrazione pubblica. In questi ambiti, l'agente può sostenere la decisione e automatizzare parti del processo, ma l'estensione dell'autonomia deve seguire le evidenze accumulate, non il fascino tecnologico.

Un mio filo di ricerca, non un'analogia retrospettiva

La continuità con i miei lavori non si riduce alla coincidenza di alcuni termini. Può essere seguita in una successione di problemi evolutisi nell'arco di quasi quattro decenni:

• 1981–1992 — il processo e l'ambiente integrato: progettazione sistematica, interforma, INTERFORM e poi Integrating Tools for Software Development, con oggetti, attività, agenti, strumenti, stati e due livelli di controllo.
• 2003 — l'agente e l'universo percepito: modellazione degli ambienti virtuali basata su agenti, campi percettivi e trasformazione delle percezioni in decisione e azione.
• 2008 — gli obiettivi e i concern degli attori: Concern-Driven Design, dove interessi, rischi, obblighi e priorità organizzano il modello e l'architettura.
• 2011–2013 — adattabilità, contesto ed ecosistema: organismi virtuali, R2V2R, ecosistemi digitali, contesti multifaccettati e agenti di raccolta e integrazione.
• 2015 — agentificazione dell'infrastruttura: passaggio graduale dai servizi a organizzazioni virtuali di agenti e avatar context-aware, goal-oriented.
• 2019 — contesto mutabile: evoluzione delle specie digitali mediante la modifica non soltanto dello stato, ma anche della struttura del contesto.

InfoQ descrive una nuova generazione tecnologica basata sugli LLM, ma le domande architetturali non nascono dal nulla. Quali informazioni costituiscono il mondo dell'agente? Come cambia questo mondo quando cambia lo scopo? Chi coordina la collettività degli agenti? Come vengono integrati gli strumenti? Come si conservano lo stato e la memoria del processo? Come vengono gestite eccezioni e conflitti? Queste domande attraversano realmente la mia opera, anche se le risposte tecnologiche di oggi sono diverse.

Dagli agenti BDI agli agenti costruiti sugli LLM

Nelle mie riflessioni sul futuro della tecnologia sono tornato al modello BDI — Beliefs, Desires, Intentions. Nei lavori sugli agenti virtuali e, più tardi, sugli avatar negli ecosistemi digitali, l’agente non era soltanto un esecutore: possedeva una rappresentazione esplicita del mondo, perseguiva obiettivi e selezionava le proprie azioni secondo regole, piani, protocolli e modelli dello stato interno. La sua autonomia era reale, ma si esercitava entro una struttura concettuale progettata in anticipo.

Gli agenti attuali sono diversi non perché abbiano scoperto per la prima volta gli obiettivi, il contesto o la cooperazione, ma perché il loro nucleo decisionale è un modello generativo. Possono interpretare un requisito non completamente formalizzato, produrre rappresentazioni e piani che il progettista non aveva enumerato, generare codice, utilizzare strumenti descritti in linguaggio naturale e rivedere la strategia in funzione dei risultati. Questa capacità amplia enormemente il loro spazio d’azione, ma riduce in proporzione la prevedibilità.

Perciò non sono semplicemente agenti BDI modernizzati. Le loro “credenze” sono distribuite fra contesto attivo, memoria persistente, conoscenza del dominio, fonti esterne e parametri del modello; i loro “desideri” derivano dagli obiettivi dell’utente, dell’organizzazione o di altri agenti; le loro “intenzioni” assumono la forma di piani generati, valutati e rivisti dinamicamente. Il modello BDI rimane tuttavia utile perché obbliga l’architetto a distinguere ciò che l’agente considera vero, ciò che persegue e il piano al quale si è impegnato.

L’introduzione dei contesti mutabili aggiunge però un problema che il semplice schema BDI non risolve: il cambiamento dell’obiettivo può modificare la struttura stessa delle “credenze” rilevanti. Per questo l’architettura richiede agenti capaci di autoriconfigurarsi oppure un livello metacognitivo — context manager, supervisore o organizzazione di governance — che controlli l’evoluzione dell’universo informativo dell’agente.

Quando più agenti collaborano, si contraddicono o negoziano, il BDI individuale deve essere completato da una teoria dell’organizzazione: ruoli, autorità, protocolli, norme, reputazione, meccanismi di consenso e risoluzione dei conflitti. Qui l’architettura dei sistemi di IA agentica incontra direttamente le mie ricerche sulle organizzazioni virtuali e sugli ecosistemi digitali.

Che cosa va aggiunto alla formazione in Software Engineering?

Nella pagina sul futuro dell’Ingegneria del software ho sostenuto che lo studente non deve essere formato né come semplice programmatore né come operatore di uno strumento di IA. L’architettura dei sistemi di IA agentica rafforza questa conclusione, ma il legame con il vecchio nucleo della disciplina deve essere reso esplicito.

• Modellazione dell’universo dell’agente: stato, percezione, contesto, conoscenza, memoria e loro rapporto con gli obiettivi.
• Contesti mutabili: la differenza fra aggiornamento dei valori e modifica strutturale dello spazio delle variabili di stato.
• Context management: autoadattamento, meta-agenti, politiche di selezione, scadenza e riconvalida, e tracciabilità del cambiamento.
• Architettura degli ecosistemi digitali: cooperazione, sostegno reciproco, negoziazione, conflitto, consenso, ruoli e organizzazioni virtuali.
• Framework integrati: oggetti, attività, agenti e strumenti; registri delle capacità, protocolli, sandbox, valutatori e gestione delle eccezioni.
• Architettura dei sistemi di IA agentica: separazione della pianificazione dall’esecuzione, agenti specializzati, orchestrazione e flussi dinamici.
• Valutazione durante l’esecuzione: criteri di qualità, test, simulazione, valutatori e controllo della convergenza.
• Osservabilità delle decisioni: tracciamento delle scelte, degli strumenti, del contesto, dei nuovi tentativi e delle ragioni dell’accettazione del risultato.
• Sicurezza degli agenti: prompt injection, contaminazione dei risultati degli strumenti, autorizzazioni limitate e credenziali legate al compito.
• Autonomia governata: guardrail, fallback deterministici, human-in-the-loop e rilascio progressivo.
• Protocolli e integrazione: API, messaggistica asincrona, MCP, A2A e bounded context.
• Economia del sistema: costo dei token, latenza, numero di chiamate ai modelli e scelta dell’astrazione sufficiente più semplice.

Non ogni studente deve diventare un ricercatore di foundation model. Ma il futuro architetto software deve saper integrare una componente probabilistica in un sistema verificabile e progettare non soltanto il comportamento dell’agente, ma anche il suo universo rilevante, la collettività di cui fa parte e l’infrastruttura che ne limita e ne spiega le azioni.

Una nuova famiglia nella storia delle architetture software

La storia dell’Ingegneria del software può essere letta anche come una successione di risposte architetturali alla crescita della complessità. Un primo riferimento importante fu il volume di Mary Shaw e David Garlan, Software Architecture: Perspectives on an Emerging Discipline, pubblicato nel 1996. Il repertorio architetturale si è poi ampliato rapidamente: ai programmi monolitici sono seguite l’organizzazione a strati, le architetture client–server, i componenti, i sistemi distribuiti, SOA, i microservizi, le architetture orientate agli eventi e le piattaforme cloud-native. Ogni famiglia ha cambiato l’unità di scomposizione, la forma delle interazioni e il luogo nel quale veniva esercitato il controllo.

L’architettura dei sistemi di IA agentica deve essere collocata in questa storia. Non è soltanto un’estensione di marketing dei microservizi né una ridenominazione dei sistemi multi-agente. L’unità architetturale centrale diventa l’agente basato su un modello generativo, mentre l’oggetto della scomposizione si sposta dalle funzionalità alle capacità decisionali: pianificazione, ricerca, interpretazione, valutazione, esecuzione, memoria e supervisione.

Ciò non significa, tuttavia, che ogni applicazione debba essere trasformata in una collettività di agenti. Come in ogni fase precedente, la nuova astrazione è giustificata soltanto dove la complessità del problema lo richiede. Un flusso deterministico, un servizio ordinario o un algoritmo ben noto rimangono preferibili quando risolvono il problema in modo più semplice, economico e sicuro. La nuova famiglia architetturale diventa necessaria quando il percorso non può essere prescritto completamente, quando gli obiettivi devono essere interpretati, quando l’informazione rilevante cambia e quando la scelta delle azioni dipende da valutazioni prodotte durante l’esecuzione.

Declino o ritorno?

Continuo a credere che la forma classica dell’Ingegneria del software sia in declino. Non esiste più la stessa fiducia nelle metodologie universali, nella documentazione esaustiva e nella possibilità di progettare completamente il sistema prima dell’implementazione. Ma l’architettura dei sistemi di IA agentica mostra che la scomparsa della forma classica non significa la scomparsa della disciplina.

Potrebbe perfino verificarsi un ritorno. Quando la generazione automatica del codice sembrava ridurre il ruolo dell’ingegnere, l’attenzione si spostava verso l’uso di un modello già costruito. Ora, con gli agenti, constatiamo che il modello da solo non è il prodotto. Il prodotto è il sistema completo: modelli, servizi, strumenti, memoria, contesto, valutatori, protocolli, regole di accesso, meccanismi di recupero e le persone che ne rispondono.

Forse il nome della disciplina cambierà o verrà suddiviso fra AI Engineering, Platform Engineering, Systems Architecture e Governance. Ma la preoccupazione fondatrice rimane: come trasformare una capacità di calcolo impressionante, a nostra disposizione, in un sistema intelligibile, affidabile, manutenibile e responsabile?

Dai programmi che eseguono ai sistemi che decidono

La prima Ingegneria del software nacque quando i programmi divennero troppo grandi per essere controllati dal talento individuale. L’architettura dei sistemi di IA agentica appare quando le decisioni prodotte dai sistemi diventano troppo complesse per essere affidate a un modello isolato.

Non progettiamo più soltanto programmi che eseguono istruzioni. Progettiamo sistemi che interpretano obiettivi, costruiscono piani, scelgono strumenti, valutano i propri risultati e modificano il proprio percorso. Questa libertà apparente non riduce il bisogno di ingegneria. Lo amplifica.

Forse questa è la continuazione naturale delle mie riflessioni precedenti. Ho cominciato temendo che l’IA rendesse inutile la programmazione e dissolvesse l’Ingegneria del software. Ora comincio a vedere anche il movimento inverso: proprio perché l’IA può produrre codice e prendere decisioni, abbiamo bisogno di un’Ingegneria del software capace di progettare la libertà della macchina senza perdere il controllo delle sue conseguenze.

Riferimenti di lettura e lavori propri

La riflessione parte da The InfoQ eMag, Issue #125, July 2026 — Agentic AI Architecture, in particolare dai seguenti articoli:

• Mallika Rao, From Microservices to Agents: The Next Evolution of Distributed Systems.
• Karthik Ramgopal, The Evolution of Agentic Harnesses: From Chains to Graphs to Code.
• Adi Polak, Systemic Approach to Memory, Knowledge, and Context in Agentic AI Architectures.
• Subash Natarajan e Ahilan Ponnusamy, Agentic AI Architecture Framework for Enterprises.
• Rafał Gancarz, Agentic AI Architecture: Current Challenges and Future Opportunities.

Lavori propri in continuità concettuale

• Integrating Tools for Software Development (1992)
  Modellazione del processo mediante oggetti, attività, agenti e strumenti; integrazione, stato, controllo e architettura dell'ambiente INTERFORM.
• Agent-Based Modeling of Virtual Environments (2003)
  Percezione, stato interno e universo accessibile all'agente virtuale.
• Concern-Driven Design (2008)
  Interessi, rischi, obblighi e priorità che organizzano obiettivi e architettura.
• Conceptual Modeling of the Healthcare Ecosystem (2011)
  Il passaggio dal sistema all'ecosistema e la cooperazione fra entità autonome.
• Supporting Adaptability in Agent-Based Digital Healthcare Ecosystem (2011)
  Adattabilità, R2V2R, organismi virtuali ed evoluzione della rappresentazione digitale.
• Towards an Agent-Oriented Architecture of the Digital Healthcare Ecosystem (2012)
  Agenti specializzati, organizzazioni e infrastruttura di un ecosistema digitale.
• Strengthening Context-Awareness of Virtual Species in Digital Ecosystems (2013)
  Contesto multifaccettato, agenti di raccolta e integrazione dello stato rilevante.
• Agentification of Electronic Healthcare Record Systems (2015)
  Organizzazioni virtuali, manager organizzativo, agenti goal-oriented e avatar.
• Evolution of Digital Species by Using Mutable Contexts (2019)
  Evoluzione dell'agente attraverso il cambiamento strutturale del contesto.

Collegamenti interni

• Storia dell'Ingegneria del software
  La cronologia della disciplina, dalla crisi del software all'IA generativa.
• Il futuro dell'Ingegneria del software
  Saggio-dialogo sulla professione, l'educazione e la scuola di Software Engineering della FILS.
• Ordine nel caos
  La macchina astratta, l'interforma e il progetto INTERFORM.
• Riflessioni
  Testi sulla tecnologia, l'intelligenza artificiale, la professione e ciò che rimane.