Anthropic porta i flussi di lavoro multi-agente ospitati a Claude agenti gestiti

Anthropic ha aggiunto flussi di lavoro dinamici a Claude Managed Agents nella versione beta pubblica, spostando un modello comune di progettazione degli agenti dal codice di orchestrazione locale alla piattaforma Claude stessa.

La versione del 9 ottobre consente a un agente gestito di scrivere un programma di flusso di lavoro, eseguire molti agenti in fasi e combinarne i risultati mentre il server esegue il lavoro in background come esecuzione di un flusso di lavoro. Gli sviluppatori abilitano la versione beta con l'intestazione beta managed-agents-2026-04-01 e configurano un campo multiagent con il tipo multiagent_20261001 e i flussi di lavoro abilitati. Anthropic afferma inoltre che workflow_run gli eventi vengono visualizzati nel flusso di eventi della sessione, offrendo alle applicazioni un modo per osservare i progressi anziché trattare il flusso di lavoro come una singola chiamata opaca.

Si tratta di un cambiamento significativo per i team che creano sistemi di agenti. La scomposizione multi-agente ha solitamente richiesto pianificatori lato applicazione, code, archivi di stati, nuovi tentativi e logica di unione dei risultati. Anthropic ora include parte del livello di orchestrazione come funzionalità API ospitata.

Cosa è cambiato

Claude Gli agenti gestiti offrivano già agli sviluppatori un ambiente gestito per le sessioni degli agenti. I flussi di lavoro dinamici estendono quel modello consentendo a un agente di produrre un programma di flusso di lavoro che coordina altri agenti attraverso le fasi. Invece di dover codificare manualmente ogni fase di una revisione parallela o di una pipeline di ricerca, l'agente gestito può definire il flusso di lavoro e la Claude piattaforma può eseguirlo in modo asincrono.

La distinzione utile non è semplicemente "più agenti". È dove vive l'orchestrazione. Con questa beta, il lavoro è rappresentato come un flusso di lavoro eseguito dal lato di Anthropic, con gli eventi emersi attraverso il flusso della sessione. Ciò potrebbe semplificare alcune architetture in cui in precedenza i team dovevano creare il proprio servizio controller attorno a Claude chiamate.

La funzionalità rimane in versione beta. La configurazione documentata e i nomi degli eventi di Anthropic sono dati stabili disponibili nelle note sulla versione e nella documentazione dell'agente gestito esaminata qui. Resoconti di terze parti hanno descritto limiti di scala specifici per agenti per esecuzione e agenti simultanei, ma tali limiti dovrebbero essere confrontati con la documentazione corrente sull'esecuzione del flusso di lavoro di Anthropic prima di essere trattati come vincoli operativi pubblicabili.

Perché è importante per API team

L'orchestrazione del flusso di lavoro ospitato rende i carichi di lavoro degli agenti più facili da avviare, ma più difficili da gestire in modo casuale. Una singola richiesta utente può suddividersi in numerose chiamate di modello, riepiloghi intermedi, chiamate di strumenti e passaggi di sintesi finale. Ciò cambia il profilo di costo e osservabilità di un'applicazione anche quando il prodotto rivolto all'utente sembra ancora una "domanda".

I casi d'uso più ovvi sono revisioni di codice di grandi dimensioni, revisione di documenti, pianificazione della migrazione, analisi di due diligence, controlli di conformità e attività di ricerca in cui specialisti paralleli possono lavorare su sezioni diverse prima che un agente di coordinamento unisca i risultati. Questi carichi di lavoro sono interessanti perché si adattano bene all’esecuzione per fasi. Sono anche i carichi di lavoro che con maggiore probabilità creeranno fatture di token di grandi dimensioni se richieste, tentativi e conteggi di sub-agenti non sono limitati.

Per i leader tecnici, la domanda sulla governance si sposta da "quale modello ha chiamato questo endpoint?" a "quale flusso di lavoro autonomo ha attivato questa richiesta e quanto ha consumato ciascuna fase?" È qui che LLM API attribuzione dei costi diventa più di un semplice reporting finanziario. I team devono sapere quale caratteristica del prodotto, cliente, progetto o chiave API ha causato l'interruzione del flusso di lavoro.

Esiste anche un aspetto dell'affidabilità. Le esecuzioni del flusso di lavoro in background richiedono visibilità dello stato di avanzamento, comportamento di annullamento, criteri di ripetizione e aspettative di stato durevoli. Il supporto del flusso di eventi di Anthropic è un inizio, perché le applicazioni possono iscriversi agli eventi eseguiti dal flusso di lavoro invece di eseguire il polling alla cieca.Ma i team dovranno comunque decidere quanta parte della propria macchina a stati rimarrà al di fuori del provider.

Chi è interessato

Il pubblico più immediato sono gli sviluppatori che già utilizzano Claude agenti gestiti o che stanno valutando l'infrastruttura degli agenti ospitati. I team che hanno creato sistemi multi-agente personalizzati possono confrontare la versione beta con il livello di orchestrazione esistente, soprattutto se la loro implementazione attuale è per lo più idraulica piuttosto che una logica di prodotto differenziata.

I team della piattaforma aziendale dovrebbero prestare attenzione anche se non sono pronti ad adottare la beta. L'orchestrazione ospitata cambia ciò che deve essere visibile in un AI API piano di controllo. Un piano di controllo che registra solo il conteggio delle richieste, il nome del modello e i token totali potrebbe non comprendere la struttura del carico di lavoro. Per i flussi di lavoro gestiti, i team vorranno identificatori di esecuzione, utilizzo a livello di fase, attività dello strumento, punti di errore e stato del budget.

Ciò influisce anche sull'approvvigionamento e sulla revisione della sicurezza. Un flusso di lavoro multi-agente ospitato non è solo un endpoint del modello; è un ambiente di esecuzione delegato. Le aziende dovranno capire quali dati passano attraverso ciascun agente, per quanto tempo viene conservato lo stato del flusso di lavoro, quali log sono disponibili e in che modo l'accesso viene limitato a progetti e ambienti.

Per B2B LLM clienti e API utenti multimodello simili, il collegamento pratico è la governance. Se i provider semplificano il fan-out degli agenti, i controlli a livello di piattaforma devono tenere il passo: limiti di spesa per chiave o progetto, analisi dell'utilizzo per i flussi di lavoro, liste consentite di modelli e avvisi quando un modello di automazione inizia a consumare più del previsto. I flussi di lavoro dinamici sono una caratteristica del prodotto, ma ricordano anche che i costi degli agenti sono spesso determinati dall'orchestrazione, non solo dal prezzo dei token.

Ciò che rimane incerto

La versione beta lascia aperte diverse domande operative per i team che pianificano l'utilizzo in produzione. Le note di rilascio pubbliche stabiliscono l'esistenza di flussi di lavoro dinamici, l'intestazione beta, il tipo di configurazione multiagente e la superficie del flusso di eventi. Nel materiale esaminato non stabiliscono ogni dettaglio della pianificazione della produzione in merito a limiti, comportamento dei prezzi, conservazione o semantica degli errori.

Gli sviluppatori devono verificare la documentazione corrente prima di impostare ipotesi sul numero massimo di agenti per esecuzione, concorrenza, comportamento di timeout e modalità di dettaglio dell'utilizzo nelle esportazioni di fatturazione. Dovrebbero anche eseguire piccole valutazioni prima di spostare i flussi di lavoro di revisione o conformità sensibili sulla funzionalità, perché la sintesi multi-agente può modificare la coerenza dell'output e il costo.

Tuttavia, la direzione più ampia è chiara. I fornitori di modelli stanno trasformando l'orchestrazione degli agenti in una piattaforma primitiva. Ciò riduce la quantità di infrastruttura necessaria per sperimentare, alzando al contempo il livello di osservabilità e controllo del budget una volta che gli esperimenti diventano flussi di lavoro reali.