|
Obiettivo |
Chiediti: "Quale risultato voglio raggiungere?Non: "Quali strumenti voglio utilizzare?", "Quali connettori dovrei attivare?" o "Quale tema dovrei creare?"
Descrivi chiaramente perché l'agente dovrebbe esistere, cosa dovrebbe realizzare e chi è il pubblico di riferimento. Attenzione ai risultati. Lascia che la progettazione dell'agente sia guidata dal problema.
Chiarisci:- Il problema o divario di valore
- Utenti di destinazione
- L'impatto atteso
- Cosa significa successo
Usa un formato Lavori da fare:
-
Come<utente>
-
Ho del<lavoro da fare>
-
Quindi<risultato>
|
-
Come nuovo dipendente, Devo comprendere i criteri locali delle risorse umane affinché io possa affrontare l'onboarding con sicurezza.
-
Come manager di supporto IT, devo gestire automaticamente le e-mail di supporto affinché venga ridotto il triage manuale.
|
- Iniziando con le funzionalità invece che con i risultati.
- Progettare per casi limite.
- Saltare criteri di successo misurabili.
|
|
Trigger |
Un trigger di agente è l'evento, la condizione o l'input specifico che segnala a un agente di iniziare il suo lavoro o attività. Un'azione umana o un evento automatico possono attivare il trigger.
Per saperne di più: Trova il trigger che si adatta al tuo evento. |
- Un messaggio dell'utente in chat.
- Una nuova e-mail in una casella di posta condivisa.
- Un nuovo record in un sistema.
- Un lavoro programmato o ricorrente.
|
- Gli agenti autonomi richiedono trigger espliciti. Senza di loro, l'agente non si avvia.
- Il trigger dipende da un comportamento imprevedibile dell'utente, ad esempio richiedendo all'utente di digitare una parola chiave o una frase specifica.
- Il trigger manca del contesto richiesto, ad esempio, l'agente si avvia ma non ha abbastanza metadati (ID record, identità utente) per agire efficacemente.
- I trigger si attivano più frequentemente di quanto lo scenario richieda realmente, portando a esecuzioni e consumo di risorse non necessari.
- La progettazione del trigger non prende in considerazione le quote o i limiti della piattaforma, portando gli agenti a superare le soglie di utilizzo o a fallire quando sono sotto carico.
|
|
Strumenti e integrazioni |
Definisci quali azioni l'agente deve essere in grado di compiere, non solo ciò che conosce.
Gli strumenti permettono all'agente di recuperare o aggiornare dati, chiamare API, attivare flussi di lavoro, inviare messaggi e completare operazioni transazionali. Elenca i sistemi da cui dipende l'agente e le loro limitazioni (API, modelli di autenticazione, limiti di flusso in entrata e limiti di proprietà/SLA).
Considera gli output previsti, i criteri di successo e qualità, il comportamento di fallback e la gestione degli errori. Le dipendenze spesso incidono sulla fattibilità: considerale in anticipo.
Scopri di più: Meccanismi per aggiungere strumenti agli agenti. |
- Connettore ServiceNow → ottenere i dettagli dei ticket
- Connettore Microsoft Entra ID → recupera la posizione dell'utente
- API Jira → aggiornare gli elementi di lavoro
- Connettore Outlook → rispondere alle e-mail
|
- Non registrare le azioni né memorizzare gli output per l'audit.
- Supponendo che le API siano stabili e sempre disponibili.
- Autorizzazioni eccessive per gli strumenti.
- Non definire il comportamento di fallback delle chiamate agli strumenti (nessuna validazione dell'output dello strumento, nessun fallback quando gli strumenti falliscono, nessun percorso di escalation).
- Limiti di flusso in entrata o limitazione delle richieste.
- Mancanza della mappatura delle dipendenze (chi possiede ogni API, qual è l'accordo di livello di servizio).
- Non validare le precondizioni prima di eseguire le azioni.
|
|
Canali |
Un canale è la piattaforma o interfaccia specifica dove il tuo agente è implementato e interagisce con gli utenti.
Il canale determina anche le aspettative degli utenti riguardo alla latenza, alla gestione dei turni e all'esperienza complessiva. |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- Chat Web o interfacce vocali
|
- Scegli i canali in base alla comodità o alla semplicità di implementazione, anziché a come e dove gli utenti effettivamente lavorano.
- Supponendo che gli utenti si adattino al canale dell'agente, invece di raggiungerli dove si trovano già.
- Dai priorità alla fattibilità tecnica rispetto all'esperienza utente, con conseguente bassa adozione anche quando l'agente funziona correttamente.
- Progettazione di "chat-first" quando il canale reale è basato su posta elettronica o su flusso di lavoro (creazione di un'esperienza utente conversazionale quando il supporto avviene effettivamente tramite Outlook; dimenticando che la posta elettronica è basata su turni, non conversazionale)
- Ignorare i vincoli specifici del canale (Outlook richiede risposte complete, non domande di chiarimento; Teams supporta le Schede adattive, mentre l'e-mail non le supporta)
|
|
Conoscenza e dati |
Documenta le informazioni di cui l'agente ha bisogno per ragionare e la posizione in cui la conoscenza o i dati sono attualmente disponibili. Considera la qualità e la freschezza dei dati, la distinzione tra contenuti strutturati e non strutturati, e le limitazioni di accesso e permessi.
La preparazione dei dati è una delle fonti più comuni di fattori di blocco nelle fasi avanzate, se non viene affrontata precocemente. |
- Documenti
- Database
- Siti Web
- Knowledge Base
- Sistemi interni o esterni
|
- Governance dei dati insufficiente o incoerente. Quando proprietà, frequenza di aggiornamento e processi di aggiornamento non sono definiti, i dati diventano rapidamente obsoleti o contraddittori.
- Confondere "documenti" con "conoscenza". Indicare grandi archivi di documenti come fonte di verità senza considerare se quei documenti siano aggiornati, ben strutturati o etichettati in modo coerente.
- Le fonti delle informazioni si contraddicono. Più versioni di un criterio, procedura o dataset portano l'agente a ricevere istruzioni in conflitto.
- I permessi e i controlli di accesso non sono esplicitamente progettati. Contenuti sensibili vengono esposti involontariamente, oppure l'agente fa riferimento a conoscenze a cui gli utenti finali non hanno accesso.
- Espandere le fonti delle informazioni senza validare i confini di sicurezza, per cui gli agenti condividono troppo o falliscono quando l'accesso è limitato.
|
|
Flussi e orchestrazione |
Definire come il lavoro è strutturato e sequenziato all'interno dell'agente: quando utilizzare flussi o argomenti deterministici, quando affidarsi all'orchestrazione e quando è necessario il coinvolgimento umano. L'obiettivo è un comportamento prevedibile, un'automazione sicura e un'escalation chiara.
Quando utilizzare flussi o argomenti:- Raccolta dati a più passaggi
- Risoluzione guidata dei problemi o alberi decisionali
- Processi guidati dalla conformità o dai criteri
- Azioni ad alto impatto o irreversibili
Gli argomenti sono il meccanismo principale della logica deterministica.
Definisci:- Cosa può fare l'agente in autonomia
- Cosa richiede approvazione, revisione o sostituzione umana
- Quando l'agente deve eseguire l'escalation o rinviare
- Come il feedback umano viene integrato nel processo di miglioramento
|
- Agente Ask-Me-Anything: flussi deterministici ridotti al minimo; si affida principalmente all'orchestrazione e al ragionamento generativo.
- Agente autonomo: utilizza flussi o argomenti per assicurare la sequenza, le validazioni e le barriere di sicurezza nei passaggi critici.
- Flussi di approvazione: l'agente prepara il contesto e le raccomandazioni; gli utenti approvano o modificano le azioni ad alto impatto.
|
- Sovrastrutturare i flussi, limitando la flessibilità e facendo risultare l’agente rigido o fragile.
- Flussi poco strutturati riducono l'affidabilità e rendono i risultati imprevedibili.
- Non utilizzare esplicitamente argomenti per la logica deterministica, portando a comportamenti ad hoc o incoerenti.
- Confondere le responsabilità tra essere umano e agente, con conseguenti percorsi di escalation poco chiari.
- Sovraccaricare le persone con approvazioni per azioni a basso rischio, creando colli di bottiglia e scoraggiando l’uso dell’agente.
- Agenti che agiscono senza confini chiari di "non agire", soprattutto in scenari limite o ad alto rischio.
|
|
Istruzioni e comportamento |
Le istruzioni definiscono:- Il ruolo e le responsabilità dell'agente
- Come ragiona e risponde
- Quando e come dovrebbe utilizzare conoscenza, strumenti o altri agenti
- La sequenza di azioni da seguire
- Tono, confini e regole di sicurezza
Istruzioni chiare connettono la conoscenza, gli strumenti e i flussi in un sistema coerente e prevedibile.
Scopri di più: Configura istruzioni di alta qualità per l'orchestrazione generativa e Scrivi istruzioni efficaci per agenti dichiarativi. |
- Ruolo e ambito: "Sei l'Agente IT di Supporto E-mail responsabile della lettura dei messaggi in arrivo nella casella di posta, dell'estrazione dei numeri dei ticket e della risposta con informazioni validate da ServiceNow."
- Sequenza operativa: "Passaggio 1: Controlla la Knowledge Base per un criterio esistente o un problema noto." Passaggio 2: Se le informazioni non vengono trovate o sono incomplete, utilizza lo strumento ServiceNow per recuperare i dettagli del ticket. Passaggio 3: Se i dati necessari sono ancora mancanti, rispondi utilizzando un modello "Non lo so" ed esegui l'escalation del caso.
- Regole per l'uso degli strumenti: «Valida sempre gli ID estratti con una chiamata allo strumento prima di usarli nelle risposte.»
- Gestione degli errori: "Se le informazioni non sono disponibili o la chiamata a uno strumento non riesce, non fare supposizioni." Rispondi con una chiara limitazione e il prossimo passaggio.
|
- Le istruzioni sono troppo vaghe. Ad esempio, "Aiutare gli utenti con problemi di supporto" non definisce l'ambito, i limiti o le azioni consentite.
- Non è chiaro quando utilizzare la conoscenza, gli strumenti o altri agenti, il che può portare a comportamenti incoerenti o inefficienti.
- Le istruzioni non definiscono la sequenza delle azioni, portando l'agente a combinare conoscenza e output degli strumenti in modi imprevedibili.
- Regole di utilizzo degli strumenti non definite esplicitamente, che possono portare a chiamare gli strumenti inutilmente o a non usarli affatto, oppure a mescolare in modo inatteso conoscenze e output degli strumenti.
- Istruzioni in conflitto, come "fai sempre domande di chiarimento" e "rispondi solo con risposte finali".
- Nessuna direttiva esplicita su cosa evitare, come modificare dati sensibili, condividere identificatori interni o fornire consulenza legale o HR senza fonti verificate.
|
|
Architettura e composizione degli agenti |
Utilizza gli agenti multipli quando:
- I domini sono grandi o distinti
- La responsabilità varia tra i team
- L'accesso o le autorizzazioni variano
- È richiesto ragionamento specializzato
La delega migliora la modularità, la chiarezza e la manutenibilità nel lungo termine.
Altre informazioni: Esplorare i pattern di orchestrazione multi-agente. |
- Un agente principale delega la ricerca dei ticket a un agente IT.
- Un agente della conoscenza esegue la verifica della qualità dei documenti.
- Un agente di routing decide quale agente esperto chiamare.
|
- Sovradelega (troppi agenti)—ad esempio, creare un agente separato per ogni piccola attività—può portare a una proliferazione architettonica e rendere difficile la manutenzione, il debugging, la protezione o l'aggiornamento degli agenti.
- Delegazione insufficiente (un agente unico e molto grande)—ad esempio, un singolo agente che si occupa di rispondere a domande HR, consultare ticket IT, gestire la risoluzione dei problemi e creare ordini di acquisto e segnalazioni—può portare a un agente monolitico e fragile, impossibile da gestire.
- Confini di delega indefiniti. Ad esempio, l’agente principale non sa quando effettuare il passaggio di consegne, gli agenti figlio non sanno quali input aspettarsi oppure le responsabilità si sovrappongono (due agenti cercano entrambi i ticket IT).
|
|
Governance e gestione dei rischi |
Definisci le modalità di governance, sicurezza e monitoraggio dell'agente per garantire che si comporti in modo responsabile, sicuro e prevedibile durante tutto il suo ciclo di vita.
Questa definizione include il controllo degli accessi, i permessi d'azione, i meccanismi di sicurezza, la responsabilità e il monitoraggio continuo per gestire sia i rischi operativi che quelli legati all'IA fin dal primo giorno.
Per saperne di più: Definisci i requisiti di governance e Applica i principi di IA responsabile. |
- Modello di autenticazione e accesso: l'agente utilizza l'identità utente per recuperare solo i dati che l'utente è autorizzato a vedere, mentre le identità di sistema sono riservate a operazioni di servizio chiaramente definite.
- Autorizzazioni e protezioni delle azioni: l'agente può aggiornare le note di lavoro o redigere risposte, ma non può eseguire azioni irreversibili (come chiudere ticket o inviare comunicazioni esterne) senza approvazione.
- Protezione dei dati e dei contenuti: Informazioni sensibili o regolamentate vengono rilevate e bloccate dalla condivisione o dall'utilizzo tramite le protezioni della piattaforma (es.prevenzione della perdita di dati o filtri di sicurezza).
- Registrazione, audit e tracciabilità: tutte le azioni dell'agente, le chiamate agli strumenti, i rifiuti e le escalation vengono registrati e sono verificabili a fini di conformità e revisione.
- Proprietà operativa: L'agente ha un proprietario, uno sponsor e un amministratore operativo definiti, con permessi e comportamenti riesaminati regolarmente.
|
- Definire troppo tardi la governance e i controlli del rischio, causando blocchi nell'implementazione o ritardi in produzione.
- Concedere troppi permessi agli agenti "per comodità", aumentando il rischio di esposizione dei dati o azioni indesiderate.
- Agenti con permessi insufficienti, causando errori durante l'esecuzione quando i sistemi o i dati necessari risultano inaccessibili.
- Non integrare le considerazioni di intelligenza artificiale responsabile nelle decisioni di governance.
- Governance operativa debole, come l'assenza di un proprietario chiaro, nessun piano di monitoraggio o nessun processo definito per la risposta agli incidenti.
- Non monitorare il comportamento dell'agente dopo lo sviluppo, supponendo che le misure di sicurezza siano sufficienti.
|
|
Valutazione e ottimizzazione |
Definisci test che simulano scenari reali per misurare accuratezza, rilevanza e qualità delle risposte dei tuoi agenti. Fornisci una risposta attesa e illustra come la risposta dell'agente si allinea alla tua o a quella standard.
Pianifica come misurare e migliorare le prestazioni:
- Accuratezza e rilevanza
- Risparmio di tempo o efficienza
- Adozione e utilizzo
- Segnali di soddisfazione e fiducia
- Qualità delle citazioni
- Conformità alle autorizzazioni
- Rilevamento di informazioni errate
- Comportamento delle domande di chiarimento
Definire quale telemetria raccogliere:
- Chiamate di strumenti
- Azioni agente
- Errori e tentativi
- Feedback degli utenti
Considera la valutazione come parte della progettazione, non come un ripensamento. Scopri di più: Progettare e implementare la valutazione degli agenti. |
- Verifica che la ricerca dei ticket restituisca lo stato corretto e non uno obsoleto.
- Verifica che i collegamenti delle citazioni puntino a contenuti attuali approvati.
- Verifica che l'agente si rifiuti di fornire informazioni sul ticket di un altro utente.
- Verifica se l'agente inventi un numero di ticket o un articolo della Knowledge Base.
- Misura il numero di e-mail elaborate dall'agente autonomo ogni giorno e la percentuale di utenti che scelgono l'agente rispetto ai canali manuali.
|
- Eseguire le valutazioni troppo tardi (dopo la distribuzione).
- Nessuna baseline o benchmark.
- Valutazioni non legate a scenari reali.
- Nessuna rilevazione di regressione.
- Nessuna valutazione su più turni.
- Nessun valutatore per la qualità dell'uso degli utensili.
- Verificare solo i "percorsi ideali".
- Lacune di telemetria.
|
