Runtime per Agenti: Managed vs Self-Hosted — I Veri Compromessi

Un runtime per agenti managed è un servizio gestito da un vendor che esegue il loop del proprio agente AI: si scrivono i prompt e le definizioni degli strumenti, e il vendor si occupa di orchestrazione, retry e scaling. Il self-hosting significa gestire quel loop in autonomia. La scelta giusta dipende meno dai costi e più da chi deve vedere i propri dati e da quanto controllo si necessita sul comportamento in caso di errore.

La maggior parte dei founder non pensa affatto al runtime finché qualcosa non si rompe: una chiamata a uno strumento si blocca, una cascata di retry triplica il costo dell'LLM nel giro di una notte, oppure un cliente chiede dove vengono conservati i trascritti delle sue conversazioni. Di solito è in quel momento che "managed vs self-hosted" diventa una decisione reale, anziché un'impostazione predefinita.

Cosa fa davvero il runtime

Togliendo il marketing, un agent runtime gestisce quattro cose:

• Gestione dello stato tra i passaggi, affinché l'agente ricordi ciò che ha già tentato
• Esecuzione degli strumenti, chiamando le proprie API, database o servizi esterni
• Logica di retry e timeout quando un passaggio fallisce o si blocca
• Osservabilità, registrando cosa ha fatto l'agente e perché

Una piattaforma managed (LangGraph Cloud, l'offerta hosted di CrewAI, varie piattaforme verticali per agenti) fornisce tutti e quattro questi elementi di default, solitamente con una dashboard. Il self-hosting significa costruire o configurare ogni componente in autonomia, spesso su una coda (SQS, Redis) e un processo worker sotto il proprio controllo.

A cosa si rinuncia in ogni caso

Con un runtime managed, si rinuncia a:

• La visibilità su come vengono implementati esattamente retry e timeout, il che è rilevante quando un agente riprova silenziosamente un'azione non idempotente (addebitare una carta due volte, inviare un messaggio WhatsApp duplicato)
• Le garanzie sulla residenza dei dati, poiché prompt e output degli strumenti transitano tipicamente dai server del vendor — un problema reale per clienti in ambito sanitario o governativo che richiedono l'elaborazione nella propria regione
• La prevedibilità dei prezzi, perché la maggior parte dei vendor addebita per esecuzione o per token, in aggiunta al costo dell'LLM

Con il self-hosting, si rinuncia a:

• Il tempo. Costruire una logica di retry affidabile, la gestione dei dead-letter e l'osservabilità a livello di passaggio è un progetto che richiede settimane, non una semplice configurazione
• Il SLA del vendor. Se il proprio processo worker cade alle 2 di notte, quella è la propria rotazione di on-call
• Gli strumenti di debug già pronti. I vendor integrano UI per la riproduzione passo-passo che richiedono un notevole sforzo per essere replicate

Nessuna delle due opzioni è gratuita. La domanda è quale costo si può sostenere in questo momento.

Dove questo penalizza i founder nella pratica

Abbiamo visto questo compromesso manifestarsi più chiaramente nei pattern di esecuzione degli agenti, non solo nella scelta della location di hosting. Quando abbiamo costruito il nostro motore di outreach, la prima versione concatenava più chiamate LLM: una per estrarre informazioni su un prospect, una per scrivere l'email, una terza per raffinare il tono. Eseguire quella catena attraverso un layer di orchestrazione managed funzionava, ma ogni hop aggiuntivo introduceva latenza e un ulteriore punto in cui una chiamata a uno strumento bloccata poteva trasformarsi in un workflow in stallo che la dashboard non spiegava chiaramente. Collassare tutto in una singola chiamata che estraesse i dati (tramite un'istanza self-hosted di Firecrawl) e scrivesse l'email in un unico passaggio ha ridotto sia i costi sia la superficie di errore, perché semplicemente c'era meno stato del runtime da gestire o su cui perdere visibilità. La lezione si generalizza: meno parti in movimento ha il loop del proprio agente, meno conta la scelta tra managed e self-hosted — e più conta invece nel momento in cui il workflow supera i due o tre passaggi. È una variante dello stesso compromesso trattato in chiamata singola vs catene di agenti.

Il self-hosting serverless ha la sua trappola: se le chiamate agli strumenti dell'agente possono durare a lungo (in attesa di una API di terze parti lenta, di un parsing di documento, di un'approvazione human-in-the-loop), una piattaforma come AWS Lambda impone un limite rigido di 15 minuti per invocazione, secondo i limiti documentati da AWS. I team che non verificano questo aspetto in anticipo lo scoprono quando un workflow che funzionava perfettamente in fase di test inizia a troncarsi silenziosamente in produzione, sotto la latenza reale delle API.

Un framework decisionale di massima

Scegliere managed se:

• Si sta validando se il caso d'uso dell'agente funziona prima di impegnare tempo di ingegneria
• I dati che transitano non sono regolamentati né sensibili per i clienti
• Non si dispone ancora di qualcuno che si occupi dell'affidabilità infrastrutturale

Scegliere self-hosted se:

• L'agente tratta cartelle cliniche, dati finanziari o qualsiasi dato soggetto a requisiti di residenza — ragionamento analogo a quello per cui raccomandiamo il self-hosting di un LLM rispetto alle chiamate API una volta che la compliance entra in gioco
• Si opera a un volume tale per cui le tariffe per esecuzione sono una voce di costo reale, non un errore di arrotondamento
• Si necessita di una semantica di retry personalizzata perché alcune chiamate agli strumenti non sono sicure da ripetere ciecamente (pagamenti, messaggi in uscita, scritture su database)

In entrambi i casi, è fondamentale disaccoppiare la logica dell'agente (prompt, schemi degli strumenti, definizioni di stato) dall'SDK specifico del runtime. Se ogni funzione di strumento chiama direttamente un'API di orchestrazione proprietaria, migrare in seguito significa riscrivere l'agente, non semplicemente ridistribuirlo. È la stessa domanda di due diligence che affrontiamo nella nostra checklist di valutazione dei vendor per agenti AI: chiedere al vendor fin da subito cosa succede alla propria logica in caso di abbandono del servizio.

Il costo di manutenzione che nessuno quota in anticipo

Qualunque sia la scelta, è necessario pianificare la manutenzione continuativa, non solo la costruzione iniziale. I runtime managed richiedono comunque qualcuno che monitori il costo per esecuzione e aggiorni i prompt al variare del prodotto. I runtime self-hosted richiedono qualcuno che faccia patching sull'infrastruttura worker e gestisca gli incidenti. Analizziamo in dettaglio come si presenta generalmente questo costo continuativo in costo di manutenzione degli agenti AI: raramente è pari a zero, in nessuno dei due percorsi.

Se si sta valutando questa decisione per un prodotto specifico e si desidera un secondo parere su dove tracciare il confine in base ai propri dati e volumi, parliamone.