Un fornitore ti invia una proposta. Le slide mostrano un diagramma con riquadri e frecce: un LLM al centro, alcuni database ai lati, qualche icona di API. Sembra tutto a posto. Ma il diagramma non ti dice se il sistema si comporterà in modo affidabile sotto carico, cosa succede quando un’API va giù, quanto costa eseguire ogni conversazione, né se potrai cambiare fornitore tra due anni.
Quelle risposte stanno nell’architettura. E non è necessario essere un tecnico per fare le domande giuste.
Questo articolo traduce l’architettura degli agenti AI nei termini che contano per gli acquisti: affidabilità, costi operativi e dipendenza dal fornitore. Consideralo una checklist per valutare il progetto di un vendor prima di firmare.
I quattro pilastri che ogni architettura agentica ha (che il fornitore li nomini o meno)
Un agente AI pronto per la produzione è costruito su quattro componenti logici. I fornitori li chiamano in modo diverso, li combinano in vari modi e a volte li raggruppano in un’unica piattaforma su cui non si ha visibilità. Ma ci sono sempre.
1. Il Planner (il livello del “ragionamento”)
Il planner è il large language model (LLM) al cuore dell’agente. Riceve un obiettivo o un messaggio dell’utente, ragiona su cosa fare e decide quali strumenti chiamare. Alcune architetture usano una singola chiamata LLM per ogni passo; altre eseguono più cicli di ragionamento prima di agire.
Cosa chiedere al fornitore:
- Quale modello LLM alimenta il planner e come viene aggiornato? (Un aggiornamento del modello che cambia il comportamento senza preavviso è un rischio per l’affidabilità.)
- Il planner è deterministico o probabilistico? È possibile impostare soglie di confidenza o condizioni di fallback?
- Come viene istruito il planner? Hai visibilità o controllo sul system prompt?
2. Gli strumenti (le “mani” dell’agente)
Gli strumenti sono i collegamenti con il mondo esterno: query su database, chiamate API, invio di moduli, lettura di file, invio di email. Un agente senza strumenti è solo un chatbot. Il livello degli strumenti è dove gli agenti fanno davvero le cose.
Il numero, l’affidabilità e l’ambito degli strumenti determinano cosa l’agente può fare — e cosa potrebbe fare per errore. Uno strumento che invia email è utile; uno che le invia a chiunque senza un passaggio di approvazione è un rischio.
Cosa chiedere al fornitore:
- A quali strumenti ha accesso l’agente, e quell’insieme può essere limitato?
- Le chiamate agli strumenti vengono registrate in modo auditabile?
- Cosa succede quando una chiamata a uno strumento fallisce — l’agente riprova, scala a un operatore umano o fallisce silenziosamente?
3. La memoria (cosa ricorda l’agente)
La memoria nell’architettura degli agenti AI è più articolata di quanto sembri. Esistono almeno tre tipi distinti:
- Memoria a breve termine: il contesto della conversazione corrente, mantenuto nella context window dell’LLM. Si azzera alla fine della sessione.
- Memoria a lungo termine: fatti archiviati in un database e recuperati all’occorrenza — storico clienti, conoscenza del prodotto, interazioni precedenti.
- Memoria procedurale: regole, flussi di lavoro e schemi integrati nelle istruzioni dell’agente o nel suo fine-tuning.
Il design della memoria incide direttamente sull’esperienza utente e sui costi. Gli agenti con una memoria a lungo termine ben progettata risultano coerenti e consapevoli del contesto. Gli agenti che si affidano unicamente alla memoria a breve termine ripongono domande a cui gli utenti hanno già risposto.
Cosa chiedere al fornitore:
- Quali tipi di memoria include l’architettura?
- Dove vengono archiviati i dati dei clienti e sotto quale giurisdizione? (Per le aziende svizzere questo è rilevante ai fini della conformità alla nLPD — vedi il nostro articolo su Agenti AI e protezione dei dati svizzera.)
- La memoria a lungo termine può essere cancellata o corretta se contiene informazioni errate?
4. I guardrail (il livello di sicurezza e controllo)
I guardrail sono i vincoli che mantengono l’agente sul compito e entro un comportamento accettabile. Operano su più livelli: filtraggio degli input (blocco di richieste dannose o fuori ambito), validazione degli output (verifica delle risposte prima dell’invio), limiti di scope (impedire all’agente di intraprendere azioni al di fuori del suo ruolo definito) e logica di escalation (sapere quando passare il controllo a un essere umano).
Questo è il componente più spesso sottodimensionato nelle demo dei fornitori. Una demo funziona perché il fornitore controlla gli input. La produzione funziona perché i guardrail tengono quando gli input sono imprevedibili.
Cosa chiedere al fornitore:
- Cosa succede quando un utente cerca di far fare all’agente qualcosa al di fuori del suo ambito?
- È prevista un’opzione human-in-the-loop per azioni ad alto rischio (transazioni importanti, accesso a dati sensibili)?
- Come vengono aggiornate le regole dei guardrail con l’evolversi del business?
Come le scelte architetturali determinano i costi operativi
I costi di un agente AI non si riducono a una licenza. L’architettura determina una quota significativa del costo per interazione, che si accumula con la scala.
Il principale driver di costo è il consumo di token LLM. Ogni messaggio nella context window ha un costo. Un agente che passa l’intera cronologia della conversazione a ogni passo — anziché usare una memoria a lungo termine strutturata — brucia token in modo lineare rispetto alla lunghezza della conversazione. Per un’azienda che gestisce centinaia di interazioni al giorno, la scelta architetturale determina la curva dei costi.
Altri driver di costo da esaminare:
- Frequenza delle chiamate agli strumenti: più chiamate per interazione significano maggiore latenza e talvolta costi aggiuntivi di API di terze parti.
- Tier del modello: alcune architetture usano modelli frontier costosi per ogni passo; altre li riservano al ragionamento complesso e usano modelli più leggeri per i compiti semplici (un approccio a volte chiamato “model cascade”).
- Logica di retry: un agente che riprova le chiamate fallite senza una logica di circuit-breaker può moltiplicare i costi durante le interruzioni.
Il lock-in sta nell’architettura, non nel contratto
Il rischio di procurement più trascurato nei progetti con agenti AI è il lock-in architetturale. Un contratto può includere clausole di uscita; un’architettura non può sempre essere migrata a basso costo.
Il lock-in si accumula tipicamente in tre punti:
Store di memoria proprietari: se la memoria a lungo termine dell’agente è archiviata in un formato di database specifico del fornitore, la migrazione significa reimportare e rivalidare tutto il contesto storico — spesso mesi di dati accumulati.
Integrazioni di strumenti hard-coded: gli agenti costruiti direttamente sull’SDK di un fornitore tramite API di tool-calling proprietarie richiedono una riscrittura quando si cambia piattaforma. È diverso dagli agenti costruiti su standard aperti come il Model Context Protocol (MCP), dove gli strumenti sono più portabili. Approfondiamo il tema in Lock-in nelle piattaforme per agenti AI: i rischi che nessuno prezza.
Dipendenza dal modello: se la logica del planner è stata fortemente ottimizzata attorno alle peculiarità di un modello specifico (ad esempio un modello poi deprecato o aggiornato in modo significativo), la migrazione a un LLM diverso potrebbe richiedere di ricalibrare l’intero sistema.
Le architetture più sicure mantengono questi livelli debolmente accoppiati: il planner può cambiare modello, il livello di memoria usa pattern di recupero standard, gli strumenti si collegano tramite API documentate o protocolli aperti. Non è sempre realizzabile con il budget o le tempistiche disponibili, ma è la domanda da porre.
Una checklist di audit pratica prima di impegnarsi
Quando si valuta una proposta per un agente AI, queste domande rivelano la qualità del design più velocemente di qualsiasi demo:
Affidabilità
- Qual è il comportamento in caso di failover quando l’API LLM non è disponibile?
- Come gestisce l’agente input ambigui o contrastanti?
- Esiste un meccanismo per rilevare e interrompere loop infiniti o catene di tool runaway?
Costo
- Qual è il costo stimato in token per interazione e come scala con la lunghezza della conversazione?
- L’architettura usa un unico modello per tutti i compiti o un approccio a tier di costo?
Lock-in
- Quali componenti sono proprietari e quali usano standard aperti?
- Dove sono archiviati i dati e in quale formato sono esportabili?
- Se si cambiasse provider LLM, cosa dovrebbe essere riscritto?
Controllo
- Quali guardrail sono in vigore e chi può modificarli?
- Esiste un audit log completo delle chiamate agli strumenti e delle decisioni dell’agente?
Quando la revisione dell’architettura è davvero necessaria
Non ogni progetto con agenti AI richiede una revisione architetturale approfondita in fase di procurement. Un semplice chatbot FAQ senza accesso a strumenti e senza persistenza dei dati ha un rischio basso indipendentemente da come è costruito.
La posta architetturale si alza con:
- Accesso a strumenti su sistemi sensibili (CRM, ERP, dati finanziari, dati dei clienti)
- Alto volume di interazioni dove il costo per interazione si accumula
- Flussi di lavoro autonomi multi-step dove una decisione errata nelle fasi iniziali si propaga
- Esposizione normativa — tutto ciò che riguarda dati personali sotto il GDPR, la nLPD svizzera, o entrambi — molte aziende svizzere sono soggette a entrambi i regimi contemporaneamente
Se il tuo caso d’uso rientra in una di queste categorie, comprendi l’architettura prima del contratto, non dopo. Per una visione più ampia di un buon design agentico, vedi Orchestrazione di agenti AI: far lavorare gli agenti come un sistema e Cosa sono gli agenti AI? Una guida senza hype per i manager.
La decisione build-vs-buy è anch’essa influenzata dall’architettura: le piattaforme scambiano configurabilità con velocità; le build personalizzate scambiano velocità con controllo. Build vs Buy: un framework decisionale per gli agenti AI esamina direttamente quel trade-off.
Come si presenta una revisione architetturale ben fatta
In Orange ITS, quando valutiamo un progetto di agente AI — che lo stiamo costruendo noi o esaminando un sistema esistente — mappiamo esplicitamente i quattro componenti prima di scrivere una riga di codice. Questo significa definire il modello del planner e il suo comportamento in caso di fallback, specificare quali strumenti l’agente può invocare e in quali condizioni, progettare il modello di memoria per le prestazioni e la residenza dei dati, e scrivere la logica dei guardrail prima di tutto il resto.
Non è entusiasmante. È anche il motivo per cui i sistemi costruiti in questo modo non sorprendono i loro proprietari sei mesi dopo con bollette API crescenti, domande di compliance o un fornitore che dice che la migrazione costerà più della build originale.
Se stai valutando un progetto di agente AI e vuoi un secondo parere su una proposta di un fornitore — o una visione lucida di quale architettura si adatta al tuo caso d’uso — una chiamata di 30 minuti con il nostro team è il modo più rapido per ottenerlo. Mapperemo i quattro componenti rispetto ai tuoi requisiti e segnaleremo dove il design regge e dove porta rischi nascosti.