IA agentica spiegata: quando un sistema di IA può pianificare, usare strumenti e agire

L'IA agentica è un sistema di IA in cui un modello può perseguire un obiettivo attraverso più passaggi decidendo cosa fare successivamente, utilizzando strumenti o altre capacità, osservando i risultati, aggiornando il proprio stato di lavoro e continuando fino a raggiungere una condizione di arresto. Il modello da solo non è l'agente. Un agente utilizzabile necessita anche di un runtime o harness che gestisca contesto, esecuzione degli strumenti, stato, permessi, approvazioni, errori e il ciclo tra decisioni e osservazioni.

Cosa significa realmente IA agentica

Il passaggio importante dall'IA generativa ordinaria all'IA agentica è il controllo sul processo. Un normale assistente può rispondere a una domanda usando il contesto che riceve. Un agente può decidere che rispondere richiede passaggi aggiuntivi: ispezionare un file, cercare in un repository, interrogare un'API, chiedere chiarimenti, eseguire un test, aggiornare un ticket, delegare un sotto-compito o riprovare dopo un'azione fallita.

Ciò non richiede autonomia illimitata. Un agente può operare all'interno di un sandbox ristretto, sotto permessi rigorosi, con approvazione richiesta prima di ogni azione consequenziale. Il sistema è comunque agentico se il modello sceglie dinamicamente tra i passaggi successivi consentiti.

L'architettura quindi conta più dell'etichetta. "Agente" dovrebbe descrivere un comportamento del sistema: processo decisionale iterativo guidato dal modello su strumenti, stato e feedback — non semplicemente un chatbot con un prompt più grande.

L'esempio più semplice

Supponiamo che uno sviluppatore chieda a un sistema di IA: "Trova perché la suite di test fallisce e correggi il bug." Una singola chiamata al modello potrebbe solo suggerire probabili cause dal testo che gli è stato fornito.

Un sistema di coding agentico può ispezionare il repository, cercare il test fallito, leggere i file rilevanti, proporre una modifica, modificare il codice, eseguire il test, osservare il fallimento, rivedere l'implementazione ed eseguire nuovamente il test.

La parte agentica non è semplicemente che esistono strumenti shell e file. È che il modello può usare il feedback ambientale per scegliere il passaggio successivo invece di seguire una sequenza completamente predefinita.

Dove si ferma l'esempio semplice

Non ogni sistema di IA multi-fase è ugualmente agentico. Un workflow può utilizzare diverse chiamate LLM e strumenti mentre ogni passaggio è predeterminato nel codice. Un altro sistema può lasciare che il modello decida quale strumento chiamare, in quale ordine, quante volte e quando fermarsi.

Entrambi possono essere utili. La differenza è dove risiede il controllo. I workflow predefiniti mettono più controllo nel codice dell'applicazione. Gli agenti spostano più decisioni tattiche di processo nel ciclo modello/runtime.

Agente vs workflow

Anthropic separa esplicitamente questi due pattern: i workflow orchestrano modelli e strumenti attraverso percorsi di codice predefiniti, mentre gli agenti lasciano che i modelli dirigano dinamicamente i propri processi e l'uso degli strumenti. Non è l'unica terminologia possibile, ma è un confine architetturale utile.

Il comportamento agentico è uno spettro, non un'etichetta binaria

Chiamare "agente" ogni sistema sopra descritto può oscurare importanti differenze operative. Più forte è il controllo del modello su sequenza, durata e azioni, più importanti diventano isolamento del runtime, permessi, tracciamento, condizioni di arresto e valutazione della traiettoria.

L'architettura minima di un sistema agentico

Un modello non è un agente

Un modello linguistico produce output da input. Non possiede di per sé un filesystem, non esegue un comando shell, non mantiene uno stato del compito durevole, non applica permessi né si richiama automaticamente.

Queste capacità provengono dal runtime circostante. Lo stesso modello può comportarsi come un semplice modello di chat in un'applicazione e come motore decisionale all'interno di un ciclo di agente in un'altra.

L'uso degli strumenti è centrale — ma il solo uso degli strumenti non rende un agente

Gli strumenti permettono al modello di acquisire informazioni e influenzare sistemi esterni. Esempi includono letture da database, operazioni su file, esecuzione di shell, ricerca web, controllo del browser, chiamate API, aggiornamenti di ticket o agenti specialisti delegati.

Una singola chiamata al modello può usare uno strumento e rimanere comunque una risposta limitata assistita da strumenti, piuttosto che un agente di lunga durata. Il comportamento agentico appare quando le osservazioni degli strumenti alimentano un ciclo adattivo in cui il modello sceglie cosa fare dopo.

La progettazione degli strumenti è importante perché gli strumenti sono il contratto tra il ragionamento del modello e la realtà esterna. Strumenti ambigui o sovrapposti creano errori di instradamento; output grandi e non strutturati inquinano il contesto; strumenti ampi con effetti collaterali aumentano il raggio d'impatto.

Capacità, permesso e autorità degli strumenti sono diversi

Questi livelli vengono spesso collassati nei prototipi. Un modello vede uno strumento di rimborso e quindi sembra in grado di emettere rimborsi. In produzione, lo strumento dovrebbe comunque validare account, utente, transazione, importo, policy e condizioni di approvazione indipendentemente dalla richiesta del modello.

Il runtime o harness è il sistema di esecuzione effettivo

L'attuale documentazione sugli agenti di OpenAI rende esplicita la distinzione del runtime. Runtime diversi possono gestire orchestrazione, stato, strumenti, sandbox ed esecuzione in luoghi diversi, mentre il modello rimane solo una parte del sistema.

L'Agents SDK descrive un ciclo che chiama ripetutamente il modello corrente, ispeziona l'output, esegue gli strumenti o i passaggi richiesti e continua finché il modello non restituisce una risposta finale o un altro punto di arresto reale.

Ciò significa che le decisioni sull'architettura dell'agente includono dove viene eseguita l'orchestrazione, dove risiede lo stato, chi esegue gli strumenti, quale sandbox contiene gli effetti collaterali e chi gestisce tentativi, timeout e ripristinabilità.

La pianificazione è utile, ma un piano esplicito non è necessario

Gli agenti sono spesso descritti come sistemi che "pianificano". In pratica, la pianificazione può essere esplicita o implicita. Un agente può prima produrre un piano visibile a più passaggi, oppure può scegliere un'azione successiva alla volta e rivederla dopo ogni osservazione.

Per attività altamente incerte, una pianificazione a breve termine può essere più sicura perché l'ambiente può invalidare un piano lungo. Il requisito architetturale è la capacità di scegliere e rivedere le azioni in base all'obiettivo, allo stato corrente e alle nuove evidenze.

Il feedback ambientale è ciò che rende utile il ciclo

Un agente diventa operativamente significativo quando può osservare se la sua azione ha funzionato. L'output degli strumenti, i risultati dei test, le risposte API, lo stato del filesystem, lo stato del browser e i record applicativi forniscono evidenze esterne che il sistema può usare per rivedere la sua decisione successiva.

La guida sugli agenti di Anthropic enfatizza questo ciclo di feedback: gli agenti usano strumenti, ottengono la verità di base dall'ambiente, valutano i progressi e continuano o richiedono input umano.

Lo stato dell'agente non è la stessa cosa del contesto del modello

Un'attività di lunga durata può richiedere uno stato che non può o non dovrebbe rimanere nel contesto del modello: ID attività, checkpoint, artefatti, approvazioni, identificatori di oggetti esterni, contatori di tentativi e stato del flusso di lavoro.

Il runtime può preservare questo stato durevole al di fuori della finestra del modello e ricostruire il contesto necessario per il passaggio successivo. Questo mantiene il contesto visibile al modello focalizzato, mantenendo continuità e ripristinabilità.

La memoria è opzionale, non la definizione di un agente

Un agente può operare con successo senza memoria a lungo termine se l'attività completa rientra in una singola esecuzione limitata. La memoria diventa utile quando le informazioni devono persistere tra sessioni, attività o lunghi orizzonti di esecuzione.

RAG, memoria, stato e contesto risolvono problemi diversi. Trattare un database vettoriale come "la memoria dell'agente" o la cronologia delle conversazioni come "la macchina a stati" di solito nasconde importanti confini di ciclo di vita e autorità.

L'ingegneria del contesto diventa dinamica negli agenti

Ogni chiamata a uno strumento può produrre nuovo contesto. Ogni passo può anche rendere obsolete le informazioni precedenti. Un runtime per agenti robusto, quindi, ricostruisce o cura il contesto man mano che l'esecuzione procede, invece di riprodurre tutto indefinitamente.

Definizioni degli strumenti, stato del compito, evidenze recuperate, osservazioni e memoria competono tutti per l'attenzione del modello. Gli agenti di lunga durata necessitano di riduzione, compattazione o caricamento just-in-time affinché il contesto rimanga rilevante per la decisione corrente.

Gli strumenti di lettura e gli strumenti con effetti collaterali hanno rischi diversi

L'essere umano nel ciclo è un meccanismo di controllo, non l'opposto dell'IA agentica

Un agente non smette di essere agentico perché un essere umano approva passi consequenziali. Il modello può comunque ispezionare, ragionare, cercare e preparare un'azione in autonomia, mentre il runtime richiede la conferma umana prima dell'esecuzione.

L'attuale guida alla sicurezza degli agenti di OpenAI raccomanda esplicitamente approvazioni per le operazioni degli strumenti in flussi di lavoro a rischio più elevato. Allo stesso modo, Anthropic sottolinea l'importanza di checkpoint e giudizio umano quando gli agenti incontrano ostacoli o decisioni consequenziali.

La domanda architetturale utile non è “umano o autonomo?” ma quali decisioni possono essere delegate, quali richiedono revisione e quali devono rimanere deterministiche?

Gli agenti necessitano di condizioni di arresto esplicite

Il recupero fa parte del comportamento dell'agente

Gli agenti operano in ambienti che falliscono: le API vanno in timeout, i file cambiano, le credenziali scadono, le pagine web si spostano e gli strumenti restituiscono output malformati. Un sistema agentico utile necessita quindi di un comportamento di recupero, non solo di un ciclo di strumenti a percorso felice.

Il recupero può includere tentativi ripetuti con limiti, la scelta di un altro strumento, la rilettura dello stato corrente, la richiesta all'utente, il rollback di un'azione parziale o l'escalation a un essere umano.

Anche i tentativi ripetuti necessitano di consapevolezza dell'idempotenza. Ripetere una lettura è di solito a basso rischio; ripetere un pagamento o l'invio di un messaggio può creare effetti collaterali duplicati.

L'IA agentica non richiede più agenti

Un singolo agente con un insieme chiaro di strumenti è spesso più semplice e più facile da valutare rispetto a un'architettura multi-agente. Più agenti sono utili quando la specializzazione migliora materialmente l'isolamento degli strumenti, l'isolamento delle policy, la chiarezza dei prompt, la proprietà o la leggibilità delle tracce.

L'attuale guida all'orchestrazione di OpenAI raccomanda esplicitamente di iniziare con un solo agente quando possibile e di aggiungere specialisti solo quando il contratto o il confine di proprietà cambia materialmente.

I sistemi multi-agente aggiungono nuovi problemi: qualità della delega, contesto duplicato, stato in conflitto, semantica del passaggio di consegne, identità, costo e gestione dei guasti distribuiti.

I protocolli degli agenti sono livelli di interoperabilità, non l'agente stesso

Protocolli come MCP e A2A possono rendere interoperabile un'architettura di agenti, ma non creano da soli il ciclo dell'agente. MCP può esporre strumenti e risorse. A2A può connettere agenti implementati in modo indipendente. L'applicazione necessita comunque di runtime, autorizzazione, stato, valutazione e logica di dominio.

Ecco perché la capacità del protocollo deve rimanere separata dall'autorità di business. Scoprire uno strumento tramite MCP non prova che il principal corrente sia autorizzato a usarlo. Ricevere un'attività tramite A2A non prova che l'agente remoto possa eseguire ogni azione richiesta.

La traiettoria fa parte dell'affidabilità dell'agente

Una risposta finale non è una prova sufficiente per un sistema agentico perché un agente può raggiungere il risultato corretto attraverso un percorso non sicuro o non valido. Può usare uno strumento non autorizzato, saltare un controllo richiesto, ripetere un effetto collaterale, basarsi su uno stato obsoleto o riuscire accidentalmente.

La valutazione necessita quindi di tracce di esecuzione: decisioni, chiamate agli strumenti, approvazioni, osservazioni, cambiamenti di stato e esito finale. Le attuali linee guida di sicurezza di OpenAI raccomandano valutatori di tracce ed eval; anche le linee guida di Anthropic del 2026 sulla valutazione degli agenti trattano le traiettorie multi-turno con strumenti come oggetti di valutazione di primaria importanza.

La domanda più forte sull'affidabilità è: l'agente ha raggiunto un esito accettabile attraverso una traiettoria accettabile, recuperabile e verificabile?

I sistemi agentici aumentano la superficie di sicurezza

L'osservabilità degli agenti deve seguire il ciclo

L'osservabilità tradizionale dei servizi registra richieste, latenza ed errori. L'osservabilità degli agenti necessita di un modello di esecuzione aggiuntivo: quale agente era attivo, quale versione del modello ha preso la decisione, quale contesto era disponibile, quale strumento è stato selezionato, quali argomenti sono stati inviati, quale risultato è tornato e perché l'esecuzione si è fermata.

Per i sistemi sensibili, le tracce stesse richiedono controllo degli accessi e policy di conservazione perché prompt, output degli strumenti e artefatti possono contenere dati riservati.

Come valutare un sistema agentico

Quando un agente è appropriato

Un buon default è iniziare con la soluzione più semplice che funziona e aumentare la complessità agentica solo quando la flessibilità produce un valore misurabile. Gli agenti scambiano prevedibilità, latenza e costo con l'esecuzione adattiva.

Evidenza dell'implementazione originale

Aaasaasa AI Client: modello, runtime e permessi sono separati

Aaasaasa AI Client separa esplicitamente agente/client, provider, modello, posizione del runtime e permessi. La sua documentazione architetturale tratta i permessi come policy centrale di strumenti/workspace piuttosto che come proprietà del modello.

La stessa applicazione può esporre Direct Chat senza strumenti di filesystem o shell, mentre un runtime Codex opera sotto un workspace e un profilo di permessi selezionati. Questo dimostra un confine architetturale agentico fondamentale: cambiare la superficie del runtime/strumenti cambia ciò che il sistema può fare anche quando l'accesso al modello rimane disponibile.

Il repository distingue anche un runtime Codex locale dalla posizione del modello: un runtime locale può chiamare un modello cloud. Questo previene l'errore comune di equiparare "l'agente gira localmente" con "l'inferenza è locale".

L'implementazione disabilita i percorsi di esecuzione incorporati le cui semantiche di approvazione non soddisfano il modello di permessi richiesto. Questo supporta il principio secondo cui la capacità dell'agente non dovrebbe aggirare l'autorizzazione del runtime semplicemente perché un framework sottostante può eseguire strumenti.

Source of Truth Research Engine: fasi di ricerca agentica delimitate

Il Source of Truth Research Engine utilizza una pipeline di ricerca delimitata: scopri → acquisisci → estrai → verifica → contraddici → sintetizza. I lavori di ricerca possono essere eseguiti tramite un runtime AI mentre evidenze, fonti, affermazioni e contraddizioni rimangono in un archivio persistente esterno.

Questo è intenzionalmente più controllato di un agente di ricerca autonomo non vincolato. Le fasi forniscono guardrail su quale tipo di lavoro dovrebbe avvenire successivamente, consentendo comunque una ricerca guidata dal modello all'interno di ogni compito delimitato.

Questa distinzione è un'evidenza utile per la progettazione di agenti: l'autonomia può essere collocata all'interno di un involucro di consegna strutturato piuttosto che applicata uniformemente all'intero processo.

Modalità di fallimento comuni dell'AI agentica

Idee sbagliate comuni

Una sequenza pratica di progettazione di agenti

Checklist per l'architettura di AI agentica

Casi limite e limitazioni

Alcuni sistemi sono “agentici” solo in un senso ristretto di instradamento: il modello seleziona uno specialista o uno strumento e poi il resto del flusso di lavoro è deterministico. Questo può comunque essere utile, ma non dovrebbe essere descritto come equivalente a un agente autonomo di lunga durata.

I domini altamente consequenziali possono intenzionalmente limitare l'autonomia dell'agente. Un sistema di AI può esaminare prove, preparare raccomandazioni e compilare moduli strutturati mentre un umano rimane l'unico attore autorizzato a finalizzare la transazione.

Alcuni ambienti sono ben adatti agli agenti perché il feedback è oggettivo. Gli agenti di programmazione possono eseguire test; gli agenti di infrastruttura possono ispezionare metriche; gli agenti di dati possono validare i risultati delle query. I domini aperti con feedback debole richiedono una valutazione più cauta.

Un agente può operare interamente in locale, interamente tramite servizi cloud gestiti o in un'architettura ibrida. Il comportamento agentico descrive il flusso di controllo, non la posizione di hosting.

Il termine “ragionamento” non dovrebbe essere usato come prova che il processo interno dell'agente sia corretto. L'assicurazione di produzione dovrebbe basarsi su input, azioni, output, stato e valutazione osservabili piuttosto che su affermazioni non verificabili su un ragionamento nascosto.

Cosa cambierebbe questa risposta?

Le API dei fornitori e i framework per agenti continueranno a evolversi, ma il confine architetturale è stabile: un modello propone decisioni, un runtime gestisce il ciclo, gli strumenti si connettono all'ambiente, i permessi limitano le azioni e le osservazioni esterne determinano ciò che è effettivamente accaduto.

Man mano che i modelli diventano più affidabili, i sistemi possono delegare in sicurezza orizzonti più lunghi o comportamenti di recupero più complessi. Man mano che la verifica e l'autorizzazione a runtime migliorano, alcuni passaggi di approvazione possono diventare automatizzati. Questi sono cambiamenti nel livello di autonomia, non cambiamenti nei livelli fondamentali di responsabilità.

L'architettura raccomandata cambia anche in base alle conseguenze. Un agente di ricerca che legge solo fonti pubbliche può tollerare controlli diversi da un agente che scrive configurazioni di produzione o sposta denaro.

Conoscenza canonica correlata

L'AI agentica si colloca sopra diversi livelli prerequisiti: l'ingegneria del contesto determina ciò che il modello vede; l'architettura della Fonte di Verità determina quali informazioni sono autorevoli; il recupero fornisce prove esterne; l'architettura runtime determina cosa può essere eseguito.

I nodi a valle includono tool calling, MCP, A2A, identità dell'agente, permessi, auditabilità, human-in-the-loop, orchestrazione, memoria e sistemi multi-agente.

L'articolo sullo stack di protocolli dovrebbe quindi essere letto dopo il concetto di base di agente: i protocolli standardizzano i confini attorno agli agenti; non definiscono il comportamento agentico stesso.

Domande frequenti

Glossario

Conclusione

L'IA agentica non è semplicemente un modello più intelligente o un chatbot con più strumenti. È un'architettura di sistema in cui un modello partecipa a un ciclo di controllo iterativo: decidere, agire, osservare, aggiornare e continuare.

Il modello fornisce un processo decisionale flessibile, ma il runtime circostante deve possedere la realtà dell'esecuzione: autorizzazioni, accesso agli strumenti, stato, approvazioni, tentativi, budget, condizioni di arresto, tracciamento e verifica.

Il principio di progettazione più utile è quindi: delegare la scelta tattica al modello solo all'interno di confini tecnici e aziendali espliciti. La capacità agentica diventa capacità produttiva solo quando autonomia, autorità e prove rimangono separabili.

Fonti primarie e linee guida attuali

Le fonti seguenti supportano le attuali distinzioni architetturali relative ad agenti, flussi di lavoro, cicli, strumenti, orchestrazione, sicurezza e valutazione. Le sezioni del progetto sono prove di implementazione originali e sono esplicitamente limitate a ciò che i repository dimostrano.