Argo's New Dreams

Tempo di lettura: ~12 minuti

Introduzione

Con il Message Center MC1280557, Microsoft ha annunciato una delle novità più significative dell’ecosistema Copilot degli ultimi mesi: la possibilità di sottoporre agenti costruiti con Agent Builder alla revisione dell’amministratore IT e pubblicarli nel catalogo dell’Agent Store aziendale.

Disponibile in General Availability da maggio 2026 (rollout completato entro fine maggio), questa feature chiude un gap che chiunque abbia lavorato seriamente con Copilot Studio o Agent Builder conosce bene: “Ho costruito un agente utile. Come lo distribuisco a tutta l’organizzazione in modo controllato?”

In questo articolo analizziamo il flusso completo — tecnico e organizzativo — con tutto quello che serve sapere per prepararsi all’adozione.

Il problema che questa feature risolve

Prima di entrare nel dettaglio, vale la pena capire perché questa novità conta davvero.

Negli ultimi due anni, con la diffusione di Copilot Studio e Agent Builder, è emerso un pattern ricorrente nelle organizzazioni:

• Gli utenti più avanzati (power users, IT pro, sviluppatori interni) costruiscono agenti utili e specifici per il business
• La distribuzione avviene in modo informale: link condivisi via Teams, file esportati, istruzioni via email
• L’IT non ha visibilità né controllo su cosa gira in produzione
• Nessun discovery centralizzato: ogni utente deve sapere che l’agente esiste per poterlo trovare

Il risultato è un ecosistema frammentato, con shadow AI che prolifera fuori da qualsiasi governance.

Il nuovo flusso di submission all’Agent Store risolve esattamente questo: introduce un marketplace interno governato, simile a quello che le organizzazioni hanno già con le app nel Microsoft Teams App Store, ma dedicato agli agenti AI.

Architettura del flusso: submission → review → distribuzione

Vediamo il flusso end-to-end in dettaglio.

1. Submission da Agent Builder

Il maker dell’agente, dall’interfaccia di Agent Builder, trova l’opzione “Submit to your org catalog” nel menu dell’agente.

Questa azione:

• Crea una review request nel Microsoft 365 Admin Center
• È disponibile anche nei tenant con sharing controls attivi (importante: non bypassa i controlli esistenti)
• Non richiede privilegi amministrativi — qualsiasi utente con accesso ad Agent Builder può sottomettere

Cosa viene inviato nella submission:

• Metadati dell’agente (nome, descrizione, icona)
• Configurazione delle istruzioni di sistema (system prompt)
• Knowledge sources associate (SharePoint, siti web, file)
• Actions configurate (connettori, API, flussi Power Automate)
• Impostazioni di sicurezza e autenticazione

2. Review nel Microsoft 365 Admin Center

L’amministratore trova le richieste in:

Microsoft 365 Admin Center
  └── Agents
        └── All agents
              └── Requests  ← nuova sezione

Per ogni submission, l’admin può:

Il workflow di review è lo stesso già usato per le app di Teams: chi gestisce app LOB o app di terze parti nel tenant conosce già questa interfaccia. Nessuna nuova curva di apprendimento per gli admin.

3. Deployment e opzioni di distribuzione

Una volta approvato, l’admin controlla tre parametri di deployment:

Scope di accesso:

• Tutti gli utenti del tenant
• Gruppi di sicurezza specifici (es. solo il reparto Finance, solo i PM)
• Singoli utenti (utile per rollout graduali o beta testing interni)

Modalità di installazione:

• Available — l’agente appare nell’Agent Store, l’utente lo installa volontariamente
• Pre-installed — installato automaticamente per gli utenti in scope, ma rimovibile
• Pinned — pre-installato e non rimovibile dall’utente finale

Queste tre modalità rispecchiano esattamente quelle già disponibili per le app Teams, rendendo la gestione coerente con i processi IT esistenti.

4. Discovery lato utente finale

Dopo l’approvazione, l’agente appare nell’Agent Store di Microsoft 365 — accessibile da Copilot, Teams e altre entry point — nella sezione dedicata:

Agent Store
  ├── Built by Microsoft
  ├── Built by your org        ← qui appaiono gli agenti interni approvati
  └── Built by partners

Gli utenti in scope vedono l’agente, possono leggere la descrizione e installarlo con un click.

Gestione del ciclo di vita dell’agente

Agent Registry

Dopo la pubblicazione, l’agente appare come entry separata in:

Admin Center > Agents > All agents

Qui l’admin ha visibilità su:

• Versione attiva
• Utenti/gruppi in scope
• Stato (attivo, sospeso, in review)
• Storia delle submission

Aggiornamenti e versioning

Ogni modifica all’agente che il maker vuole distribuire richiede una nuova submission e un nuovo ciclo di review completo.

Questo è un punto critico da comprendere:

• ✅ Vantaggio: nessun aggiornamento silenzioso arriva agli utenti finali senza approvazione IT
• ⚠️ Attenzione: in ambienti con agenti che evolvono rapidamente, il ciclo di review può diventare un collo di bottiglia se non si definisce un processo interno chiaro

Best practice: definire SLA interni per la review (es. 2 giorni lavorativi), distinguere tra aggiornamenti critici (fix di sicurezza o bug) e feature updates.

Implicazioni per la governance AI aziendale

Questa feature non è solo operativa — ha implicazioni strategiche sulla governance AI dell’organizzazione.

Visibilità e inventario

Per la prima volta, l’IT ha un registro centralizzato degli agenti AI attivi in produzione. Questo è fondamentale per:

• Audit di conformità (GDPR, ISO 27001, NIS2)
• Data loss prevention: sapere quali agenti hanno accesso a quale knowledge base
• Offboarding: quando un maker lascia l’azienda, gli agenti pubblicati rimangono gestiti dall’org

Controllo delle Actions

Un aspetto spesso sottovalutato: gli agenti possono avere Actions — ovvero connessioni a sistemi esterni via connettori o API. Nel flusso di review, l’admin dovrebbe valutare:

• Quali sistemi viene chiamato dall’agente?
• L’autenticazione è delegata all’utente finale o usa credenziali di servizio?
• I dati elaborati rimangono nel tenant Microsoft 365 o escono verso API esterne?

Non esiste (ancora) una scheda di “security summary” automatica nella review, quindi la valutazione rimane manuale — ma avere il processo centralizzato è già un grande passo avanti.

Policy di pubblicazione

Prima dell’arrivo di questa feature, poche organizzazioni avevano una policy formale per gli agenti AI interni. Ora è il momento giusto per definirla. Una policy minimale dovrebbe coprire:

1. Chi può sottomettere — tutti gli Agent Builder users o solo utenti in ruoli specifici?
2. Criteri di approvazione — qualità della descrizione, sicurezza delle knowledge sources, revisione delle Actions
3. SLA di review — tempo massimo di risposta per non bloccare i maker
4. Criteri di sospensione — quando un agente approvato viene ritirato
5. Comunicazione — come vengono notificati gli utenti di nuovi agenti disponibili

Scenario pratico: dalla costruzione alla produzione

Vediamo un esempio concreto per rendere tangibile il flusso.

Scenario: Il team Finance di un’azienda manifatturiera ha costruito un agente con Agent Builder chiamato “FinanceGPT” che:

• Risponde a domande sui dati di budget attingendo a file SharePoint del team Finance
• Ha un’Action che interroga il gestionale ERP via Power Automate per dati di chiusura mensile
• È configurato per rispondere solo in italiano con un tono formale

Flusso:

1. Finance team lead (maker) → "Submit to your org catalog" da Agent Builder
         │
         ▼
2. IT Admin riceve notifica in Admin Center > Agents > Requests
         │
         ├── Verifica: le knowledge sources sono solo SharePoint Finance? ✅
         ├── Verifica: l'Action ERP usa autenticazione utente (OAuth)? ✅
         ├── Verifica: nessun dato esce dal tenant Microsoft 365? ✅
         │
         ▼
3. Admin approva → scope: security group "Finance-All" → modalità: Pre-installed
         │
         ▼
4. I 45 utenti del gruppo Finance trovano FinanceGPT già installato in Copilot
         │
         ▼
5. Tre mesi dopo, il maker aggiorna le istruzioni di sistema e aggiunge 
   una seconda Action → nuova submission → nuovo ciclo di review

Confronto con l’approccio Teams App Store

Per chi gestisce già app aziendali in Teams, il parallelismo è diretto:

La coerenza è chiaramente intenzionale: abbassare la curva di apprendimento per gli admin IT già familiari con la gestione delle app Teams.

Limitazioni e aree di miglioramento attese

Essendo una GA di maggio 2026, alcune limitazioni sono prevedibili nella fase iniziale:

• Nessuna differenziazione di versione visibile all’utente finale: non è chiaro se l’utente vede la “versione” dell’agente installato
• Review manuale senza strumenti di analisi automatica delle Actions o delle knowledge sources (un futuro Secure Score per agenti sarebbe utile)
• Notifiche aggiornamenti agli utenti finali: da verificare il comportamento quando una nuova versione viene approvata (aggiornamento silenzioso? notifica?)
• Rollback: non è documentato un meccanismo di rollback rapido a una versione precedente in caso di problemi

Sono aree che Microsoft probabilmente affinerà nei mesi successivi al rilascio.

Cosa fare adesso per prepararsi

Per gli IT Admin:

• Esplorare la sezione Agents > All agents > Requests nell’Admin Center
• Definire o aggiornare la policy interna di governance degli agenti AI
• Comunicare il nuovo processo ai team che già usano Agent Builder

Per i maker di agenti:

• Prepararsi a scrivere descrizioni di agenti chiare e complete (il processo di review li richiederà)
• Documentare le Actions e le knowledge sources di ogni agente
• Anticipare i tempi: se un agente serve per una deadline, la submission va fatta con anticipo rispetto al ciclo di review

Per i decision maker:

• Valutare se nominare un “Agent Owner” per ogni agente pubblicato — una figura responsabile della qualità e del ciclo di vita dell’agente, distinta dall’IT admin che approva

Conclusione

L’Agent Store con submission e governance non è solo una feature di distribuzione — è l’infrastruttura che trasforma gli agenti AI da esperimenti individuali a asset aziendali gestiti.

Siamo all’inizio di un’era in cui ogni organizzazione costruirà e gestirà una propria libreria di agenti AI specializzati. La governance non è il freno a questo processo — è la condizione che lo rende sostenibile, scalabile e sicuro.

Le organizzazioni che iniziano ora a strutturare processi, policy e cultura intorno a questa capability avranno un vantaggio significativo nei prossimi 12-24 mesi.

Fonte ufficiale: Microsoft 365 Message Center – MC1280557 | Roadmap ID: 557173
Documentazione: Publish agents | Microsoft Learn
Disponibilità: General Availability Worldwide — rollout maggio 2026

Hai già agenti interni che vorresti distribuire nella tua organizzazione? Scrivimi nei commenti o contattami direttamente — sarò felice di confrontarmi sul tuo scenario specifico.