L’asse che separa le tre categorie: chi avvia e che cosa produce

La distinzione non riguarda la sofisticazione del modello. Si legge su due assi: chi avvia l’esecuzione (una persona oppure un evento di sistema) e che cosa lascia dietro di sé il turno (una risposta oppure un effetto su un sistema di record). Un prompt and response agent è avviato da un messaggio e produce una risposta. Un task agent è avviato da una richiesta ma produce una scrittura, una chiamata API, un record. Un autonomous agent non aspetta nessuno: parte da un evento e produce un effetto.

Qui l’esame piazza la sua trappola preferita. L’autonomia è una proprietà dell’innesco, non dell’intelligenza: un trigger a ricorrenza che chiama un agent flow deterministico è autonomo pur senza alcuna decisione generativa, mentre un agente con orchestrazione generativa che risponde in chat resta un agente avviato dall’utente. Il verso opposto vale altrettanto: in Microsoft Copilot Studio gli event trigger sono disponibili solo per gli agenti con generative orchestration attiva, quindi non si può progettare un agente autonomo restando sull’orchestrazione classica a topic. Chi legge lo scenario cercando la parola “AI” invece della frase che dice chi preme il pulsante sbaglia la risposta.

Prompt and response agent: il turno di conversazione come unità di progetto

Il perimetro di progettazione qui è il dialogo. In Copilot Studio si combinano topic, system topic (saluto, fallback, escalation, fine conversazione, disambiguazione su più topic corrispondenti, gestione errori), condition node con logica AND/OR e, quando serve, formule Power Fx, più il nodo Generative Answers, noto anche come NLU Boost, che risponde attingendo a knowledge source pubbliche, SharePoint, Dataverse o connettori quando nessun topic corrisponde. Accanto ai topic esistono i prompt riutilizzabili costruiti nel prompt builder, che si usano come tool di un agente, nodo di un flusso o dentro un’app.

Il criterio di scelta è la prevedibilità richiesta: dove la risposta deve essere identica ogni volta si progetta un topic, dove la varietà delle domande è aperta si progetta il grounding. Attenzione a non confondere i prompt agents di Microsoft Foundry con questa categoria: in Foundry “prompt agent” indica un agente definito solo da configurazione (istruzioni, modello, tool) ed eseguito dalla piattaforma, contrapposto agli hosted agents che impacchettano codice proprio. È un asse diverso — chi esegue il runtime — non una tassonomia di comportamento.

Task agent: obiettivo delimitato, tool espliciti, vincoli tecnici veri

Un task agent si progetta partendo da un goal verificabile (“crea un record di vendita a partire dai dati cliente”), poi si assegnano le capacità di comprensione, interpretazione dei dati, pianificazione ed esecuzione, e infine le action: connettori Power Platform, connettori custom, API, operazioni Dataverse, cloud flow. Ogni azione richiede parametri di input, schema di output, autenticazione e regole di gestione degli errori; le regole di sicurezza (“chiedi sempre conferma prima di inviare un ordine”, “non superare mai il fido del cliente”) sono parte del design, non un ripensamento. Il principio del privilegio minimo si applica ai permessi delle azioni, non solo agli utenti.

Uno scenario tipico: una società di servizi vuole che l’agente prepari la proposta commerciale interrogando tre sistemi, con il vincolo che l’elaborazione richiede diversi minuti. Chi progetta un agent flow come tool deve sapere che il flusso va aggiunto con il trigger When an agent calls the flow e l’azione Respond to the agent, deve rispondere in tempo reale con l’opzione di risposta asincrona disattivata, deve essere pubblicato e deve rientrare nel limite di 100 secondi previsto per l’azione. Il vincolo di durata non si aggira scrivendo istruzioni migliori: obbliga a spezzare il processo o a spostare la parte lunga fuori dal percorso sincrono. È esattamente il tipo di dettaglio su cui l’esame costruisce la risposta corretta contro tre distrattori plausibili.

Autonomous agent: il trigger prende il posto dell’utente, e con lui l’identità

L’event trigger genera un trigger payload che arriva all’agente attraverso un connettore, portando con sé i dati dell’evento e istruzioni specifiche di quel trigger, distinte dalle istruzioni generali dell’agente. Finché l’agente non è pubblicato, il trigger non reagisce; dopo la pubblicazione reagisce ogni volta, e da lì nascono i vincoli architetturali che contano davvero.

Il primo è l’identità: i trigger a evento possono autenticarsi soltanto con le credenziali del maker, e perché l’agente giri senza interruzioni ogni azione autenticata deve usare quelle stesse credenziali. Un utente dell’agente pubblicato può quindi raggiungere dati che con la propria identità non vedrebbe: se lo scenario impone segregazione per utente, quella è una ragione per non scegliere questa strada. Il secondo è il governo: gli amministratori possono bloccare gli event trigger tramite le data policy, e l’ambiente deve avere attivo il solution-aware cloud flow sharing. Il terzo è il consumo: un trigger a ricorrenza invia un payload a ogni scadenza, e frequenze troppo strette portano l’agente contro le quote di servizio. Per le azioni ad alto impatto resta consigliata la supervisione umana esplicita, con approvazione prima dell’esecuzione.

Un ultimo criterio decide molti scenari di Microsoft 365: un declarative agent non supporta le interazioni proattive e dipende dall’avvio dell’utente, mentre un custom engine agent può avviare azioni senza input diretto. Se il requisito dice “senza che nessuno apra una chat”, l’opzione dichiarativa è esclusa a prescindere dalla qualità della knowledge. Sul versante del Microsoft Foundry Agents service vale il principio speculare — l’agente può lavorare in background innescato da eventi di sistema — ricordando che alcuni tool della piattaforma, fra cui memory e web search, sono in preview e come tali non si mettono in un percorso critico.