Che cos’è un agent flow, e con che cosa non va confuso

Un agent flow è un’automazione costruita in Copilot Studio composta da un trigger e da almeno un’azione. La doc lo riassume con una frase che vale la pena tenere a mente: “Agent flows are deterministic.” A parità di input producono sempre lo stesso output, e questo li rende il posto giusto dove mettere le parti del processo che non vuoi affidare al ragionamento del modello.

Prima di andare avanti, quattro oggetti da non impastare. Un topic è un dialogo autorizzato dentro l’agente, con le sue trigger phrases e i suoi nodi. Un tool è qualsiasi cosa l’agente possa invocare: un agent flow lo diventa, ma sono tool anche un prompt, un connettore, una REST API, un server MCP o computer use. Una knowledge source serve a far rispondere l’agente, non ad agire. E l’agent flow è la sola di queste quattro cose che sia un’automazione con una sua run, una sua version history e un suo consumo di capacità.

Si crea dalla pagina Flows con New flow > Agent flow: il designer si apre con un template di partenza che contiene già gli elementi obbligatori. Come alternativa la doc prevede la creazione in linguaggio naturale, descrivendo a parole quello che serve.

Il trigger e l’azione di risposta: la regola che l’esame verifica davvero

Perché un flow possa comparire fra i tool di un agente deve avere il trigger When an agent calls the flow e un’azione di risposta Respond to the agent, ed essere pubblicato. Questa è la coppia che rende il flow invocabile dall’orchestratore, e nella pagina di aggiunta del tool la doc lo dice a chiare lettere: se il flow non compare nell’elenco che si apre selezionando Flow, controlla che abbia questi due elementi, perché senza di essi non può essere aggiunto.

Ne segue la confusione più costosa dell’esame: un flow che parte da un trigger di connettore, per esempio When a new email arrives (V3), non è invocabile dall’agente, per quanto funzioni benissimo per conto suo. Il rimedio documentato è chirurgico: cancella il trigger esistente dai tre puntini della card, cerca Copilot sotto Add a trigger e scegli When an agent calls the flow, poi aggiungi in fondo l’azione Respond to the agent dello stesso connettore, salva e pubblica. Il flow deve inoltre stare in una solution nello stesso environment dell’agente.

Due dettagli tecnici che valgono una domanda. Il primo: la risposta deve essere sincrona, cioè il toggle Asynchronous response, sotto Networking nelle impostazioni di Respond to the agent, deve stare su Off; se resta acceso l’agente non esegue il flow e risponde con il messaggio di errore che riporta il codice 3000. Il secondo: la risposta deve arrivare entro il limite di 100 secondi per azione, e le azioni che devono girare più a lungo vanno collocate dopo Respond to the agent, dove continuano fino al limite di durata della run. Se il collo di bottiglia è il tempo di elaborazione e non la mole di dati, esiste Express mode, un toggle attivabile dai dettagli del flow o dalla card del trigger.

Parametri di input e output, e chi li riempie

Gli input si aggiungono sul trigger, gli output sull’azione di risposta. Lo scheletro tipico è questo:

When an agent calls the flow      input:  ExpenseId (Text), Amount (Number)
  → Get item / azioni del flow
  → Respond to the agent          output: Outcome (Text), Comments (Text)

Attenzione a un vincolo poco intuitivo: l’azione di risposta può essere usata su più rami del flow, ma deve esporre gli stessi output in ogni punto in cui compare. Rami con output diversi sono un errore di progetto, non una variante creativa.

Lato agente, quando aggiungi il flow con Add a tool > Flow > Add and configure, la sezione Inputs mostra una riga per parametro. La colonna Fill using è impostata per default su Dynamically fill with AI: l’agente prova a estrarre il valore dal contesto e, se non lo trova, genera lui la domanda da fare all’utente. Se invece vuoi imporre il valore, porta Fill using su Custom value e indica un valore, una variabile o una formula Power Fx; in quel caso l’utente non viene interrogato. La Description del tool non è decorativa: è ciò su cui l’orchestratore decide se e quando chiamare il flow.

Se dopo una modifica compare l’errore FlowActionBadRequest, la causa documentata è un disallineamento di schema fra i parametri del flow e quelli che l’agente si aspetta, tipicamente perché il flow è stato cambiato senza ripubblicare. La soluzione è Refresh sui tre puntini del nodo Action nel topic, verifica dei parametri e ripubblicazione dell’agente.

Human-in-the-loop: fermare il flusso per farsi autorizzare

Le azioni di approvazione sono il modo canonico di inserire una persona nel mezzo. Con il connettore Approvals hai Create an approval, Start and wait for an approval e Wait for an approval: la seconda avvia la richiesta e mette la run in attesa della risposta prima di proseguire. I tipi disponibili sono Approve/Reject - Everyone must approve, Approve/Reject - First to respond, le due varianti Custom Responses e la Sequential approval; l’approvatore risponde da Outlook, dalla adaptive card in Teams o dall’action center.

Negli agent flow c’è di più. Il connettore Human review porta l’azione Run a multistage approval, dove l’approvazione si compone in stages: Manual stage con Title, Assigned to e Details, AI stage con istruzioni e modello, e Condition fra gli stage per instradare. Un dettaglio da ricordare: non assegnare lo stesso approvatore a stage diversi, perché il flow fallisce. Sempre sotto Human review vive Request for information, che mette in pausa l’esecuzione e chiede a persone designate dati strutturati (Text, Yes/No, Email, Number, Date) via Outlook; vince la prima risposta, e ogni input diventa un parametro riusabile nelle azioni successive.

Qui casca la trappola progettuale che l’esame ama: un essere umano non risponde in 100 secondi. Se l’agente deve ricevere l’esito della decisione nella stessa chiamata, il conto non torna. Il pattern coerente con la doc è rispondere subito all’agente con un esito interlocutorio e collocare l’approvazione dopo Respond to the agent, lasciando che la run continui. Da non confondere, infine, con l’opzione Ask the end user before running del tool: quella è una conferma nella chat prima di eseguire, non un’approvazione dentro il flusso.