Intelligenza artificiale
Il 9 ottobre 2026 Anthropic ha introdotto in beta i workflow dinamici per i Claude Managed Agents. Secondo le release notes della Claude Platform, per i lavori fatti di molte parti, come la revisione di centinaia di documenti, l’agente può scrivere un workflow: un programma che esegue molti agenti in più fasi e ne combina i risultati. Il server lo esegue in background come «workflow run».
Che cosa sono workflow, run e workflow dinamici
La documentazione dei workflow run, sul sito di Anthropic, distingue tre termini. Il workflow è il programma scritto dall’agente, il workflow run è la sua esecuzione, i workflow dinamici sono la funzione che consente all’agente di scrivere workflow e avviare run.
Durante un run l’agente può continuare a lavorare o chiudere il proprio turno, e può controllare lo stato dell’esecuzione. Solo l’agente avvia un run: nessun evento inviato dall’utente lo termina, mentre l’archiviazione della sessione può farlo. Alla fine del run, normalmente l’agente della sessione riceve un turno per leggerne l’esito, rispondere all’utente o avviare un altro run. Il turno può arrivare più tardi, al raggiungimento del budget o mentre il thread principale attende il client; dopo un’interruzione può richiedere un nuovo user.message, mentre dopo archiviazione o terminazione non arriva.
Come si attivano i workflow dinamici
La funzione è in beta e richiede l’header managed-agents-2026-04-01. Nella definizione dell’agente il campo multiagent va impostato così:
{"type": "multiagent_20261001", "workflows": {"type": "enabled"}}
Per guidare l’agente, Anthropic indica di scrivere nel system prompt quando deve avviare un run. Nell’esempio della documentazione, un agente che rivede contratti ha l’istruzione di lanciare un run quando i contratti sono più di pochi e di occuparsi da solo di uno o due.
- Con il tipo
multiagent_20261001workflow e subagent sono attivi per impostazione predefinita; per avere solo i workflow si aggiunge"subagents": {"type": "disabled"}. - Un workflow può usare agenti che definisce da sé (inline) oppure agenti già creati, elencati in
workflows.predefined_agents, fino a 20. - Un agente inline usa il modello dell’agente di sessione; per un altro modello bisogna creare l’agente e inserirlo nell’elenco.
- Per disattivare la funzione si imposta
workflowssu{"type": "disabled"}.
Come lavora un run
Un run si articola in fasi con un nome, per esempio «Read the contracts». Secondo Anthropic, il programma può eseguire molti agenti in parallelo, passare il risultato di uno a un altro, ripetere un passaggio (ad esempio finché una revisione non viene superata) e scegliere il passo successivo in base a ciò che un agente restituisce. Se un agente fallisce, il programma può gestire l’errore oppure lasciare che chiuda il run.
Ogni agente lavora in un proprio thread di sessione, ma tutti condividono la sandbox della sessione e quindi gli stessi file. I run non sono annidati: un agente che lavora dentro un run non può avviarne un altro. Una sessione può avere più run aperti contemporaneamente.
Gli eventi per seguire un run
L’avanzamento arriva sullo stream di eventi della sessione, con eventi workflow_run.*:
workflow_run.created: il run è partito; include nome, descrizione e fasi dichiarate;workflow_run.status_runningeworkflow_run.status_idle: esecuzione avviata o ripresa, oppure pausa, per esempio al budget;workflow_run.phase_startedeworkflow_run.phase_ended: ingresso e uscita da una fase;workflow_run.status_ended: fine del run, sempre l’ultimo evento, con il camporesult;workflow_run.error: errore di un run o avvio rifiutato.
Il risultato può essere completed, stopped oppure un errore. Un run completed non dice se il lavoro sia riuscito: può finire così anche se alcuni thread hanno fallito, quindi per trovare i fallimenti vanno letti gli eventi di ciascun thread. La durata massima predefinita di un run è di 24 ore.
| Errore | Significato secondo Anthropic |
|---|---|
timeout_error |
il run ha raggiunto la durata massima, 24 ore per impostazione predefinita o quella scelta dall’agente |
program_error |
il workflow è fallito, oppure un thread è fallito e il workflow ha lasciato che chiudesse il run |
thread_limit_error |
il run ha superato il limite di agenti che un workflow può avviare |
unknown_error |
il server non ha potuto proseguire, o il run ha superato altri limiti sui workflow |
Costi e budget di sessione
Secondo la pagina sull’orchestrazione multiagente, ogni agente di un run consuma token: Anthropic consiglia quindi di impostare un budget di sessione, che limita la spesa della sessione, run compresi.
I dettagli del budget sono nella pagina dedicata ai budget. Il tetto si imposta alla creazione della sessione e, se la sessione non ne ha uno, non si può aggiungere dopo. Il limite è espresso in centesimi di dollaro USA, l’unica valuta supportata, ed è calcolato ai prezzi di listino pubblici. Ogni thread termina comunque la richiesta già avviata quando viene raggiunto il tetto: il costo finale può quindi superare il budget fino al costo di una richiesta per ciascun thread attivo.
Al raggiungimento del budget il lavoro va in pausa senza che la sessione termini. La sessione passa a idle con budget_reached, oppure segnala requires_action se un thread attende una risposta a una chiamata strumento, che va comunque fornita. Ogni run aperto non già idle riceve un evento workflow_run.status_idle. Per riprendere si modifica il tetto con un valore superiore al costo già consumato oppure lo si rimuove; ogni run messo in pausa dal budget riceve workflow_run.status_running. Se però il consumo della sessione include un modello senza prezzo di listino pubblico, la modifica del budget viene rifiutata: per riprendere occorre rimuoverlo. Una volta rimosso, il budget non può essere riassegnato alla stessa sessione.
Tra gli usi indicati da Anthropic per i workflow dinamici ci sono audit, migrazioni, ricerca approfondita e verifiche incrociate.
