Automazione

Claude Managed Agents: La guida completa alla nuova piattaforma agenti di Anthropic

9 aprile 2026

TL;DR

L'8 aprile 2026, Anthropic ha lanciato Claude Managed Agents in beta pubblica — un servizio hosted sulla Claude Platform che esegue agenti AI in produzione sull'infrastruttura di Anthropic, eliminando i mesi di lavoro di plumbing normalmente necessari per metterne uno in produzione.
Si definisce un agente in linguaggio naturale o YAML, si impostano i guardrail, e Anthropic gestisce l'esecuzione di codice in sandbox, il checkpointing, la gestione delle credenziali, i permessi con scope definito, l'identità e il tracing dell'esecuzione.
Pricing: tariffe standard dei token API di Claude, più $0,08 per session-hour di runtime attivo (il tempo idle è gratuito), più $10 per 1.000 web search.
Tra i clienti del lancio figurano Notion, Rakuten, Asana, Atlassian e Sentry — tutti dichiarano di aver messo in produzione agenti in giorni invece che in mesi.
Questo articolo analizza cosa sia realmente, l'architettura che Anthropic chiama "brain, hands, session," come si confronta con n8n, LangGraph e Zapier, i tradeoff onesti, un calcolatore di pricing realistico e una guida passo-passo per costruire il primo agente.
La versione breve per gli operator: se si stanno eseguendo agenti su un VPS con n8n o LangGraph, Managed Agents è la prima offerta credibile "gestiamo noi l'infra" che non è un giocattolo.

Cos'è Claude Managed Agents?

Claude Managed Agents è un servizio hosted sulla Claude Platform (platform.claude.com) che fornisce il runtime completo per agenti AI in produzione. Fino ad ora, Anthropic forniva il modello e l'infrastruttura era a carico dell'utente. Con Managed Agents, si porta la definizione di cosa l'agente deve fare e Anthropic porta tutto il resto.

Nella formulazione di Anthropic stessa, mettere in produzione un agente richiede esecuzione di codice in sandbox, checkpointing, gestione delle credenziali, permessi con scope definito e tracing end-to-end — mesi di lavoro infrastrutturale prima di rilasciare qualcosa che gli utenti vedono. Managed Agents gestisce questa complessità. Si definiscono i task, gli strumenti e i guardrail dell'agente, e Anthropic lo esegue sulla propria infrastruttura.

Il servizio è stato lanciato in beta pubblica l'8 aprile 2026, accessibile tramite la Claude Platform API. Tutti gli endpoint di Managed Agents richiedono l'header beta managed-agents-2026-04-01, che l'SDK imposta automaticamente. Tre funzionalità avanzate — outcomes (auto-valutazione rispetto ai criteri di successo), multi-agent coordination e persistent memory — sono attualmente in research preview e richiedono una richiesta di accesso separata.

Perché questo lancio è davvero importante

Ogni settimana, negli ultimi diciotto mesi, qualcuno ha annunciato "la piattaforma agenti che cambia tutto." La maggior parte non l'ha fatto. Perché allora questo genera 2 milioni di visualizzazioni su un singolo tweet e 39.000+ like il giorno del lancio? Tre ragioni che vale la pena capire prima di valutare se adottarlo.

Primo, Anthropic ha risolto il 70% noioso. Chi ha costruito un agente in produzione lo sa già: il modello è la parte facile. Tutto ciò che circonda il modello — la sandbox in cui esegue il codice, lo stato persistente che sopravvive a un crash del container, le credenziali usate dagli strumenti per autenticarsi, lo scoping dei permessi che impedisce all'agente di cancellare dati di produzione, l'audit log che il team di compliance richiede, il recovery degli errori quando una tool call fallisce a metà — è dove i mesi svaniscono. Questa è la parte che Managed Agents rimuove.

Secondo, la governance story è il vero sblocco per l'enterprise. Permessi con scope definito, identity management e execution tracing sono le tre cose che tradizionalmente bloccano i rollout enterprise degli agenti AI. I CISO e i responsabili compliance non si preoccupano di quanto sia elegante il prompt; si preoccupano di poter rispondere "chi ha fatto cosa e quando" in un audit. Managed Agents costruisce tutto questo di default, ed è per questo che la lista dei clienti del lancio si legge come si legge — Atlassian, Notion, Rakuten e Asana non sono aziende che rilasciano agenti senza un sign-off compliance.

Terzo, il pricing è pensato per un utilizzo reale. A $0,08 per session-hour di runtime attivo — e, cosa cruciale, il tempo idle non viene contato — i conti tornano per i workload async di lunga durata che sono stati i più difficili da mettere in produzione sulle piattaforme esistenti. Un agente di ricerca che trascorre 2 ore a leggere documenti e 22 ore in attesa di nuovi task paga runtime per 2 ore, non per 24.

L'architettura: Brain, Hands, Session

Questa è la parte che la maggior parte degli articoli di lancio ha saltato, ed è quella che conta se si intende costruire sopra questa piattaforma. Anthropic ha pubblicato un engineering blog companion lo stesso giorno del lancio per spiegare il design, e l'astrazione centrale vale la pena interiorizzarla.

Managed Agents virtualizza un agente in tre componenti separabili:

Il Brain. L'LLM stesso (Claude) più l'harness che orchestra il suo reasoning loop — decide quando chiamare strumenti, come gestire il contesto e come recuperare dagli errori.

Le Hands. Un ambiente di esecuzione sandboxed ed effimero in cui gli strumenti vengono effettivamente eseguiti. L'esecuzione di codice, le operazioni su file, la navigazione web e le chiamate ai server MCP avvengono qui. Le hands sono stateless — se un container crasha o viene corrotto, il sistema ne avvia uno nuovo e l'agente continua. Un container compromesso non persiste, il che è una proprietà di sicurezza significativa per chi esegue output di strumenti non fidati.

La Session. Un event log durevole e append-only che vive al di fuori sia del brain che delle hands. Registra ogni tool call, ogni risultato, ogni decisione. Se il brain deve tornare indietro e verificare cosa è successo tre step fa, legge dal session log. Se l'intero sistema si riavvia a metà task, la session riprende da dove si era fermata.

Perché questo è rilevante nella pratica? Perché ogni componente può scalare indipendentemente, e perché le astrazioni sono stabili anche quando l'implementazione sottostante cambia. Nelle parole di Anthropic stessa, questo è progettato come un "meta-harness" — senza opinioni sull'harness specifico di cui Claude avrà bisogno in futuro, ma con opinioni sulle interfacce che lo circondano. Questo è importante perché gli harness codificano assunzioni su ciò che il modello non è in grado di fare da solo, e queste assunzioni invecchiano rapidamente con il miglioramento dei modelli. Costruire direttamente contro un harness specifico significa re-platformare ogni volta che Anthropic rilascia un modello più capace. Costruire contro le interfacce di Managed Agents significa non doverlo fare.

Cosa si definisce concretamente come sviluppatore: l'agente (modello, system prompt, strumenti, server MCP e skills), l'ambiente (un cloud container con pacchetti pre-installati come Python, Node.js, Go, più regole di rete e file montati) e la session (che referenzia entrambi). Si crea l'agente una volta e lo si referenzia per ID tra le sessioni.

Pricing: cosa costa davvero

Il pricing di Managed Agents si compone di tre componenti, tutte trasparenti e documentate nella pagina ufficiale dei prezzi API:

1. Token del modello. Ogni token consumato da una sessione di Managed Agents viene fatturato alle tariffe standard dell'API Claude. I moltiplicatori di prompt caching si applicano in modo identico. Ciò significa che se si usa Sonnet 4.6, si pagano le tariffe di Sonnet 4.6; se si usa Opus 4.6, si pagano le tariffe di Opus.

2. Session runtime. $0,08 per session-hour, misurato al millisecondo, fatturato solo mentre lo status della sessione è running. Il tempo trascorso idle (in attesa del prossimo messaggio o di una conferma da uno strumento), in rescheduling o terminato non conta ai fini del runtime. Il session runtime sostituisce il modello di fatturazione per container-hour di Code Execution — non viene fatturato separatamente un costo per container-hour in aggiunta a questo.

3. Web search. $10 per 1.000 web search attivate all'interno di una sessione, identico alla tariffa standard dello strumento web search nel resto dell'API Claude.

Da notare che i seguenti modificatori API non si applicano alle sessioni di Managed Agents: sconto Batch API, pricing Message Batches e pricing Fast mode. Se si sta ottimizzando i costi, questi non aiutano qui.

Esempi di pricing realistici

Alcuni esempi concreti, perché i numeri astratti non atterrano finché non li si vede applicati.

Esempio 1: Agente di triage inbox per un piccolo team. Gira due volte al giorno, con una media di 15 minuti di runtime attivo per esecuzione, elabora circa 50 email usando Sonnet 4.6, effettua circa 5 web search per esecuzione. Calcolo mensile: 30 giorni x 2 esecuzioni x 0,25 ore = 15 session-hour x $0,08 = $1,20 di runtime. Token: circa $8–15/mese alle tariffe Sonnet. Web search: 300/mese x $0,01 = $3. Totale: circa $12–20/mese.

Esempio 2: Agente di lead enrichment per un team outbound B2B. Gira su richiesta quando nuovi lead arrivano nel CRM, con una media di 3 minuti di runtime attivo per lead, elabora 200 lead al mese con Sonnet 4.6, effettua 4 web search per lead. Calcolo: 200 x 0,05 ore = 10 session-hour x $0,08 = $0,80 di runtime. Token: circa $20–40/mese a seconda del contesto. Web search: 800 x $0,01 = $8. Totale: circa $30–50/mese.

Esempio 3: Agente di ricerca always-on che monitora un mercato. Attivo circa 2 ore al giorno a scansionare notizie e generare report, con Opus 4.6 per la fase di sintesi. Calcolo: 60 session-hour/mese x $0,08 = $4,80 di runtime. Token alle tariffe Opus: circa $80–200/mese a seconda dei volumi. Web search: 3.000/mese x $0,01 = $30. Totale: circa $120–240/mese.

Esempio 4: Un agente "sempre in esecuzione" h24. Questo è il caso limite da tenere a mente. Se un agente è genuinamente in esecuzione continua — elaborazione attiva, non idle — il calcolo è 730 ore/mese x $0,08 = $58,40/mese solo di runtime, più token, più web search. La maggior parte dei workload reali non gira in modo continuo; gira a burst. Se il proprio workload lo fa, occorre tenerne conto.

L'insight chiave: il tempo idle è gratuito. Questo è ciò che rende il pricing funzionante per il tipo di workload long-running, async ed event-driven che rappresenta il caso d'uso principale di Managed Agents. Un agente che aspetta 23 ore al giorno un trigger non costa nulla in quelle 23 ore.

Claude Managed Agents vs. n8n vs. LangGraph vs. Zapier

Questo è il confronto che tutti stanno cercando su Google, quindi esaminiamo direttamente dove si posiziona ciascuno strumento.

vs. n8n (self-hosted o cloud)

n8n è uno strumento di workflow automation che eccelle nelle automazioni deterministiche e trigger-based con molte integrazioni SaaS — webhook, job pianificati, notifiche Slack, scritture su database. I suoi nodi agente AI permettono di aggiungere reasoning LLM a un workflow, ma n8n è fondamentalmente un workflow engine con funzionalità AI aggiunte, non un agent runtime.

Quando n8n vince ancora: pipeline deterministiche dove ogni step è prevedibile. Job cron-based. Flussi semplici "se succede X, fai Y, poi Z" con 20+ integrazioni SaaS. Self-hosting a basso costo su VPS quando serve controllo assoluto.

Quando vince Managed Agents: task open-ended dove l'agente deve decidere il passo successivo in base a ciò che ha trovato nel precedente. Sessioni long-running che possono durare ore. Workload dove il layer di governance (permessi con scope, audit trail, identità) non è negoziabile. Qualsiasi cosa in cui si ha bisogno che l'agente scriva ed esegua codice in modo sicuro in una sandbox.

La vera distinzione: n8n è per workflow con AI dentro. Managed Agents è per agenti con strumenti dentro. Se si sta usando n8n con nodi agente AI e si stanno incontrando limiti sulla lunghezza della sessione, la gestione del contesto o la sicurezza — questo è il segnale.

vs. LangGraph / LangChain

LangGraph è il framework open-source per costruire applicazioni multi-agente stateful con control flow esplicito basato su grafi. È lo strumento che la maggior parte dei team di AI engineering seri ha usato per costruire agenti in produzione nell'ultimo anno.

Quando LangGraph vince ancora: quando serve controllo totale sull'agent loop, si vuole girare sulla propria infrastruttura per motivi di compliance o costo, si ha bisogno di orchestrazione multi-modello (mix di Claude, GPT, Gemini, modelli open-source), o si vuole personalizzare ogni aspetto della gestione dello stato.

Quando vince Managed Agents: quando si vuole smettere di manutenere completamente il layer infrastrutturale. Quando si è già su modelli Claude. Quando i mesi di lavoro che Anthropic ha fatto su checkpointing, compaction e ottimizzazione dell'harness sono genuinamente migliori di ciò che il proprio team costruirebbe. Quando si vuole che la storia di compliance e audit sia già pronta.

La vera distinzione: LangGraph è un framework che si hosta e si mantiene. Managed Agents è un servizio che si affitta. Uno dà massima flessibilità; l'altro dà massima velocità verso la produzione.

vs. Zapier / Make

Zapier e Make sono piattaforme di automazione SaaS ottimizzate per utenti non tecnici che connettono applicazioni business. Sono la risposta giusta per "quando arriva una nuova riga nel mio Google Sheet, posta su Slack e crea una card su Trello." Hanno funzionalità AI ora, ma non sono agent runtime.

Quando Zapier/Make vincono ancora: quando chi costruisce l'automazione non è tecnico e il task è una pipeline lineare ben definita tra app SaaS note.

Quando vince Managed Agents: quando il task richiede genuinamente reasoning — leggere documenti, decidere cosa è rilevante, scrivere codice, condurre ricerche. Cose che nessuna quantità di step Zapier risolverà in modo pulito.

La vera distinzione: Zapier è per connettere app note con logica nota. Managed Agents è per logica sconosciuta che deve capirsi a runtime.

Guida passo-passo: costruire il primo Managed Agent

Ecco il percorso minimo viable da "non l'ho mai toccato" a "ho rilasciato un agente funzionante in produzione." Claude Managed Agents si accede tramite la Claude Platform API (platform.claude.com), e i seguenti step assumono che si abbia già un account Anthropic Console con la fatturazione abilitata.

Step 1: Pianificare l'agente su carta prima

Prima di scrivere una singola riga di YAML, scrivere un piano di una pagina che risponde a cinque domande:

Cosa fa l'agente, in una frase? "Effettua il triage della mia inbox e bozza risposte alle 10 email più importanti." Non "gestisce le email."
A quali strumenti deve avere accesso? Gmail read/write, web search, forse il calendario.
Quali sono i guardrail? Cosa non è mai autorizzato a fare? (ad es., "Non inviare mai email senza la mia approvazione. Non cancellare mai nulla.")
Come appare il successo? Come si saprà se l'agente sta davvero funzionando?
Qual è il trigger? Invocazione manuale, schedule, webhook, evento CRM?

Saltare questo step significa trascorrere la prima settimana a fare debug di sintomi di un problema mal specificato.

Step 2: Definire l'agente

Si hanno due opzioni. Per i non sviluppatori o i prototipi rapidi, si definisce l'agente in linguaggio naturale attraverso la UI della Claude Platform — si descrive cosa si vuole e il tooling di Anthropic genera la configurazione sottostante. Per qualsiasi cosa si voglia mantenere in version control, si usa un file di definizione YAML con il modello dell'agente, il system prompt, la lista degli strumenti, i server MCP e le skills.

La definizione dell'agente viene creata una volta e referenziata per ID tra le sessioni. Questo è importante: la stessa definizione di agente può servire molte sessioni concorrenti senza overhead di ri-definizione.

Step 3: Configurare l'ambiente

L'ambiente è il cloud container in cui le hands dell'agente gireranno. Si specificano i pacchetti pre-installati (Python, Node.js, Go e altri), le regole di accesso alla rete (quali domini l'agente può raggiungere) e i file montati di cui l'agente ha bisogno.

Iniziare con la configurazione più restrittiva. Dare il minimo accesso di rete richiesto, installare solo i pacchetti che si sa di avere bisogno, e montare solo i file specifici rilevanti per il task. Si può sempre espandere dopo; non si può annullare una data leak.

Step 4: Avviare una sessione

Una sessione referenzia sia la definizione dell'agente che l'ambiente. Una volta avviata, l'agente gira autonomamente — ragionando, chiamando strumenti, eseguendo codice e persistendo lo stato nel session log. È possibile ispezionare qualsiasi sessione attraverso la Claude Console, inclusa ogni tool call, ogni decision point e ogni failure mode.

Step 5: Strumentare e iterare

Il session tracing, gli integration analytics e la guida al troubleshooting sono integrati direttamente nella Claude Console. Usarli. Rivedere le prime 20–50 sessioni manualmente prima di cominciare a fidarsi che l'agente giri in modo non supervisionato. Cercare tre pattern: strumenti che l'agente chiama ma non dovrebbe, strumenti che dovrebbe chiamare ma non chiama, e punti in cui dichiara il task completato prematuramente.

Step 6: Hardening per la produzione

Una volta che l'agente funziona, aggiungere le tre cose che separano una demo da un sistema di produzione:

Permessi con scope definito. Dare all'agente l'identità più ristretta possibile — un service account con accesso in sola lettura ai sistemi di cui ha bisogno e accesso in scrittura solo dove è assolutamente necessario.
Human-in-the-loop checkpoint per ogni azione irreversibile. Inviare un'email, cancellare un file, addebitare una carta di credito, pubblicare contenuto — tutte queste azioni dovrebbero richiedere un'approvazione esplicita finché non si hanno mesi di prove che l'agente le gestisce in modo affidabile.
Budget alert. Impostare spending cap a livello di organizzazione e alert ben al di sotto del cap. Un agente in un loop non intenzionale può bruciare token velocemente.

Limitazioni oneste (il giorno dopo)

Ogni articolo di copertura del lancio le omette. Ecco cosa tenere davvero d'occhio.

È in beta pubblica. Lanciato l'8 aprile 2026. L'affidabilità in produzione su mesi di operatività non è ancora provata — i first adopter sono grandi nomi, ma il battle-testing su larga scala richiede tempo. Trattarlo come production-capable ma non ancora production-hardened.

I rate limit si applicano ancora. I rate limit esistenti dell'API Claude non spariscono perché si usa Managed Agents. Se si eseguono 50 agenti in parallelo che bruciano tutti token, si raggiungeranno i limiti. Gli endpoint di Managed Agents sono inoltre rate-limited per organizzazione, e Anthropic non ha ancora pubblicato numeri specifici per la beta.

Il vendor lock-in è reale. Una volta che gli agenti girano sull'infrastruttura di Anthropic, con i loro strumenti, il loro formato di sessione e il loro sandboxing, passare a un altro provider non è banale. Non è un dealbreaker — tutto il SaaS ha switching cost — ma è una considerazione che vale la pena nominare.

Le funzionalità avanzate che probabilmente si desiderano sono in research preview. Outcomes (auto-valutazione rispetto ai criteri di successo), multi-agent coordination e persistent memory richiedono tutte una richiesta di accesso separata e non sono ancora in disponibilità generale.

La prevedibilità dei costi su agenti long-running è difficile. Che il tempo idle sia gratuito è ottimo. Ma se l'agente entra in un loop non intenzionale di lavoro attivo — diciamo, una web search che continua a innescare altre ricerche — il conto può salire rapidamente. I budget alert sono obbligatori.

Chi dovrebbe adottarlo ora e chi dovrebbe aspettare

Adottare ora se:

Si è già su modelli Claude per i propri workload agente
Si sta manutenendo un setup n8n / LangGraph / harness custom e la tassa infrastrutturale sta uccidendo la velocity
Il proprio use case è lavoro async long-running — ricerca, elaborazione di documenti, content pipeline, lead enrichment
Governance, audit e permessi con scope definito sono requisiti che i propri buyer devono approvare

Aspettare se:

Si ha bisogno di orchestrazione multi-modello tra Claude, GPT e modelli open-source nello stesso agent loop
Il proprio workload è una semplice automazione deterministica meglio servita da n8n o Zapier
Si opera in una giurisdizione con regole di data residency stringenti che Anthropic non soddisfa ancora per la propria classe di dati
Si hanno bisogno di funzionalità ancora in research preview (multi-agent coordination, persistent memory)

FAQ

Cos'è Claude Managed Agents? Claude Managed Agents è un servizio hosted sulla Claude Platform che fornisce il runtime completo per agenti AI in produzione — inclusi esecuzione di codice in sandbox, checkpointing, gestione delle credenziali, permessi con scope definito, identity management e execution tracing. Si definisce l'agente; Anthropic lo esegue.

Quando è stato lanciato? La beta pubblica è stata lanciata l'8 aprile 2026. Tutti gli endpoint richiedono l'header beta managed-agents-2026-04-01.

Quanto costa? Tariffe standard dei token API Claude per l'utilizzo del modello, più $0,08 per session-hour di runtime attivo, più $10 per 1.000 web search. Il tempo idle non viene fatturato.

Come si confronta con n8n? n8n è uno strumento di workflow automation con funzionalità AI aggiunte. Managed Agents è un agent runtime — progettato appositamente per task di reasoning open-ended dove il passo successivo dipende dal risultato del precedente. Usare n8n per pipeline deterministiche; usare Managed Agents per lavoro agente autonomo.

È possibile il self-hosting? No. Managed Agents è un servizio hosted esclusivamente sulla Claude Platform. Per chi necessita di self-hosting, LangGraph o un harness custom è la risposta giusta.

Quali clienti del lancio lo stanno usando? Notion, Rakuten, Asana, Atlassian e Sentry sono i clienti pubblici del lancio, con use case che spaziano da coding agent a productivity teammate a elaborazione di documenti.

È necessario essere sviluppatori per usarlo? Per casi d'uso di base, no — è possibile definire agenti in linguaggio naturale attraverso la UI della Claude Platform. Per qualsiasi cosa di livello production, una conoscenza operativa di API e YAML è sostanzialmente richiesta.

Il punto per le aziende europee

Se si sta osservando il settore degli agenti chiedendosi quando diventa reale per le aziende che non hanno un team di AI engineering dedicato, questo è probabilmente quel momento. Non perché Managed Agents sia perfetto — è un prodotto in beta con limitazioni reali — ma perché è la prima offerta credibile "gestiamo noi l'infrastruttura" da un frontier lab che è sia prezzata in modo sensato che architettata seriamente.

Per le PMI europee e le aziende mid-market, l'implicazione pratica è che il calcolo build-vs-buy è appena cambiato. Costruire un agente di produzione significava un progetto infrastrutturale di tre-sei mesi più manutenzione continua. Ora significa scrivere una buona specifica e pagare $0,08 per ora attiva. Questo sposta "dovremmo rilasciare un agente per questo workflow?" da una decisione capex a una decisione opex.

Se si è un founder, CTO o operator che cerca di capire cosa fare concretamente con tutto questo — non solo annuire con saggezza su LinkedIn — questa è la conversazione che facciamo ogni settimana ad areza.digital. Aiutiamo le aziende europee a progettare, costruire ed eseguire agenti AI in produzione.

Prenota una chiamata conoscitiva di 30 minuti →

Scritto da Nikita Janochkin, fondatore di areza.digital. Fonti: documentazione ufficiale della Claude Platform (platform.claude.com/docs), engineering blog di Anthropic "Scaling Managed Agents: Decoupling the brain from the hands," annuncio di lancio su claude.com, The New Stack, SiliconANGLE, FindSkill.ai, engineering blog di Epsilla. Pricing e disponibilità delle funzionalità verificati sulla documentazione live al 9 aprile 2026. Ultimo aggiornamento: 9 aprile 2026.

Smetti di perdere lead a causa di un sito lento

Prenota un audit di attrito gratuito e scopri esattamente dove il tuo sito perde denaro.

Prenota una chiamata →