Se i tuoi agenti AI .NET costano troppo ecco dove intervenire

Un manager entra nella riunione del lunedì mattina con un'idea fissa.

Ha visto una demo su LinkedIn: un agente AI che gestisce l'assistenza clienti di un'azienda, risponde alle richieste, apre ticket interni, aggiorna il CRM, manda notifiche.

Tutto in autonomia. Tutto in tempo reale.

E adesso guarda te, il developer senior della stanza, con quella domanda già formata sulle labbra: "Lo possiamo fare anche noi?"

Silenzio. Perché' sai già come finisce.

Quella demo girava su un dataset finto, con un modello da trenta centesimi a chiamata, senza logging, senza sicurezza, senza nulla che regga alla prima settimana in produzione con utenti reali.

Ma non puoi dirlo così. Devi rispondere qualcosa di intelligente.

E in questo momento, se non hai già costruito un agente AI che funziona davvero, quella risposta ti manca.

Questa è la situazione in cui si trovano decine di developer italiani ogni settimana nel 2026.

Non è più una questione di curiosità verso una tecnologia emergente: è una questione di competitività professionale.

Le aziende non cercano più chi conosce l'AI "in teoria".

Cercano chi sa creare sistemi che funzionano, che si integrano con l'infrastruttura esistente, che non costano una fortuna in token e che non si rompono quando un utente scrive qualcosa di inaspettato.

E il gap tra chi sa farlo e chi sa fare solo la demo si misura, oggi, si misura in differenze di stipendio, promozioni e progetti assegnati.

Il problema è che la quasi totalità dei tutorial sugli agenti AI insegna a costruire demo.

Mostrano un kernel con due plugin, un agente che interroga Wikipedia o calcola la data corrente, un esempio che funziona in locale e non ha mai visto un utente reale.

Utile per capire la meccanica di base, inutile per chi deve decidere se e come portare un agente in produzione su un sistema aziendale con requisiti di sicurezza, osservabilità e costi operativi sostenibili.

Tutti parlano di agenti AI. Quasi nessuno sa come costruirli davvero.

Ed è qui che entrano in gioco strumenti come Semantic Kernel e .NET, e soprattutto le competenze architetturali per usarli in modo professionale.

Se hai già letto il nostro articolo introduttivo su Semantic Kernel, qui trovi quello che viene dopo: non i primi passi, ma i problemi reali che emergono quando smetti di fare esperimenti e inizi a ragionare in termini di produzione.

Cosa sono davvero gli agenti AI e perchè cambiano il modo di sviluppare software

C'è una frase che sento spesso nei team di sviluppo: "Abbiamo già integrato l'AI, usiamo ChatGPT tramite API."

Giusto.

Ma usare un'API LLM e costruire un agente AI sono cose così diverse che quasi non dovrebbero condividere lo stesso nome.

Con una chiamata LLM classica, il controllo del flusso è completamente nelle tue mani.

Invii un testo, ricevi una risposta testuale, decidi cosa farne.

Il modello è uno strumento passivo: esegue quando chiamato, risponde solo a quello che gli chiedi.

Se vuoi che recuperi dati da un database, lo fai tu prima della chiamata. Se vuoi che aggiorni un record, lo fai tu dopo la risposta.

Tutta la logica decisionale rimane nel tuo codice, deterministica e testabile come qualsiasi altro pezzo di software.

Un agente AI funziona in modo radicalmente diverso.

Invece di decidere tu la sequenza di operazioni, fornisci all'agente un insieme di funzioni che può invocare autonomamente.

Il modello ragiona su quale funzione chiamare, con quali parametri, valuta il risultato intermedio e decide se il suo obiettivo è raggiunto o se serve un altro passo.

Tu definisci le capacità del sistema. Il modello decide la strategia di esecuzione.

È uno spostamento di responsabilità che ha implicazioni profonde su come si progetta, si testa e si porta in produzione il software.

Questo schema, che prende il nome di ReAct (Reasoning and Acting), è alla base di tutti i sistemi ad agenti moderni.

Nel Semantic Kernel è implementato nativamente: il modello riceve la lista dei tool disponibili con le loro descrizioni, decide quali invocare, esegue le chiamate, ragiona sui risultati e continua finchè ritiene di aver completato il compito.

Ogni ciclo genera nuovi messaggi nella storia conversazionale, che vengono reinviati al modello insieme ai risultati dei tool.

Un agente AI non è un chatbot migliorato: è un componente che prende decisioni.

Progettare un sistema che prende decisioni è un’attività diversa dal progettare un sistema che risponde a domande.

Perchè le aziende italiane stanno investendo sugli agenti AI nel 2026

Nei settori dove la variabilità dei casi è alta, come l'assistenza clienti, l'analisi documentale, l'integrazione tra sistemi eterogenei, i team di sviluppo hanno sempre scritto enormi quantità di codice per gestire eccezioni, varianti e scenari imprevisti.

Ogni nuova casistica richiedeva nuovo codice, nuovi test, nuova manutenzione.

Un agente ben progettato copre questa variabilità con un set di funzioni generali ed istruzioni comportamentali, invece che con rami condizionali infiniti.

La differenza pratica per un team: con le chiamate LLM tradizionali, il codice cresce linearmente con la complessità del problema.

Con un agente, deleghi al modello la pianificazione dei passi intermedi.

Il codice che scrivi definisce cosa il sistema può fare, non come deve farlo in ogni scenario possibile.

Per problemi ad alta variabilità, questo riduce drasticamente la superficie di codice da mantenere.

Non è magia e non è privo di rischi, ma il rapporto tra complessità del problema risolto e codice da scrivere è significativamente migliore per una classe specifica di problemi.

Quando ha senso usare un agente e quando è eccessivo

Gli agenti brillano dove il numero di combinazioni possibili di passi è troppo alto per essere codificato esplicitamente.

Puoi leggere questo concetto in modo più concreto se lo traduci in situazioni reali:

• Quando il flusso cambia in base all’input dell’utente
• Quando i passi intermedi non sono prevedibili a priori
• Quando il numero di combinazioni cresce rapidamente
• Quando scrivere tutto in codice porterebbe a centinaia di condizioni

Non usare un agente quando il flusso di lavoro ha passi fissi e noti: il codice imperativo classico è più prevedibile, più testabile e molto più economico in termini di token e latenza.

Una buona euristica: se riesci a disegnare un diagramma di flusso completo del problema con meno di dieci nodi decisionali, probabilmente non ti serve un agente.

Se il diagramma richiede centinaia di rami per coprire tutti i casi reali, un agente è la scelta giusta.

LLM e agenti AI: la differenza che determina l'architettura del tuo sistema

La confusione tra LLM e agenti AI è comprensibile, perché' entrambi usano un modello linguistico come componente centrale.

Ma la differenza architetturale è radicale, e scegliere l'approccio sbagliato per un determinato problema porta a sistemi troppo costosi, troppo fragili, o entrambe le cose.

Un sistema basato su chiamate LLM dirette ha una struttura semplice: il tuo codice chiama il modello, interpreta la risposta, agisce di conseguenza.

Il flusso è deterministico e completamente sotto il tuo controllo.

È la scelta giusta per la stragrande maggioranza dei casi d'uso AI: rispondere a domande su un dominio documentale, classificare testo, generare contenuto strutturato, riassumere informazioni.

Semplice, prevedibile, testabile con strumenti standard.

Un sistema ad agenti ha una struttura fondamentalmente diversa: il modello guida il flusso, non il contrario.

L'agente riceve un obiettivo, non una domanda. Decide quali passi eseguire, in quale ordine, con quali parametri.

L'esito non è prevedibile in anticipo perché dipende dalle decisioni del modello a runtime, che a loro volta dipendono dai risultati intermedi.

Questo rende i sistemi ad agenti potenti per problemi complessi e più difficili da debuggare e testare rispetto al codice tradizionale.

Se vuoi rendere questa differenza davvero operativa, puoi leggerla così:

Capire questa differenza serve a fare una scelta architetturale consapevole, non a scegliere la tecnologia più avanzata disponibile.

In molti casi che sembrano richiedere un agente, una pipeline classica con alcune chiamate LLM integrate funziona meglio: è più veloce, costa meno e si testa con gli strumenti normali.

Un agente vale la pena quando la capacità di adattamento è necessaria, non come default per qualsiasi integrazione AI.

Vedere il proprio sistema come "dotato di AI" perché usa un agente invece di una chiamata diretta è un errore di priorità che molti team fanno.

Il costo nascosto della scelta sbagliata

Un agente che invoca cinque funzioni per rispondere a una domanda semplice usa molto più token di una singola chiamata LLM diretta.

La storia conversazionale cresce a ogni iterazione, aumentando ulteriormente il costo.

In produzione, con centinaia di sessioni al giorno, la differenza tra scegliere agente o chiamata classica può tradursi in costi operativi molto diversi.

Prima di scegliere l'architettura, rispondi a questa domanda: il percorso di soluzione del mio problema è variabile in modo tale che non posso codificarlo esplicitamente?

Se la risposta è sì, un agente ha senso. Se i passi sono prevedibili e stabili, una pipeline tradizionale è la scelta migliore.

C'è anche un costo meno ovvio: la complessità di debugging.

In pratica, quando lavori con un agente, il debugging smette di essere lineare:

• Non segui più un flusso deterministico riga per riga
• Devi ricostruire il ragionamento del modello dai log
• Devi capire perché ha scelto un tool invece di un altro
• Devi distinguere se il problema è nel codice o nel comportamento del modello

Con il codice imperativo, sai esattamente quale riga ha prodotto un certo comportamento.

Con un agente, il debugging cambia completamente natura.

Devi ricostruire il ragionamento del modello dai log delle invocazioni, capire perché ha scelto un certo tool invece di un altro, e determinare se il problema è nel plugin, nelle istruzioni di sistema o nel modello stesso.

Questa complessità aggiuntiva deve essere compensata da un beneficio reale in flessibilità o capacità.

Se stai leggendo questa sezione con la sensazione che “ok, ora è più chiaro…” ma non sapresti ancora prendere una decisione architetturale su un progetto reale, fermati un attimo.

Perché è esattamente lì che si crea il gap.

Tra chi capisce la differenza tra LLM e agenti… e chi sa usarla per progettare sistemi che non crollano in produzione.

La verità è che nessun tutorial ti insegna questo passaggio.

Ti insegnano a usare gli strumenti. Non a ragionare da chi prende decisioni che impattano budget, stabilità e carriera.

È qui che cambia tutto.

Se vuoi smettere di essere quello che “implementa” e iniziare a essere quello che decide come costruire davvero sistemi AI, dai un’occhiata al percorso completo: Corso Programmazione con l’AI.

Non è un corso solo per imparare a usare l’AI.

È un percorso per diventare il professionista che gli altri consultano quando le scelte diventano critiche.

Perchè Semantic Kernel è diventato lo standard per gli agenti AI in .NET

Nel 2025, se avessi voluto costruire un agente AI in Python avresti avuto LangChain, LlamaIndex, AutoGen e una decina di altri framework tra cui scegliere.

In .NET, la scelta era meno ovvia.

Ma nel corso degli ultimi dodici mesi, Semantic Kernel ha consolidato una posizione dominante nell'ecosistema enterprise .NET, e ci sono ragioni concrete per questa adozione che vanno oltre il fatto che sia prodotto da Microsoft.

La prima ragione è l'integrazione con l'ecosistema Azure.

Semantic Kernel si integra nativamente con Azure OpenAI, Azure AI Search, Azure AI Foundry e Application Insights.

Per le aziende già su Azure, questo significa zero configurazione extra per autenticazione, logging e monitoring.

Non è un dettaglio: riduce settimane di lavoro di configurazione infrastrutturale che in un progetto normale vengono pagate a tariffa giornaliera.

La seconda ragione è la neutralità rispetto al provider LLM.

Lo stesso codice che gira con Azure OpenAI in produzione gira con Ollama in locale durante lo sviluppo, e potenzialmente con Claude di Anthropic o Gemini di Google se i requisiti cambiano.

L'astrazione è concreta: quando cambi provider, cambi la configurazione del kernel, non il codice dell'agente.

Per un team che deve mantenere il sistema per anni, questa flessibilità ha un valore economico reale.

La terza ragione è integrazione con la dependency injection standard di .NET.

Semantic Kernel usa IServiceCollection e il pattern builder che conosci già. I plug in ricevono dipendenze tramite costruttore come qualsiasi altro servizio. Non impone pattern architetturali diversi da quelli già usati nel progetto.

Per chi vuole approfondire la programmazione AI enterprise con Semantic Kernel, il punto di partenza giusto è esattamente questo ecosistema.

Per un team .NET senior, il framework si sente familiare dal primo giorno.

Il pacchetto Agents.Core è separato dal core proprio perché chi usa il framework solo per chiamate LLM non deve portarsi dietro il codice degli agenti.

Questa separazione riflette la filosofia del framework: ogni funzionalità avanzata è un livello opzionale sopra il core.

La struttura del progetto che scala

Separare plug in, agenti e filtri in cartelle dedicate non è un capriccio organizzativo: è la struttura che permette di aggiungere un nuovo plugin senza toccare il codice dell'agente, di modificare le istruzioni senza impattare i plugin, di aggiungere filtri di logging o sicurezza senza cambiare la logica applicativa.

Una cartella Agents/ per le definizioni degli agenti con le loro istruzioni di sistema, Plugins/ per le funzioni che gli agenti possono invocare, Filters/ per l'osservabilità e la sicurezza, Infrastructure/ per la factory del kernel: è una struttura che si capisce al primo sguardo, si mantiene nel tempo e si spiega a un nuovo membro del team in cinque minuti.

Questi dettagli fanno la differenza quando il progetto ha sei mesi e la lista dei plugin è cresciuta fino a venti elementi.

Come progettare plugin efficaci per i tuoi agenti AI

I plug in sono la parte più critica di qualsiasi agente.

Ogni errore nella loro progettazione si traduce in un agente che invoca funzioni nel contesto sbagliato, con parametri errati, oppure che non riesce a completare compiti che dovrebbe gestire senza difficoltà.

Progettare bene i plug in è la competenza che più di ogni altra separa un agente che funziona in demo da uno che regge in produzione.

Il principio fondamentale, e il più controintuitivo per chi arriva dal mondo dello sviluppo tradizionale: le descrizioni negli attributi non sono documentazione per il team di sviluppo.

Sono istruzioni per il modello LLM. Il modello le legge per decidere se e quando invocare ogni funzione.

Una descrizione vaga genera invocazioni errate. Una descrizione che spiega il contesto d'uso genera un agente affidabile.

Il parametro include esempi di formato che aiutano il modello a estrarre correttamente l'ID dal messaggio dell'utente.

Ecco cosa rende davvero efficace questo tipo di plug in:

• La descrizione spiega quando usare la funzione, non solo cosa fa
• I parametri includono esempi concreti di input
• I messaggi di errore sono pensati per l’utente finale
• Ogni invocazione viene loggata per il debugging
• Il contesto d’uso è esplicito e non ambiguo

Il messaggio di errore è scritto per l'utente finale, non per il developer. Il token di cancellazione è propagato per permettere la cancellazione in caso di timeout.

Ogni invocazione viene loggata con i parametri per il debugging.

Quante funzioni esporre a un agente

I modelli più capaci gestiscono bene liste di venti-trenta funzioni.

I modelli più economici hanno prestazioni peggiori quando la lista è troppo lunga: iniziano a confondere i tool, a invocare quelli sbagliati, a ignorare quelli pertinenti.

La regola pratica: mantieni il numero di funzioni sotto le quindici-venti per agente.

Se ne servono di più, valuta la selezione dinamica dei plugin in base al contesto della conversazione invece di averli tutti sempre disponibili.

Un errore frequente nei team che iniziano con gli agenti: esporre le API del dominio interno come plugin, con gli stessi nomi e le stesse firme usati nel codice applicativo.

Le funzioni dei plugin devono essere pensate per il modello LLM, non per il developer.

I nomi devono essere chiari in linguaggio naturale. Le descrizioni devono contestualizzare l'uso. I messaggi di ritorno devono essere comprensibili come testo semplice.

Una funzione chiamata GetOrderV2ByIdFromCrmAsync con una descrizione generica è uno scherzo per il modello.

Una funzione chiamata GetStatoOrdineAsync con una descrizione che spiega quando usarla è uno strumento preciso.

Costruire e configurare l'agente AI in .NET con Semantic Kernel

Con il kernel configurato e i plugin registrati, creare l'agente è tecnicamente semplice.

La vera complessità sta nelle istruzioni di sistema: sono la parte più importante dell'intera architettura e quasi sempre la più sottovalutata.

Definiscono il contratto comportamentale dell'agente: cosa può fare, cosa non deve fare mai, come deve comunicare, come gestire i casi limite.

Qualsiasi comportamento non specificato nelle istruzioni diventa non deterministico.

Il modello gestirà quei casi nel modo che ritiene più appropriato in base al suo addestramento, e questo raramente corrisponde a quello che vuoi in un sistema aziendale.

Istruzioni efficaci usano elenchi espliciti per permessi e vincoli, specificano il formato delle risposte quando è rilevante, includono indicazioni su come gestire le situazioni di errore e le richieste fuori scope.

Un buco nelle istruzioni è un vettore di comportamento non deterministico che si manifesta prima o poi, inevitabilmente, nel momento peggiore.

Il parametro FunctionChoiceBehavior.Auto() abilita il comportamento degli agenti: il modello decide autonomamente se e quando invocare le funzioni disponibili.

Senza questa configurazione, l'agente risponde solo con testo senza invocare nulla, comportandosi come una normale chiamata LLM.

Il MaximumAutoInvokeAttempts definisce quanti cicli di invocazione sono permessi prima che il modello debba concludere: tenerlo esplicito in produzione, non affidarsi al valore di default.

Le istruzioni che ogni agente di produzione dovrebbe avere

Un agente di produzione ha bisogno di istruzioni che coprano almeno quattro aree:

• Il contesto e il ruolo (chi è e per quale sistema lavora)
• Le capacità esplicite (cosa può fare)
• I vincoli espliciti (cosa non deve mai fare)
• Istruzioni per la gestione degli errori e dei casi limite (come comportarsi quando un tool fallisce o la richiesta è fuori scope).

Un'area non coperta genera un buco comportamentale.

I buchi comportamentali si trovano in produzione, non in fase di sviluppo.

Testare le istruzioni con una suite di scenari limite, inclusi i tentativi di iniezione di prompt, prima del rilascio è una pratica che non puo' essere saltata.

Configurare un agente è facile.

Scrivere due istruzioni, attivare l’auto invoke, collegare qualche plugin… e tutto sembra funzionare.

Poi arriva la produzione.

E lì capisci che il problema non era “farlo partire”. Era costruire qualcosa che non si rompe.

Istruzioni incomplete. Comportamenti imprevedibili. Costi che esplodono senza motivo apparente.

È qui che si divide il mondo.

Da una parte chi ha seguito tutorial. Dall’altra chi ha imparato a progettare davvero.

Se vuoi evitare mesi di tentativi, errori e sistemi instabili, e imparare un approccio che funziona anche quando il contesto diventa reale, guarda qui: Corso Programmazione con l’AI.

Perché la differenza non è sapere usare Semantic Kernel. È sapere cosa farci quando non hai più margine di errore.

La memoria degli agenti AI: contesto di sessione e persistenza tra conversazioni

La memoria di un agente AI si divide in due livelli con caratteristiche molto diverse: la storia conversazionale, che dura per la durata di una sessione, e la memoria persistente, che sopravvive tra sessioni diverse.

Capire questa distinzione e gestirla correttamente è uno dei punti dove si commettono gli errori più frequenti in produzione, con conseguenze che vanno dai costi in token fuori controllo alle violazioni di privacy.

La storia conversazionale e è un oggetto che contiene tutti i messaggi scambiati tra utente, agente e funzioni nel corso di una sessione.

È il meccanismo che trasforma una sequenza di chiamate indipendenti a un LLM in una vera conversazione con memoria del contesto.

Senza di essa, ogni messaggio è trattato come una nuova conversazione.

L'agente non ricorda nulla di quanto detto un turno prima, non può fare riferimento a informazioni fornite in precedenza, non può completare compiti multipasso che attraversano più turni di dialogo.

Il problema che emerge in produzione è che la storia cresce.

Ogni invocazione di funzione aggiunge messaggi. Ogni risposta dell'agente aggiunge messaggi.

Dopo decine di turni il contesto diventa enorme, i costi in token crescono proporzionalmente, e il rischio di superare il contesto massimo del modello diventa reale.

Per conversazioni lunghe è necessaria una strategia di riduzione consapevole.

Strategie per gestire la crescita della storia conversazionale

La strategia più semplice è la finestra scorrevole: mantieni solo gli ultimi N messaggi, eliminando i più vecchi.

Semplice da implementare, ma perde il contesto delle conversazioni molto lunghe.

Una finestra di venti-trenta messaggi è un buon punto di partenza per la maggior parte dei casi enterprise: copre conversazioni di media complessità senza lasciare il contesto crescere in modo incontrollato.

La strategia alternativa è la sintesi: prima di eliminare i messaggi più vecchi, li riassumi con una chiamata al modello e inserisci il riassunto come messaggio di sistema.

Mantiene il contesto semantico ma aggiunge il costo di una chiamata LLM extra.

Vale la pena in scenari dove le conversazioni durano ore e il contesto accumulato è criticamente importante per la qualità delle risposte.

A questo punto, la scelta tra le due strategie diventa molto più concreta:

La memoria persistente tra sessioni

Per molti casi d'uso enterprise serve qualcosa di più della storia di sessione.

Un agente che ricordi le preferenze dell'utente tra una sessione e l'altra, che conosca i documenti rilevanti per il dominio, che recuperi contesto da conversazioni passate rilevanti.

Semantic Kernel fornisce un livello di astrazione sopra i database vettoriali per salvare e recuperare ricordi tramite ricerca semantica.

Invece di una query che cerca corrispondenze esatte, cerchi per significato: una query come "come preferisce ricevere i pacchi questo cliente" restituisce risultati rilevanti anche se quei ricordi non contengono esattamente quelle parole.

La scelta del backend vettoriale dipende dall'infrastruttura esistente: Azure AI Search è una scelta naturale se lavori già in Microsoft Azure, mentre soluzioni come Qdrant o Weaviate si prestano meglio a deployment on-premises, cioè eseguite su infrastruttura propria senza dipendere da cloud esterni.

Cambiare il backend non richiede cambiare il codice dell'agente.

Per approfondire il tema della memoria semantica e il pattern di recupero e generazione aumentata, leggi il nostro articolo su AI memory e RAG per applicazioni .NET.

Per capire come gli LLM comunicano con sistemi di contesto esterni secondo lo standard emergente, leggi anche il nostro articolo sul Model Context Protocol.

Come evitare loop infiniti e comportamenti inattesi negli agenti AI

C'è un momento che quasi tutti i developer che hanno lavorato seriamente con gli agenti AI ricordano: guardi la dashboard dei costi e noti un picco anomalo.

Apri i log e trovi un agente che ha invocato lo stesso plugin sette volte consecutive, con parametri leggermente diversi ogni volta, senza mai arrivare a una risposta finale.

Il motivo, scopri dopo venti minuti di debugging, è una descrizione ambigua in una delle funzioni che ha messo il modello in un ciclo di ragionamento circolare.

Nel frattempo, il costo in token di quella singola sessione è dieci volte quello previsto.

I loop infiniti negli agenti AI non sono un'eccezione rara: sono uno dei problemi più comuni in fase di sviluppo, e uno dei più costosi quando si manifestano in produzione.

Nascono quasi sempre da questi scenari:

• L’agente non riesce a raggiungere l’obiettivo ma continua a provare
• Un plugin restituisce un errore e l’agente lo ripete senza adattarsi
• Le istruzioni di sistema non definiscono chiaramente quando fermarsi
• Le descrizioni dei tool sono ambigue e generano cicli decisionali

Il limite massimo di invocazioni è la prima linea di difesa.

Non affidarti al valore di default del framework: impostalo in modo deliberato in base al tipo di agente e alla complessità dei compiti che deve gestire.

Un agente di assistenza clienti raramente ha bisogno di più di sei-otto invocazioni per rispondere a una richiesta.

Un agente di analisi dati complessa potrebbe averne bisogno di quindici.

Imposta il limite in modo consapevole, monitora in produzione il numero medio di invocazioni per sessione, e abbassalo se vedi sessioni che lo raggiungono frequentemente senza motivo legittimo.

La seconda causa di comportamenti inattesi sono le istruzioni di sistema incomplete.

Se l'agente non sa come gestire un caso specifico, il modello improvvisa. A volte improvvisa bene.

Spesso no.

Testa sempre le istruzioni con una suite di casi limite prima del rilascio: richieste fuori scope, errori nei dati restituiti dai plugin, input malformati, richieste ambigue che potrebbero essere interpretate in due modi diversi.

Pattern per rilevare e interrompere comportamenti anomali

Oltre al limite di invocazioni, implementa un filtro di monitoraggio che tiene traccia del pattern di invocazioni nella conversazione corrente.

Se lo stesso plugin viene invocato con gli stessi parametri tre volte consecutive, l'agente è probabilmente in un ciclo.

Un filtro che rileva questo pattern e lo interrompe con un messaggio di errore esplicito è molto più utile di un timeout generico.

Permette all'agente di rispondere all'utente con un messaggio significativo invece di cadere silenziosamente in timeout.

Sanitizzazione dell'input e resistenza all'iniezione di prompt

Se gli utenti possono inserire testo libero che finisce nel contesto dell'agente, esiste il rischio di iniezione di prompt.

Input costruiti per cercare di modificare il comportamento dell'agente, farlo uscire dal suo scope, o fargli eseguire azioni non autorizzate.

Pulisci sempre l’input dell’utente prima di inserirlo nella conversazione.

Le istruzioni di sistema devono includere esplicitamente indicazioni su come l'agente deve reagire a tentativi di manipolazione.

La contaminazione del contesto nei sistemi multi-tenant merita attenzione separata: la storia conversazionale e la memoria persistente devono essere isolate per utente o per sessione.

Condividere accidentalmente contesto tra utenti diversi è una violazione di privacy grave e difficile da rilevare senza log strutturati.

Supervisione umana e sicurezza: il pattern human-in-the-loop con Semantic Kernel

Un agente AI senza limiti espliciti è come uno junior developer con accesso admin: intelligente ma pericoloso.

Non esporre mai a un agente funzioni che eseguono azioni irreversibili senza un meccanismo di approvazione umana.

Eliminare record, inviare e-mail, processare pagamenti, modificare configurazioni di sistema: queste azioni richiedono un pattern dove l'agente propone l'azione e attende conferma prima di eseguirla.

Non è una buona pratica consigliata: è un requisito non negoziabile per qualsiasi sistema in produzione che vuole essere affidabile e conforme alle normative aziendali.

Il meccanismo tecnico in Semantic Kernel per implementare questo pattern è il filtro di invocazione delle funzioni.

È una classe che intercetta ogni chiamata a un plugin prima dell'esecuzione.

Si registra nel kernel una volta sola e si applica automaticamente a tutte le funzioni, il che significa che non devi modificare il codice dei singoli plugin per aggiungere il controllo di sicurezza.

Come classificare le azioni per livello di rischio

Una tassonomia pratica per le funzioni esposte a un agente distingue tre categorie.

Le azioni di sola lettura, come recuperare dati, consultare cataloghi, fare ricerche, possono essere invocate liberamente senza approvazione.

Le azioni reversibili a basso impatto, come aggiornare preferenze, salvare bozze, creare ticket, possono richiedere solo logging senza blocco esplicito.

Le azioni irreversibili o ad alto impatto, come inviare comunicazioni, processare pagamenti, eliminare dati, modificare configurazioni, richiedono sempre approvazione umana prima dell'esecuzione.

Questa classificazione deve essere documentata, condivisa con il team e aggiornata ogni volta che si aggiunge un nuovo plugin.

Ogni funzione aggiunta al sistema va categorizzata prima del rilascio.

Non è un'attività burocratica: è la governance minima che permette di sapere cosa l'agente può fare in autonomia e cosa no, e di rispondere alle domande del management quando qualcosa va storto.

Osservabilità in produzione: log, tracce e metriche

Un agente AI in produzione senza osservabilità è come un'applicazione senza log: quando qualcosa va storto, non hai elementi per capire cosa è successo.

Semantic Kernel supporta nativamente OpenTelemetry: ogni invocazione genera span con attributi standard compatibili con Azure Monitor, Jaeger, Grafana e qualsiasi backend compatibile.

In un sistema con più agenti, il tracing distribuito è l'unico modo pratico per ricostruire il flusso completo di una conversazione.

Le metriche da monitorare in produzione sono: numero di invocazioni per conversazione, costo in token per sessione, tasso di errore dei plugin, distribuzione delle latenze.

Questi numeri servono per capire dove gli agenti si bloccano più spesso e se il costo operativo è sostenibile nel tempo.

Agenti multipli in .NET: orchestrare team di AI specializzati

Per scenari dove un singolo agente non è sufficiente, Semantic Kernel supporta i gruppi di agenti: più agenti specializzati che collaborano per raggiungere un obiettivo comune.

Ogni agente ha un ruolo specifico, un set di funzioni coerenti con quel ruolo, e istruzioni che ne definiscono il comportamento nel contesto del gruppo.

È un pattern potente, con costi operativi e complessità di gestione proporzionalmente più alti rispetto a un agente singolo.

Il pattern è particolarmente utile per pipeline di elaborazione dove i passi richiedono competenze diverse.

Un agente raccoglie e analizza dati, un secondo produce un report esecutivo, un terzo verifica la qualità dell'output.

Oppure per sistemi di revisione dove un agente genera una proposta e un secondo la critica, iterando finché il risultato soddisfa i criteri stabiliti.

Due configurazioni sono critiche per qualsiasi gruppo di agenti: la strategia di selezione, che decide quale agente parla a ogni turno, e la strategia di terminazione, che decide quando il gruppo ha completato il lavoro.

La strategia di selezione sequenziale, dove gli agenti si alternano in ordine fisso, è la più semplice e la più prevedibile.

La selezione basata su LLM, dove un modello decide quale agente è più adatto a rispondere in base al contesto, aggiunge costi e latenza senza necessariamente migliorare i risultati.

Per la maggior parte dei casi, partire con la selezione sequenziale e valutare solo in seguito se serve qualcosa di più sofisticato.

Un caso d'uso concreto: revisione del codice con due agenti specializzati

Un caso reale nel mercato italiano: revisione automatica del codice di una pull request.

Un agente analista ha accesso al codice e agli strumenti di analisi statica: identifica problemi potenziali, valuta la complessità, suggerisce refactoring.

Un agente revisore ha accesso alle linee guida di qualità e alla storia delle revisioni passate: valuta la qualità dell'analisi dell'analista, verifica che siano stati considerati sicurezza, prestazioni e testabilità, approva o richiede un approfondimento.

Il ciclo continua finché il revisore è soddisfatto o si raggiunge il limite di iterazioni.

Il punto chiave è che ogni agente ha il proprio kernel con i plugin appropriati al suo ruolo.

L'Analista non ha accesso agli strumenti del revisore e viceversa.

Questa separazione riduce il rischio che un agente invochi tool inappropriati per il suo ruolo e rende il comportamento del sistema più prevedibile.

Il costo operativo dei sistemi multi-agente

I sistemi multi-agente con cicli di revisione sono potenti ma costosi.

Ogni iterazione genera chiamate LLM multiple. In produzione, monitora il numero medio di iterazioni prima della terminazione e il costo medio per sessione.

Alcune ottimizzazioni pratiche: usa un modello più economico per l'agente che genera bozze e uno più capace solo per il revisore.

Imposta un limite rigido di due-tre iterazioni massime per contenere i costi senza sacrificare la qualita'.

I sistemi multi-agente con cicli di revisione sono lo stato dell'arte per compiti complessi, ma il loro costo operativo richiede governance esplicita: budget per sessione, metriche di utilizzo e soglie di alert fanno parte dell'architettura tanto quanto il codice.

Gli agenti multipli sono affascinanti. Finché restano su carta.

Perché quando inizi davvero a orchestrare più agenti, emergono problemi che nessun esempio semplice ti mostra: coordinamento, costi fuori controllo, decisioni incoerenti, debug quasi impossibile.

E a quel punto capisci una cosa. Non stai più “usando l’AI”. Stai progettando un sistema complesso.

E se non hai un metodo, ti si ritorce contro.

Se vuoi imparare a gestire questa complessità senza perderti, e costruire sistemi che scalano davvero (tecnicamente e professionalmente), entra qui: Corso Programmazione con l’AI.

Non per fare cose più complicate. Ma per farle in modo che funzionino quando contano davvero.

Come testare un agente AI: strategie per sistemi non deterministici

Testare un agente AI è fondamentalmente diverso dal testare codice deterministico.

Non puoi aspettarti che lo stesso input produca sempre lo stesso output: i modelli LLM hanno una componente stocastica. L'output testuale varia tra esecuzioni.

Ma puoi testare le proprietà comportamentali del sistema: l'agente invoca le funzioni giuste nelle situazioni appropriate? Non esegue mai azioni critiche senza approvazione?

Mantiene il contesto correttamente tra i turni? Risponde con un messaggio sensato quando un plugin fallisce?

La strategia più efficace è disaccoppiare il test del comportamento dell'agente dal test della logica dei plugin.

Per i plugin, gli unit test classici in C#, sono funzioni con input e output definiti, completamente deterministici.

Per l'agente, mock dei plugin e verifica che le funzioni corrette vengano invocate con parametri ragionevoli in risposta a input specifici.

Questo ti permette di isolare i problemi: se l'agente non funziona correttamente in un test, sai che il problema è nel comportamento dell'agente, non nella logica del plugin.

Il pattern è verificare che i plugin giusti siano stati invocati con parametri ragionevoli, non che l'output testuale sia identico a un valore atteso.

Il comportamento funzionale, quali funzioni vengono chiamate e con quali parametri, è molto più stabile dell'output testuale ed è verificabile in modo affidabile anche considerando la natura stocastica del modello.

Test di regressione comportamentale

Per i test di integrazione end-to-end, mantieni un set di scenari conversazionali rappresentativi con input e out come attesi, eseguiti periodicamente contro il modello reale.

Servono a rilevare regressioni comportamentali introdotte da aggiornamenti del modello LLM, modifiche alle istruzioni di sistema, o nuovi plugin che interferiscono con quelli esistenti.

Una regressione comportamentale è quando l'agente smette di fare qualcosa che faceva correttamente, o inizia a fare qualcosa che non dovrebbe, senza che il tuo codice sia cambiato.

Succede quando il provider aggiorna il modello di base, quando si aggiungono nuovi plugin che il modello preferisce a quelli esistenti in certi contesti, o quando si modificano le istruzioni di sistema per un agente senza verificare l'impatto sugli altri.

Senza una suite di test di regressione, non te ne accorgi finché arriva la segnalazione di un utente.

Questi test sono costosi in token e lenti: non devono girare a ogni build, ma almeno settimanalmente in staging e sempre prima di un rilascio in produzione.

Quando usare un agente AI e quando è la scelta sbagliata per il problema

Dopo aver visto come costruire agenti complessi, è importante fare un passo indietro.

Gli agenti AI non sono la soluzione giusta per ogni problema che coinvolge un LLM.

Usarli indiscriminatamente porta a sistemi più costosi, più lenti, più difficili da debuggare e spesso peggiori, non migliori, rispetto a soluzioni più semplici.

I segnali che un agente è la scelta giusta: il problema ha alta variabilità nei percorsi di soluzione.

I passi da eseguire dipendono dai risultati dei passi precedenti in modi non prevedibili in anticipo.

Codificare tutti i casi possibili in codice imperativo richiederebbe centinaia di rami condizionali difficilmente mantenibili nel tempo.

I segnali che un agente è eccessivo: il flusso di lavoro ha passi fissi e prevedibili.

Le operazioni sono principalmente chiamate ad API esterne senza logica decisionale complessa.

La latenza aggiuntiva introdotta dal ciclo agente-modello-plugin non è accettabile per il caso d'uso, il costo in token per sessione supera il valore del servizio erogato.

In questi casi, una soluzione più semplice funziona meglio sotto ogni dimensione: costo, velocità, affidabilità, manutenibilità.

Le alternative agli agenti per i casi più comuni

Per molti scenari che sembrano richiedere un agente, una soluzione più semplice funziona meglio.

Un sistema con chiamate LLM dirette e routing manuale basato su classificazione del testo è sufficiente per assistenza clienti con scope limitato e passi prevedibili.

Una pipeline di elaborazione con passi fissi in codice imperativo è più prevedibile e testabile per workflow deterministici.

Un sistema RAG, con recupero semantico su una base documentale e generazione della risposta, è la scelta giusta quando il problema è rispondere a domande su documenti, non eseguire azioni su sistemi.

Gli agenti aggiungono valore quando il problema richiede vera pianificazione adattiva, non quando si tratta di rispondere a domande con contesto recuperato da un database.

Confondere i due scenari è uno degli errori più comuni nei team che iniziano a lavorare con i sistemi AI.

Per un confronto tra le diverse architetture, leggi anche la nostra analisi sul vibe coding e lo sviluppo assistito dall'AI.

Il mercato degli agenti AI nel 2026 e le competenze che fanno la differenza

Il mercato italiano degli agenti AI nel 2026 ha smesso di essere quello delle sperimentazioni.

Le aziende di medie e grandi dimensioni stanno portando in produzione i primi sistemi ad agenti reali, principalmente in tre aree: automazione dell'assistenza clienti, analisi e classificazione documentale, integrazione tra sistemi legacy e nuove piattaforme cloud.

Nei settori manifatturiero, finanziario e della distribuzione, le richieste più frequenti riguardano agenti che si integrano con ERP e CRM esistenti, che rispettano requisiti di sicurezza stringenti anche con dati sensibili, e che forniscono log completi di tutte le azioni eseguite per conformità normativa.

Non è un caso che questi settori siano i più attivi: sono anche quelli con la maggiore variabilità nei processi e il maggiore costo del personale dedicato a gestire i casi eccezionali che un sistema automatico tradizionale non riesce a coprire.

Il profilo professionale che queste aziende cercano non è il data scientist che addestra modelli.

È il developer senior che sa progettare sistemi AI integrati con l'infrastruttura esistente.

Ha una conoscenza solida di .NET, comprende i pattern architetturali per sistemi distribuiti, sa valutare quando usare un agente e quando no, e ha l'esperienza per portarlo in produzione con le garanzie di affidabilità e osservabilità richieste dall'enterprise.

Il gap che separa chi sa costruire demo da chi sa costruire sistemi

Semantic Kernel è oggi lo standard de facto per gli agenti AI in ambienti .NET aziendali.

La sua adozione è cresciuta significativamente nell'ultimo anno grazie all'integrazione con Azure AI Foundry e al supporto per il protocollo MCP.

I developer che lo conoscono in profondità, non solo le basi, hanno un vantaggio concreto nel mercato attuale. Ma la conoscenza del framework da sola non è sufficiente.

Il gap più comune nei team che iniziano con gli agenti è questo: sanno costruire un prototipo che funziona in demo, ma faticano a portarlo in produzione con i requisiti di affidabilità, osservabilità sicurezza che le aziende richiedono.

La differenza non è tecnica nel senso stretto: è architetturale.

Riguarda le decisioni prese prima di scrivere la prima riga di codice: dove mettere i confini di autonomia dell'agente, come strutturare i plugin perché siano efficaci per il modello, quali metriche monitorare, come gestire i casi limite e le azioni irreversibili.

Come formarsi sugli agenti AI .NET in modo efficace

La formazione sui sistemi ad agenti richiede un approccio pratico.

Leggere la documentazione e guardare tutorial risolve il problema dei primi passi, ma non prepara a gestire i problemi reali di produzione.

I problemi reali includono comportamenti imprevisti del modello, costi fuori controllo, regressioni comportamentali dopo un aggiornamento e incidenti di sicurezza legati a iniezione di prompt o contaminazione del contesto.

Il percorso più efficace combina fondamenta architetturali solide con pratica su scenari reali che rispecchiano quelli incontrati in un progetto enterprise.

Per approfondire come Semantic Kernel si integra nell'ecosistema .NET e come strutturare un piano di adozione in un team, leggi il nostro articolo sul framework Semantic Kernel.

Vuoi imparare a progettare e deployare sistemi AI agent robusti in .NET con un approccio architetturale solido?

Scopri il percorso formativo di BestDeveloper per Architect di sistemi AI.

Se hai letto questo articolo fino in fondo, una cosa è chiara. Non sei più nella fase in cui ti basta “provare l’AI”.

Hai capito dove stanno i problemi veri. Hai visto cosa succede quando passi dalla demo alla produzione.

Hai visto quanto velocemente un sistema apparentemente semplice può diventare ingestibile.

E soprattutto hai capito questo: il vero gap non è tra chi usa l’AI e chi no. È tra chi sa costruire sistemi che reggono… e chi no.

Puoi continuare a fare tentativi. Accumularli. Sperare che prima o poi tutto torni.

Oppure puoi fare il salto.

Non quello tecnico. Quello mentale. Passare da sviluppatore che integra strumenti a professionista che progetta sistemi AI con criterio.

Se è questo il passaggio che vuoi fare, qui trovi il percorso: Corso Programmazione con l’AI.

Non è l’ennesimo corso per “imparare l’AI”.

È un percorso costruito per chi vuole smettere di essere un esecutore, e iniziare a ragionare da chi prende decisioni che impattano architettura, costi e carriera.

Se invece cerchi ancora l’ennesimo tutorial, va bene così.

Ma sappi che là fuori non pagano chi sa fare una demo. Pagano chi sa far funzionare le cose quando contano davvero.