Deep Agents

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 1 di 16. Creare un coding agent da zero è divertente per circa un'ora. Poi il modello raggiunge il context limit, dimentica completamente il task originale e sovrascrive un file critico con della spazzatura. Per impedire al tuo assistente di distruggere il proprio workspace, hai bisogno di quello che viene chiamato il pattern agent harness. Spesso si incontra questo pattern tramite una libreria chiamata Deep Agents. Prima di tutto, una breve precisazione. Deep Agents non è LangChain e non è LangGraph. È una libreria Python standalone che si appoggia a questi tool, impacchettandoli in un coding assistant pronto all'uso. Se provi a creare un coding assistant da solo, di solito inizi con uno script di base. Prendi uno user prompt, lo invii a un Large Language Model e stampi il codice che ti restituisce. Questo è solo un semplice chat loop. Funziona bene per rispondere a una singola domanda. Ma presto, vorrai che il modello implementi effettivamente una feature su più file sulla tua macchina. Ed è qui che l'illusione svanisce. Ti rendi conto di dover scrivere manualmente dei tool per leggere i file, cercare nelle directory e applicare i code diffs in modo sicuro. Hai bisogno di un sistema per tenere traccia del context su decine di step senza superare il token limit. Devi creare una task list persistente in modo che il modello ricordi effettivamente cosa ha appena fatto e cosa deve fare dopo. Finisci per passare tutto il tempo a scrivere boilerplate per il file system e lo state management, invece di concentrarti sull'agent behavior. Questo è esattamente ciò che risolve il pattern agent harness. Un harness è il layer infrastrutturale che avvolge il raw language model. Trasforma un fragile chat loop stateless in un agent durevole e long-running. In Deep Agents, questo harness fornisce il memory management, le operazioni sul file system e la logica di pianificazione step-by-step direttamente out of the box. Gli assegni un goal ad alto livello e lo punti verso una directory locale. L'harness si fa carico del lavoro ripetitivo di fornire al modello un ambiente sicuro per pianificare, editare e verificare il codice. Ecco il punto chiave. Il vantaggio principale di usare un harness indipendente come Deep Agents è che è completamente model-agnostic. Soluzioni strettamente integrate come il Claude Agent SDK o ecosistemi più datati come OpenAI Codex sono altamente ottimizzate, ma ti vincolano a un singolo provider. Se domani venisse rilasciato un modello più economico o più intelligente, migrare il tuo tightly coupled agent diventerebbe un enorme grattacapo. Poiché Deep Agents astrae l'ambiente dal reasoning engine, il language model diventa un componente completamente sostituibile. L'harness gestisce le task list, legge il file system e si occupa dell'error recovery. Questa logica rimane identica sia che tu usi Anthropic, OpenAI o un modello locale open-weight. L'harness è il telaio dell'auto e il language model è solo il motore. Il vero valore di questo pattern è l'affidabilità. Un agent è capace solo quanto l'ambiente in cui opera e, senza un harness che lo ancori a un file system reale e a un piano concreto, anche il modello più intelligente è solo un generatore di testo che gira a vuoto. Se vuoi dare una mano a far andare avanti lo show, puoi cercare DevStoriesEU su Patreon; qualsiasi supporto lì è di grande aiuto ed è sempre apprezzato. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 2 di 16. Non hai bisogno di un enorme diagramma di architettura o di centinaia di righe di boilerplate per far sì che un language model pianifichi autonomamente il proprio lavoro. Ti basta una singola function call per attivare il Core Loop. L'entry point per questo comportamento è una funzione chiamata create deep agent. È in questa funzione che definisci il cervello della tua applicazione. Invece di importare librerie client separate e scrivere wrapper custom, indichi alla funzione quale modello utilizzare tramite una semplice string separata da due punti. Passi il provider, due punti e il nome esatto del modello. Potresti usare anthropic due punti claude-sonnet-4-6, oppure openai due punti gpt-5.4. Il framework legge questa string e gestisce l'inizializzazione specifica dietro le quinte. Un agente ha bisogno di un modo per interagire con il mondo, che tu gli fornisci tramite dei tool. Un tool è semplicemente una funzione Python standard che esegue un'azione specifica. Mettiamo caso che tu stia costruendo un agente per la ricerca su internet. Scriveresti una funzione che accetta una query, chiama un'API di ricerca e restituisce del testo. Passi questa funzione di ricerca direttamente alla tua chiamata create deep agent come parte di una lista. Il tuo agente ora è pronto. Per avviare il processo, chiami il metodo run sul tuo nuovo agente e gli passi un prompt, ad esempio chiedendogli di cercare e sintetizzare notizie recenti sul quantum computing. A questo punto entra in gioco il core loop. Ecco il punto chiave. Gli sviluppatori spesso pensano di dover scrivere system prompt complessi per forzare il modello a suddividere i task, o di dover creare parser custom per tracciarne i progressi. Tu non devi fare nulla di tutto questo. Quando chiami create deep agent, l'harness inietta automaticamente un tool integrato chiamato write todos. Non sei mai tu a scrivere o gestire questo tool. Fa parte del core engine. Prima ancora che l'agente tocchi il tuo tool di ricerca, il core loop forza il modello a usare il tool write todos. L'agente valuta il tuo prompt e genera una lista strutturata di step. Solo dopo che questo piano è stato finalizzato inizia la fase di esecuzione. Il loop itera sul piano passo dopo passo. L'agente esamina il suo primo task, riconosce di aver bisogno di informazioni e chiama il tuo tool di ricerca su internet. Legge il raw text restituito dal motore di ricerca e aggiorna la sua memoria interna. Il loop quindi verifica se l'obiettivo primario è stato raggiunto. Se i risultati della ricerca sono incompleti, l'agente passa all'elemento successivo della sua todo list, magari formulando una nuova query di ricerca per trovare i dettagli mancanti. Questo ciclo di selezione di un tool, osservazione del risultato e verifica del piano continua autonomamente. Quando il loop conferma che tutti i task necessari sono stati completati, smette di chiamare i tool. L'agente analizza i dati raccolti, genera una risposta finale sintetizzata e te la restituisce. La caratteristica distintiva del core loop è che trasforma un generatore di testo statico in un problem solver attivo, obbligandolo strutturalmente a pianificare prima di agire. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 3 di 16. Dare a un agente autonomo l'accesso raw al tuo computer è un ottimo modo per cancellare accidentalmente la tua home directory. Se un agente decide di riorganizzare i tuoi file o testare uno script, devi assicurarti che sia confinato in un'area sicura. Ecco perché usiamo il Pluggable Filesystem. Quando dai a un Deep Agent dei tool per leggere o modificare un file, questi tool non si collegano direttamente al tuo sistema operativo. Vengono invece mappati su un backend. Un backend è un ambiente di storage che stabilisce dove e come risiedono effettivamente i file. L'ambiente di default è lo StateBackend. Si tratta di un drive fantasma effimero, tenuto interamente in memoria. Supponi di chiedere a un agente di scrivere una bozza veloce di un'email o di manipolare dei dati testuali. L'agente crea il file, lo rilegge e lo modifica, tutto all'interno dello StateBackend. Quando il tuo script finisce di girare, quella memoria viene svuotata e i file svaniscono. È completamente isolato e perfettamente sicuro. Ma cosa succede quando vuoi che l'agente generi un vero progetto Python sul tuo disco locale? La memoria non basta più. Fai un upgrade dei permessi dell'agente collegando un FilesystemBackend. Questo collega i tool per i file dell'agente al tuo vero hard drive. Per mantenerlo sicuro, inizializzi il backend con un parametro chiamato virtual mode impostato su true. Ecco il punto chiave. Il virtual mode crea un limite di path rigoroso. Definisci una base directory, e l'agente opera al suo interno. Se l'agente prova a leggere un file di sistema sensibile fuori da quella cartella, il backend blocca la richiesta. Intrappola l'agente in un workspace designato. Tuttavia, qui c'è un pericoloso malinteso. Molti developer danno per scontato che abilitare il virtual mode crei una sandbox completamente sicura. Non è così. Il filesystem backend controlla solo le operazioni sui file. Se vuoi anche che il tuo agente esegua comandi da terminale, devi collegare un terzo tipo di backend chiamato LocalShellBackend. Il LocalShellBackend dà all'agente un nuovo tool chiamato execute. Questo permette all'agente di lanciare comandi shell sulla tua macchina host. Se colleghi un LocalShellBackend, il virtual mode del tuo filesystem backend non ti proteggerà dai comandi da terminale distruttivi. L'agente potrebbe eseguire uno script di cancellazione a livello di sistema, e la shell lo farebbe girare, bypassando completamente le tue restrizioni sui path dei file. L'accesso ai file e l'esecuzione nella shell sono funzionalità distinte mappate su backend distinti. Se il tuo agente ha solo bisogno di scrivere codice, limitati al FilesystemBackend. Collega il LocalShellBackend solo se l'agente deve assolutamente compilare o far girare quel codice in locale. L'agente autonomo più sicuro non è quello con i prompt più intelligenti, ma quello deployato con uno state backend effimero che fisicamente non può toccare il tuo sistema operativo host. Questo è tutto per oggi. Grazie per l'ascolto: vai a creare qualcosa di fantastico.

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 4 di 16. L'errore più comune nel design degli agenti è scrivere un system prompt enorme, di quattromila parole, che descrive nel dettaglio il funzionamento di ogni singolo tool e fare l'hardcoding di dati specifici della sessione. Ti ritrovi con un prompt fragile, context window esaurite e un incubo quando gestisci più utenti. I system prompt dinamici risolvono questo problema assemblando al volo le istruzioni esatte di cui il language model ha bisogno. Pensa al context engineering in Deep Agents come a una catena di montaggio dinamica. Invece di scrivere un blocco di testo statico, il prompt finale inviato al language model viene costruito a partire da tre layer distinti. Questi layer sono il system prompt statico, i tool prompt e il runtime context. Si uniscono esattamente al momento dell'esecuzione per formare l'input context completo. Il primo layer è il system prompt statico. Questa è la parte che scrivi manualmente. Definisce la persona dell'agente, le sue regole principali e il suo obiettivo finale. È volutamente semplice. Potresti dire all'agente che è un assistente per le query a database, ma non gli dici come connettersi al database, quale formattazione si aspetta il tool o qual è il session ID dell'utente. Mantieni questo layer strettamente focalizzato sulla business logic di alto livello. Il secondo layer è costituito dai tool prompt, ed è qui che entra in gioco il framework. Deep Agents inietta automaticamente le istruzioni d'uso necessarie per i tool specifici che colleghi all'agente. Se fornisci all'agente un tool per leggere un file, il framework aggiunge dinamicamente lo schema esatto per quel tool. Insieme agli schemi, inietta un planning prompt integrato. Questo planning prompt istruisce il modello su come mettere in sequenza in modo efficace i tool disponibili per risolvere un problema. Non devi mai scrivere manualmente le istruzioni su come il modello debba formattare un tool call o pianificare i suoi step di esecuzione. Il framework gestisce automaticamente questi meccanismi. Quando aggiungi o rimuovi un tool dall'agente, i tool prompt sottostanti si aggiornano all'istante senza che tu debba toccare il system prompt principale. Ora, dobbiamo chiarire una fonte comune di confusione tra il system prompt statico e il runtime context. Il prompt statico viene definito quando inizializzi l'agente. Il runtime context, invece, viene iniettato esattamente quando invochi l'agente per eseguire un'operazione. Considera uno scenario in cui stai sviluppando un'applicazione multi-tenant. Quando un utente specifico fa una domanda, l'agente ha bisogno del database connection ID univoco di quell'utente per recuperare i suoi dati. Se tu inserissi quell'identificatore nel system prompt statico, dovresti ricreare l'intero agente da zero per ogni singola richiesta dell'utente. Invece, usi il runtime context. Ecco il punto chiave. Passi un context object tramite una feature chiamata ToolRuntime proprio nello step di invocazione. Fornisci al framework un dizionario che contiene lo specifico database connection ID per quella sessione. Il framework prende questo runtime context, lo unisce al tuo prompt statico e alle istruzioni dei tool generate automaticamente, e lo collega direttamente ai tool che lo richiedono. Il tool viene eseguito usando il connection ID corretto, fornito dinamicamente. Il tuo system prompt statico rimane completamente pulito da identificatori temporanei, API key o session token. Al millisecondo dell'esecuzione, la catena di montaggio dinamica finisce il suo lavoro. Deep Agents concatena le tue istruzioni principali, i tool schema generati dinamicamente, i planning prompt e i dati di invocazione specifici in un unico input context coeso. Il modello riceve un set di istruzioni completo e perfettamente formattato, su misura per quello specifico utente e per quel task specifico. Gli agenti più scalabili non sanno nulla del loro ambiente fino al momento esatto in cui gli viene chiesto di agire. Per questo episodio è tutto. Ci sentiamo alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 5 di 16. La maggior parte degli agenti IA si blocca o fallisce silenziosamente nel momento in cui legge un system log o un data dump che supera la dimensione massima del prompt. Deep Agents previene questo problema gestendo i limiti di context come un sistema operativo gestisce la memoria virtuale. Questo processo si chiama Context Compression e Offloading. I Large Language Model hanno un limite massimo alla quantità di testo che possono elaborare in una volta sola. Se un agente tenta di tenere troppi dati nel suo prompt attivo, il modello lancia un errore e si ferma. Deep Agents gestisce questo token overflow monitorando costantemente la dimensione dei dati della conversazione. Funziona esattamente come un computer che fa paging della RAM su un disco rigido quando la memoria è piena. Lo spazio di lavoro attivo viene mantenuto leggero, mentre il grosso dei dati viene spostato al sicuro. Questo meccanismo opera in due fasi distinte. La prima fase gestisce i picchi di dati immediati e massicci provenienti da tool esterni. Il framework monitora il token count di ogni singolo tool input e tool result. La soglia massima per questo controllo è di ventimila token. Se un'operazione supera questo limite, il sistema intercetta il payload prima ancora che raggiunga il language model. Pensa a un agente che esegue una query che recupera un enorme database dump da trentamila token. Un agente standard tenta di inserire l'intero payload direttamente nella history della conversazione, causando immediatamente un token overflow. Deep Agents adotta un approccio diverso. Intercetta questa risposta enorme, fa l'offload dell'intero testo in un nuovo file sul filesystem di backend, e sostituisce il payload nella conversazione con una semplice preview di dieci righe. L'agente legge la preview e riceve un file path che punta ai dati completi. L'agente sa esattamente cosa ha trovato, ma il prompt attivo rimane completamente pulito. Questo gestisce i picchi improvvisi di dati. La seconda fase gestisce il lento accumulo di una conversazione standard. Mentre un agente esegue un processo lungo e multi-step, il continuo botta e risposta della history consuma lentamente i token disponibili. Deep Agents monitora l'utilizzo totale della context window rispetto ai limiti del modello. Quando il prompt attivo raggiunge l'ottantacinque percento della context window totale disponibile, si attiva automaticamente un processo di summarization in background. Il sistema prende il blocco di messaggi più vecchio nella history corrente e usa un language model per generare un summary denso e fattuale di quegli eventi. Poi sostituisce quel vecchio blocco di messaggi nel prompt attivo con il summary appena generato, riportando all'istante il token count a un livello di lavoro sicuro. Ecco il punto chiave. Gli sviluppatori spesso danno per scontato che riassumere la conversazione distrugga per sempre la history originale. Non è affatto così. Prima di qualsiasi summarization, i messaggi originali vengono scritti sul filesystem come record canonico e permanente. I dati raw non vanno persi. Se in seguito l'agente capisce di aver bisogno di un dettaglio molto specifico da uno step precedente che non è finito nel summary, può usare i suoi search tool per fare una query su quel filesystem e recuperare l'esatto testo originale. Combinando gli offload immediati su filesystem per i tool result più massicci con la summarization dinamica per le history di lunga durata, un agente può operare all'infinito senza soffocare nel suo stesso context. Grazie per aver ascoltato, e buon coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 6 di 16. Se il tuo agente IA principale legge dieci pagine web per rispondere a una singola domanda, prima o poi dimenticherà qual era il prompt originale. Tutto quel rumore intermedio sovrasta le istruzioni. La soluzione è la Context Isolation con subagenti sincroni. Pensa a questo come a un pattern di clean architecture per i tuoi modelli linguistici. Quando un singolo agente ha accesso a decine di tool ed esegue lunghi loop iterativi, la sua context window si riempie rapidamente di dati grezzi, messaggi di errore e output dei tool. Questo context bloat degrada la capacità di ragionamento del modello. Invece di un unico agente enorme che cerca di fare tutto, hai bisogno di un supervisor. L'agente principale agisce come un manager. Delega il lavoro disordinato e pieno di token agli specialisti e riceve solo un report finale pulito e formattato. Spesso si confondono i subagenti con una chat room multi-agente continua, dove diversi modelli si siedono e discutono idee tra di loro. Ma non è questo il caso. I subagenti sincroni sono strettamente effimeri. Vengono istanziati per eseguire un job specifico, girano in modo completamente autonomo nel loro spazio di memoria isolato finché il job non è finito, e restituiscono un singolo risultato finale al supervisor. Una volta consegnato quel risultato, scompaiono. Considera uno scenario specifico. Il tuo agente principale ha il task di scrivere un market briefing, e ha bisogno di dati sui recenti trend economici. Invece di invocare direttamente un tool di web search per cinque volte e inquinare la sua context window con il testo grezzo dei siti web, il supervisor delega il problema. Attiva un subagente researcher. Questo researcher effimero entra nel suo loop isolato. Fa le cinque ricerche su Google, legge i risultati disordinati, sintetizza le informazioni e scrive un singolo paragrafo di riassunto. Passa solo quel paragrafo indietro al supervisor. Il supervisor ottiene esattamente ciò di cui ha bisogno, e il suo context rimane intatto. Per configurarlo, definisci i tuoi specialisti usando dei semplici dictionary. Li passi al parametro subagents quando costruisci il tuo agente principale. Ogni dictionary è una specifica del subagente che richiede quattro informazioni. Primo, fornisci un nome, come researcher o calculator. Secondo, fornisci una description. Questa è la parte che conta. Il supervisor legge questa description per decidere quale specialista assumere per un dato problema. Terzo, fornisci i tool, dando a questo specifico subagente accesso isolato a cose come un web scraper o un database client. Infine, fornisci un system prompt, che governa il comportamento del subagente. Una volta passata questa lista di configurazioni all'agente principale, ottiene automaticamente l'accesso a un tool integrato chiamato task. Il supervisor non ha bisogno di sapere come istanziare i subagenti. Quando incontra un problema che corrisponde alla description di uno specialista, chiama semplicemente il tool task. Passa due argomenti: il nome del subagente da usare, e un'istruzione in plain text su cosa deve essere fatto. L'esecuzione del supervisor va in pausa. Il subagente fa lo spin up, lavora con i suoi tool, e alla fine termina. Al supervisor, il tool task restituisce semplicemente la risposta testuale finale come se fosse una normale function call. Anche se non definisci esplicitamente alcun dictionary, il framework ti offre un fallback. C'è un subagente di default general-purpose integrato. L'agente principale può usare questo specialista di default per fare l'offload dei passaggi di ragionamento complessi. Agisce come una tabula rasa, dando al modello una context window pulita per risolvere un puzzle logico denso senza sporcare la memoria del supervisor. Ecco il punto chiave. Imponendo confini rigorosi tra task isolati, impedisci che il lavoro intermedio di scratchpad degradi la qualità di ragionamento del tuo application flow principale. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, questo è Alex di DEV STORIES DOT EU. Deep Agents, episodio 7 di 16. Lasciare che un sistema autonomo esegua query SQL alla cieca è un ottimo modo per fare accidentalmente il drop di un database di produzione. Se vuoi che il tuo agent operi nel mondo reale, hai bisogno di un meccanismo per intercettarlo prima che faccia qualcosa di distruttivo. È qui che entrano in gioco gli interventi Human-in-the-Loop. L'idea di base è semplice. Metti in pausa l'agent poco prima che esegua un'operazione sensibile, chiedi indicazioni a un umano e poi riprendi l'esecuzione in base a quel feedback. Prima di guardare i meccanismi, c'è un errore comune da evitare. LangGraph richiede memoria per mettere in pausa e riprendere lo stato. Se provi a configurare un intervento Human-in-the-Loop senza impostare un checkpointer, l'intervento fallirà. Il sistema ha bisogno di un persistence layer, come un memory saver, per congelare l'execution graph e salvare le variabili correnti mentre aspetta che un umano risponda. Collega sempre prima un checkpointer. Non tutti i tool hanno bisogno di una revisione umana. Controllare il meteo o leggere un file di log è generalmente sicuro. Eliminare file o alterare i record di un database richiede un controllo rigoroso. Gestisci questa categorizzazione del rischio usando il parametro di configurazione interrupt on. Quando inizializzi il tuo agent o definisci il tuo tool node, passi una lista di nomi di tool a questo parametro. Se l'agent tenta di chiamare un tool che non è nella lista, viene eseguito immediatamente. Se prova a chiamare un tool che è nella lista, l'esecuzione va in pausa. Vediamo uno scenario concreto. Hai un agent con un tool per il database chiamato execute. Aggiungi execute alla tua lista interrupt on. L'agent decide che deve fare pulizia di alcuni vecchi dati e tenta di eseguire un comando drop sul database. Il sistema intercetta la chiamata e mette in pausa l'execution graph. Quando esegui il tuo agent, monitori l'oggetto result restituito dal framework. Nello specifico, controlli la presenza di una proprietà chiamata interrupts. Se la lista interrupts del result contiene dati, l'agent ha colpito un safety gate e sta aspettando il tuo input. A questo punto, l'operatore umano valuta l'azione in sospeso. Hai tre decisioni consentite che puoi rimandare all'agent. Queste sono approve, reject o edit. Se approvi, l'agent esegue il tool con gli argomenti originali. Se rifiuti, la tool call fallisce in modo controllato e l'agent riceve un messaggio di errore che lo invita a provare un approccio diverso. È qui che la cosa si fa interessante. La decisione edit ti permette di modificare l'azione prevista dall'agent prima che avvenga. Nel nostro scenario del database, l'agent sta tentando un pericoloso comando drop. Puoi intercettare quella richiesta, riscrivere gli argomenti del tool per eseguire invece una query select sicura, e rimandare quel payload modificato al sistema. Per sbloccare l'agent, lo invochi di nuovo, ma questa volta passi un oggetto command usando il parametro resume. All'interno di quel parametro resume, fornisci la tua decision string insieme a eventuali argomenti modificati. Il checkpointer recupera lo stato congelato, inietta la tua decisione umana direttamente nel grafo come se l'agent l'avesse originariamente pianificata in quel modo, e l'esecuzione continua. La cosa più importante da ricordare è che gli interventi Human-in-the-Loop ti danno molto più di un semplice pulsante di arresto di emergenza. La capacità di modificare gli argomenti del tool in corso d'opera ti permette di guidare in sicurezza un agent attraverso workflow complessi senza dover ricominciare da capo. Se vuoi supportare lo show, cerca DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 8 di 16. Magari guardi un agent che legge un file locale e pensi che questa capacità sia hardcoded nel profondo del core execution loop. Non è così. La magia dietro il file system di un agent è interamente gestita da middleware componibili che puoi estendere tu stesso. Oggi vediamo come estendere l'harness con i middleware. Deep Agents non è una black box. L'harness che gestisce la execution pipeline è altamente estensibile. Quando doti un agent di un file system o di una todo list, stai semplicemente attaccando dei middleware preconfezionati a quell'harness. Il middleware si trova esattamente al confine tra la decisione dell'agent di invocare un tool e l'effettiva esecuzione di quel tool. È un interceptor. Ti dà il controllo assoluto su cosa entra, cosa esce e cosa viene registrato durante lo scambio. Per scrivere il tuo middleware custom, crei una funzione interceptor e applichi uno specifico decorator chiamato wrap tool call. Questo decorator registra la tua funzione nell'harness. Quando l'agent innesca un tool, l'harness mette in pausa il flusso di default e passa il controllo alla tua funzione wrapped. All'interno di questo interceptor, ricevi i raw input arguments generati dall'agent, una reference al tool chiamato e il graph state corrente. Esegui manualmente il tool originale dall'interno della tua funzione, catturi il suo output e poi restituisci quell'output all'harness. Prendi ad esempio un middleware custom creato per monitorare un'API esterna. Vuoi intercettare ogni tool call all'API, loggare gli argomenti esatti usati dall'agent e tracciare le metriche di utilizzo per evitare i rate limit. La tua funzione wrap tool call cattura la richiesta prima che raggiunga la rete. Estrae il payload, lo scrive nei log della tua applicazione e poi esegue la richiesta API vera e propria. Una volta completata la richiesta, il middleware riceve i dati di risposta. Ora deve registrare che è stata effettuata una chiamata. Fai attenzione a questa parte. Quando tracciano le metriche di utilizzo, gli sviluppatori spesso cercano di usare delle class instance variables standard. Scrivono semplicemente qualcosa come self punto api call count più uguale a uno. Questo è un errore fatale. Deep Agents esegue regolarmente tool e subagent in parallelo. Se più tool si risolvono nello stesso momento e provano a mutare direttamente la stessa instance property, causerai delle race condition. I tuoi contatori si sovrascriveranno a vicenda, gli aggiornamenti verranno persi e le tue metriche saranno completamente sbagliate. Per gestire i dati in modo sicuro, devi invece aggiornare il graph state. Il graph state è progettato esplicitamente per gestire l'esecuzione parallela. Invece di modificare una variabile locale, il tuo middleware legge la metrica corrente dal graph state, calcola il nuovo valore e restituisce un oggetto di stato aggiornato insieme al risultato del tool. L'execution harness prende il controllo da lì. Elabora tutti gli aggiornamenti di stato in arrivo dalle esecuzioni parallele dei tool e li unisce in modo pulito senza collisioni. Indirizzando tutti i side effect e il tracciamento delle metriche attraverso il graph state, il tuo middleware rimane completamente thread-safe. Capire questo pattern sblocca l'intero framework. Smetti di trattare l'agent come un sistema chiuso e inizi a vederlo come una pipeline trasparente dove ogni azione può essere intercettata e misurata in modo sicuro. Questo è tutto per questo episodio. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 9 di 16. Avere un coding assistant basato sull'IA è fantastico, almeno finché non devi ricordargli per la cinquantesima volta che il tuo progetto richiede strict typing e variabili in snake case. La soluzione sono le convenzioni di progetto tramite file di memoria. L'ergonomia per i developer impone che i tuoi tool si adattino alla tua codebase, non il contrario. Non dovresti dover incollare una style guide in ogni singolo prompt. Deep Agents gestisce la cosa dando all'agent una memoria persistente tramite un file specifico chiamato AGENTS punto md. A volte le persone confondono la memoria con le skill. La memoria fornisce la tua baseline universale. Viene sempre caricata allo startup, il che la rende perfetta per le convenzioni globali e le regole architetturali. Le skill sono tool funzionali che l'agent carica dinamicamente solo quando un task specifico lo richiede. Oggi ci concentriamo esclusivamente sulla memoria. Quando inizializzi un agent e passi il parametro memory, il framework inietta automaticamente il contenuto del file AGENTS punto md direttamente nel context dell'agent prima che faccia qualsiasi lavoro. Questa operazione si basa sul protocollo memory-first, che detta tre fasi distinte per l'agent: Research, Response e Learning. Nella fase di Research, l'agent legge il file di memoria per capire l'environment. Nella fase di Response, genera il codice o risponde al prompt. Poi arriva la fase di Learning. Ecco il punto chiave. Non devi scrivere manualmente il file AGENTS punto md. L'agent aggiorna questo file in autonomia basandosi sul tuo feedback. Prendi uno scenario concreto. Chiedi all'agent di generare un nuovo endpoint API. Scrive codice funzionante, ma formatta le variabili in CamelCase. Rifiuti la pull request e rispondi che questo progetto usa rigorosamente lo snake case. L'agent corregge il codice, ma non si ferma lì. Entra nella fase di Learning, apre il file AGENTS punto md locale e appende una nuova regola che richiede lo snake case per tutte le variabili future. La prossima volta che chiedi un endpoint, l'agent legge quel file di memoria durante la sua fase di Research e scrive nativamente in snake case fin dall'inizio. Questo sistema di memoria persistente opera su due scope diversi. Il primo è lo scope globale. Questo file vive nella tua home directory utente, dentro una cartella punto deepagents. Lo usi per le tue preferenze personali da developer. Se preferisci sempre Python asincrono rispetto al codice sincrono in tutti i tuoi progetti, l'agent lo impara qui. Il secondo è lo scope di progetto. Questo file vive direttamente dentro la cartella della tua repository locale. È qui che vanno le regole specifiche della repository. Quando un agent viene eseguito, carica entrambi i file. Applica prima le tue preferenze globali, poi ci sovrappone le convenzioni specifiche del progetto. Dato che il file di memoria con scope di progetto vive nella tua repository, lo committi nel version control. Quando un nuovo developer si unisce al team ed esegue l'agent, la sua istanza locale eredita all'istante tutte le decisioni stilistiche che l'agent ha già imparato. Ogni errore corretto migliora in modo permanente la comprensione della tua repository da parte dell'agent, trasformandolo da un generico code generator a un maintainer altamente contestualizzato. Per questo episodio è tutto. Ci sentiamo alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 10 di 16. Se butti cinquanta guide diverse della documentazione API nel tuo system prompt, il tuo agent non diventerà più intelligente. Si distrarrà e fallirà nei task di base. Hai bisogno di un modo per dare a un agent una competenza profonda senza far esplodere la context window. La Progressive Disclosure con le skill risolve esattamente questo problema. Una skill in Deep Agents funziona come un upgrade modulare del cervello. Ti permette di pacchettizzare logiche complesse, come le regole di deploy su AWS o dei workflow personalizzati di data science, in una directory isolata. Per crearne una, ti basta creare una nuova cartella, darle il nome della tua skill e metterci dentro un file chiamato esattamente skill punto md. Un malinteso comune è che il framework appenda semplicemente l'intero contenuto di questo file al system prompt. Non è così. Farlo ci riporterebbe dritti al problema della context window sovraccarica, degradando le performance e aumentando i costi. Invece, il framework si basa su un pattern chiamato Progressive Disclosure, che avviene in tre fasi: Match, Read ed Execute. In cima al tuo file skill punto md, scrivi un blocco frontmatter. Questo è formattato in semplice YAML e contiene solo un nome e una breve descrizione. Ed ecco il punto chiave. Il framework carica solo quella breve descrizione nel system prompt iniziale. L'agent legge la descrizione e decide se fa match con la richiesta corrente dell'utente. Questa è la fase di Match. Se l'agent decide che la skill è rilevante, non cerca di indovinare cosa fare dopo. Usa attivamente un tool interno per recuperare il resto del file skill punto md. Questa è la fase di Read. Ora, l'agent ha le istruzioni complete e dettagliate caricate temporaneamente nella sua memoria di lavoro per questo specifico turno. Infine, passa alla fase di Execute, dove segue quelle istruzioni dettagliate per completare il task. Quando la conversazione passa a un altro argomento, il payload pesante viene scartato e l'agent torna al suo stato di base. Immagina uno scenario in cui vuoi creare una skill chiamata langgraph-docs. Il frontmatter del tuo file skill punto md ha una descrizione che dice che questa skill fornisce istruzioni e URL interni per cercare nella documentazione di LangGraph. Il corpo del file contiene quegli URL interni effettivi e la specifica metodologia di ricerca. Quando un utente chiede cosa sia LangGraph, l'agent controlla le sue skill attive. Vede la breve descrizione, capisce di aver bisogno di più informazioni per rispondere alla domanda e richiede il documento completo. Legge gli URL, esegue la ricerca e formula una risposta accurata. Senza la Progressive Disclosure, dovresti incollare tutti quegli URL nel prompt principale per ogni singola conversazione. Quando costruisci una libreria di skill, potresti imbatterti in conflitti in cui due skill cercano di definire istruzioni per task simili. Deep Agents risolve la cosa usando la precedenza delle fonti. La regola è semplice: l'ultima vince. Qualsiasi skill venga caricata per ultima farà l'override delle istruzioni in conflitto di quelle precedenti. Questo ti permette di impilare prima skill ampie e generiche, e poi aggiungere livelli di override molto specifici più avanti nella tua configurazione. L'esecuzione del tuo intero workflow agentico dipende da quanto bene scrivi quel frontmatter. Mantieni le tue descrizioni precise e i corpi delle tue skill molto dettagliati, perché l'agent leggerà il file completo solo se prima lo convinci con la descrizione. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 11 di 16. Un assistente intelligente non dovrebbe chiederti quale database usi ogni volta che inizi una nuova conversazione. Eppure, out of the box, la maggior parte degli agenti soffre di amnesia totale nel momento in cui un thread termina. Per risolvere questo problema, hai bisogno dei Long-term Memory Store. Quando esegui un agente, questo genera dei file. Spesso chi ascolta dà per scontato che se un agente scrive un file, questo viva per sempre. Non è così. Di default, tutto è effimero. I Deep Agents usano uno StateBackend, che memorizza i file nello state del thread di conversazione corrente. Quando quel thread si conclude, quei file scompaiono. Se vuoi una vera personalizzazione, in cui l'agente costruisce un database permanente delle preferenze dell'utente e della knowledge del progetto, hai bisogno di un approccio diverso. Hai bisogno dello StoreBackend. Questo si connette direttamente a un LangGraph Store persistente, mantenendo i dati al sicuro attraverso thread multipli. Ma non vuoi rendere persistente ogni singolo file temporaneo che il tuo agente crea. Ti serve un meccanismo per separare il lavoro effimero di scratchpad dalle memorie durature. È qui che entra in gioco il CompositeBackend. Pensalo come un router di traffico per il file system del tuo agente. Configuri il CompositeBackend con un fallback di default, di solito lo StateBackend effimero. Poi, registri esplicitamente una route per il tuo storage a lungo termine. Dici al router che qualsiasi file path che inizia con il prefisso di directory slash memories slash deve essere gestito dallo StoreBackend. Fai attenzione a questa parte. Questa persistenza non è automatica. Devi fare il routing specifico del path slash memories slash verso lo Store. Se salti questo step di routing, l'agente scriverà semplicemente i file di memoria nello state effimero, e verranno eliminati quando il thread termina. Una volta introdotto un database persistente, affronti un nuovo problema. Non puoi permettere che un utente legga le preferenze salvate di un altro utente. Per evitare questo, lo StoreBackend usa le namespace factory. Una namespace factory è semplicemente una funzione che inietta un layer di isolamento basato sul contesto corrente. Invece di salvare un file a livello globale, la factory genera un array di prefissi, come la parola users seguita dall'ID univoco dell'utente. Ogni volta che l'agente interagisce con lo StoreBackend, il database limita automaticamente lo scope dell'operazione a quell'esatto namespace utente. Vediamo come funziona nella pratica. Inizi la conversazione uno. Menzioni che stai sviluppando un'applicazione React. L'agente ne prende nota e scrive un riepilogo in un file chiamato project notes dot txt, posizionandolo specificamente all'interno della directory slash memories slash. Il CompositeBackend vede quel prefisso di directory, intercetta il comando di scrittura e lo instrada allo StoreBackend duraturo sotto il tuo namespace utente isolato. Domani, inizi la conversazione due. Questo è un thread completamente nuovo con zero contesto immediato. Fai una domanda sui framework di state management. Prima di rispondere, l'agente controlla la sua directory slash memories slash. Il CompositeBackend instrada la richiesta di lettura al persistent store. L'agente legge le tue note di progetto, vede i dettagli su React e fornisce una risposta altamente pertinente, su misura per il tuo specifico stack. Il contesto viene mantenuto perfettamente, anche se i thread sono separati. La persistenza cross-thread richiede una progettazione intenzionale, facendo il routing di directory specifiche verso un persistent store e proteggendole con namespace specifici per l'utente. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 12 di 16. Far scrivere codice a un'IA è impressionante. Farle eseguire ciecamente il codice appena scritto direttamente sul tuo laptop è una pessima idea. Per risolvere questo problema, hai bisogno di un posto sicuro in cui l'agente possa verificare la sua logica senza mettere a rischio la tua host machine. Ed è esattamente di questo che parliamo oggi: eseguire codice nelle sandbox. Se un agente non può eseguire codice, non può verificare se il suo codice funziona davvero. Si basa esclusivamente sui suoi training data per indovinare se uno script è corretto. Le sandbox offrono all'agente un playground sicuro in cui iterare, fallire e correggere gli errori basandosi sull'output reale dell'esecuzione. Prima di guardare i meccanismi, dobbiamo chiarire un malinteso comune. Potresti pensare che l'agente stesso debba essere deployato ed eseguito all'interno della sandbox. Ma non è così. I Deep Agent si basano sul pattern Sandbox as tool. La logica, la memoria e i prompt dell'agente vivono al sicuro sul tuo server. L'agente si limita a inviare comandi shell e codice tramite un'API verso un ambiente remoto e isolato. Questa interazione avviene tramite il tool execute. Quando l'agente decide che ha bisogno di eseguire uno script, chiama il tool execute e gli passa il blocco di codice generato. Questo tool inoltra il payload a un backend della sandbox. Provider come Modal, Daytona e Runloop forniscono questi ambienti. Fanno il provisioning di un container sicuro, eseguono il codice e restituiscono lo standard output o gli error log all'agente. La sandbox crea un rigoroso confine di isolamento tra lo spazio di esecuzione e il tuo sistema. Prendi un agente incaricato di creare un piccolo package Python e di eseguire una test suite usando pytest. L'agente si trova sul tuo server. Usa il tool execute per contattare un server remoto effimero. Per prima cosa, invia un comando per installare le librerie necessarie. Poi, scrive i file Python nella directory della sandbox. Infine, invia un comando per eseguire pytest. La sandbox esegue questi step e restituisce l'output del terminale. Se un test fallisce, l'agente legge l'errore dalla response dell'API, aggiorna il codice e chiama di nuovo il tool execute. L'agente può fare build, testare e ripulire tutto, il tutto mentre la tua host machine rimane completamente intoccata. Quando configuri un backend per la sandbox, devi definire il suo lifecycle. Ci sono due approcci principali. Il primo è thread-scoped. Qui, la sandbox è legata a uno specifico thread di conversazione. Quando la conversazione inizia, viene avviata una nuova sandbox. Quando la sessione utente termina, la sandbox viene distrutta. Questo garantisce un ambiente pulito per ogni interazione, ed è ideale per operazioni single-task in cui i dati non devono persistere. Il secondo approccio è assistant-scoped. In questo modello, la sandbox è legata all'agente stesso, indipendentemente dalla conversazione attiva. Ogni thread che interagisce con quell'agente condivide esattamente lo stesso state della sandbox. Se un thread installa una versione specifica di una libreria o scarica un dataset di grandi dimensioni, quei file rimangono disponibili per il thread successivo. Questa è la scelta giusta quando il tuo agente agisce come un worker persistente che richiede un workspace stabile e continuo. Ecco il punto chiave. L'ambiente di esecuzione detta le capacità dell'agente. Controllando il lifecycle della sandbox e imponendo rigorosi API boundaries, dai all'agente la libertà di fare errori senza compromettere la tua infrastruttura. Il vero potere di un agente non è solo generare codice, ma iterare sui fallimenti, e le sandbox remote offrono l'unico modo sicuro per permettere che questa iterazione avvenga in automatico. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 13 di 16. Lanci una query complessa, il tuo supervisor agent delega a tre subagent in parallelo, e il tuo utente resta a guardare un generico loading spinner per due minuti di fila. È una user experience terribile e, per risolverla, devi esporre esattamente cosa succede sotto il cofano. La risposta è la Subgraph Streaming UX. I workflow multi-agent sono intrinsecamente asincroni e lenti. Quando un main agent delega dei task, crea una black box. Se aspetti semplicemente il risultato finale combinato, l'utente pensa che l'applicazione si sia bloccata. Devi mandare in stream l'attività dei subagent direttamente al frontend. Un errore comune che i developer fanno qui è presumere che quando i subagent mandano in stream i token, questi vengano semplicemente appesi alla cieca all'output stream del main agent. Se fosse vero, gli output paralleli si mescolerebbero in un groviglio di testo incomprensibile. Invece, il framework gestisce la cosa isolando ogni singolo evento nel proprio namespace. Per farlo funzionare, usi il formato di streaming versione due e passi un flag impostando subgraphs a true quando chiami il tuo stream. Quando fai questo, lo stream non restituisce più chunk di testo grezzi. Restituisce dei dictionary. Ogni dictionary contiene tre key specifiche: type, ns e data. Type ti dice che tipo di evento stai guardando. Data contiene il payload effettivo o il token di testo. E ns sta per namespace. Questa è la parte che conta. Il namespace è una tuple che definisce il path esatto del node che ha generato l'evento. Se un chunk proviene dal main agent, la tuple del namespace è vuota. Se proviene da un subagent, il namespace contiene il path. Sembra una tuple contenente la parola tools seguita da un ID univoco del subagent. Mettiamo che tu stia costruendo una dashboard frontend. Un utente chiede al sistema di pianificare una vacanza. Il supervisor agent crea tre subagent separati: uno per i voli, uno per gli hotel e uno per le attività. Nel tuo codice frontend, fai un loop sullo stream in ingresso. Controllando la key del namespace su ogni chunk del dictionary, sai esattamente quale subagent ha generato quello specifico token. Puoi quindi indirizzare quei dati a componenti UI separati. Invece di un singolo spinner bloccato, il tuo utente vede tre loading bar o finestre di testo individuali che si riempiono con output in real-time, una accanto all'altra. A volte devi mandare in stream informazioni che non sono solo un token del language model. Magari vuoi pushare un aggiornamento di stato custom, come notificare la UI che è in corso una chiamata a un API esterna. Puoi farlo dall'interno di un node usando la funzione get stream writer. Recuperi il writer, gli passi il tuo dictionary custom, e lui inietta quei dati direttamente nello stream generale sotto il namespace del subagent corrente. Il frontend lo riceve esattamente come qualsiasi altro evento e aggiorna la loading bar specifica corretta. Se vuoi aiutarci a portare avanti lo show, puoi supportarci cercando DevStoriesEU su Patreon. La trasparenza multi-agent è fondamentalmente un problema di routing; mappare le tuple del namespace a componenti UI indipendenti è ciò che trasforma una frustrante black box in una user experience premium. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 14 di 16. E se potessi connettere il tuo agent da terminale locale al database proprietario della tua azienda senza scrivere una sola riga di codice Python? È proprio per questa funzionalità che oggi parliamo della CLI di Deep Agents e dei tool MCP esterni. L'SDK di Deep Agents fornisce una command line interface integrata out of the box. Avvii il processo e ottieni un terminal prompt dove puoi chattare con il tuo agent. Puoi gestire il cervello principale dell'agent direttamente da questo prompt. Se ti serve un reasoning engine più potente, ti basta digitare slash model seguito dal nuovo identificatore del modello. La CLI fa un hot-swap del provider all'istante, e tu continui la tua sessione. Ma un agent da terminale che si limita a chattare non è molto utile. Ha bisogno di accedere al tuo lavoro reale. Normalmente, per dare a un agent l'accesso a un repository GitHub o a un database locale devi scrivere del codice wrapper Python custom per gestire le chiamate API. La CLI evita tutto questo usando il Model Context Protocol, meglio noto come MCP. Spesso c'è confusione su cosa sia effettivamente MCP. Non è una libreria Python che importi nel codice del tuo agent. Un server MCP è un processo completamente separato o un URL remoto. Funziona come un wrapper standardizzato attorno a un sistema esterno. Quando la CLI si avvia, comunica con questo processo separato, chiedendogli quali tool fornisce, e li carica dinamicamente. Configuri questa connessione usando un semplice file di testo chiamato punto mcp punto json. Questo file è il core delle integrazioni zero-code. Quando lanci la CLI di Deep Agents, esegue un'auto-discovery. Cerca questa configurazione json nella tua directory corrente. Se la trova, si connette ai server elencati all'interno, registra i loro tool e li passa al tuo agent. Questo file di configurazione supporta due meccanismi di transport. Il primo è lo standard input e output, o stdio. Questo serve per i server locali. La CLI spawna il server come processo in background sulla tua macchina e ci comunica tramite gli stream standard del terminale. Il secondo tipo di transport si basa su HTTP e Server-Sent Events. Lo usi quando il tuo server MCP è hostato da remoto, magari all'interno di una rete aziendale privata. Dato che i server stdio eseguono comandi locali, la sicurezza è una priorità. La CLI mantiene un trust store locale per i server a livello di progetto. La primissima volta che la CLI rileva un nuovo comando per un server locale nel tuo file punto mcp punto json, si ferma e ti chiede un permesso esplicito. Una volta approvato, l'hash di quel comando viene salvato nel tuo trust store, e le run successive si connettono automaticamente. Vediamo uno scenario specifico. Vuoi che il tuo agent legga dei file dal tuo disco locale. Crei un file punto mcp punto json. All'interno, definisci un blocco server e lo chiami local-filesystem. Imposti il tipo di transport su stdio. Per la command line, gli dici di eseguire il tool del node package manager, npx, puntandolo a un community server pre-built chiamato server-filesystem, insieme al path della directory che vuoi esporre. Salvi il file e lanci la CLI di Deep Agents. Ecco il punto chiave. La CLI spawna automaticamente quel comando npx in background. Il server del filesystem fa il boot e fa un broadcast dicendo che ha dei tool per leggere file e listare le directory. La CLI intercetta quel broadcast ed equipaggia il tuo agent. Puoi digitare immediatamente nel tuo terminale, chiedendo all'agent di leggere il tuo file di log di sistema. L'agent capisce di avere il tool, chiama il processo in background, recupera i contenuti del file e risponde alla tua domanda. Hai appena dato a un sistema di AI un accesso sicuro al tuo disco locale usando poche righe di testo di configurazione. Disaccoppiando la logica dei tool dalla tua applicazione Python, MCP trasforma il tuo terminale da una semplice chat interface a un control center estensibile. Per questo episodio è tutto. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 15 di 16. Perché accontentarsi di un coding assistant generico quando puoi iniettare il tuo agente LangGraph altamente personalizzato direttamente nel tuo code editor? Il protocollo che tira fuori il tuo agente personalizzato dal terminale e lo porta nel tuo workflow quotidiano è Editor Integrations tramite ACP. Prima di proseguire, dobbiamo chiarire un conflitto tra acronimi. Probabilmente hai già sentito parlare di MCP, o Model Context Protocol. MCP collega il tuo agente a tool esterni, permettendogli di cercare in un database o leggere un file system. ACP, l'Agent Client Protocol, è completamente diverso. ACP collega il tuo agente a IDE esterni, come Zed o VSCode. Uno collega l'agente a dati esterni, l'altro lo collega al tuo workspace. ACP è un layer di comunicazione standardizzato. Definisce esattamente come un Integrated Development Environment invia selezioni di testo, strutture di file e prompt dell'utente a un agente AI. Detta anche come quell'agente restituisce code insertion, diff di file e risposte in chat. Implementando questo protocollo, il tuo deep agent personalizzato si comporta esattamente come un assistente pronto all'uso all'interno del tuo editor. La differenza è che possiede tutte le specifiche strutture di memoria, i prompt template personalizzati e i tool interni specializzati che ci hai integrato. Per colmare questo divario, installi il package deepagents-acp. L'integrazione richiede un brevissimo script Python che faccia da entry point. In questo script, istanzi il tuo deep agent preconfigurato. Poi, invece di avviare un web server o un loop a riga di comando, fai il wrap del tuo agente in un'interfaccia server ACP. Lo ottieni chiamando una funzione run dedicata e passandogli un oggetto AgentServerACP, che a sua volta fa il wrap della logica sottostante del tuo agente. Ecco il punto chiave. Quando configuri questo server, lo imposti per usare standard input e output, comunemente noti come modalità stdio. Questo è fondamentale perché significa che non ci sono porte di rete da gestire, regole del firewall da bypassare e web socket da debuggare. Il processo dell'agente si limita ad ascoltare le stringhe di testo in arrivo sullo standard input e a stampare le sue risposte strutturate sullo standard output. Successivamente, devi connettere il tuo editor a questo script. Considera l'editor Zed come scenario concreto. All'interno di Zed, apri il tuo file JSON delle impostazioni utente. Aggiungi un blocco di configurazione che istruisce l'editor a usare un agente personalizzato. Invece di far puntare Zed a un endpoint REST API remoto, lo punti direttamente al tuo eseguibile Python locale, fornendo il path del tuo nuovo script ACP come argomento principale. Quando avvii una sessione, l'editor fa lo spawn del tuo script Python come processo in background nascosto. Ogni volta che richiedi un inline edit o evidenzi una funzione per il refactoring, l'editor invia un messaggio ACP strutturato tramite standard input direttamente al tuo script in esecuzione. Il tuo agente personalizzato elabora la richiesta, attraversa il suo grafo di nodi interno, interroga la sua memoria e stampa la risposta formattata in ACP di nuovo sullo standard output. L'editor cattura quell'output e applica le modifiche al codice in modo nativo nella finestra della tua applicazione. Il takeaway più prezioso qui è il controllo. Instradando il tuo agente personalizzato tramite ACP su stdio, smetti di affidarti a un assistente generico e inizi a collaborare con un'entità che comprende intrinsecamente le convenzioni specifiche della tua codebase. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Deep Agents, episodio 16 di 16. Chiedi al tuo agente un refactor massiccio della codebase e la chat interface si blocca immediatamente. Rimani bloccato a fissare uno spinner per venti minuti, senza poter fare domande o cambiare idea. Per risolvere questo problema, hai bisogno di Background Worker con Async Subagent. I subagent standard sono sincroni. Bloccano il main thread. Il supervisor assegna un task e aspetta semplicemente che finisca. Gli async subagent cambiano completamente questa dinamica, girando come background worker non-blocking. Quando il supervisor assegna il lavoro, non aspetta il risultato. Riceve immediatamente un job ID e restituisce il controllo all'utente. La user interface rimane responsiva mentre il lavoro pesante viene fatto altrove. Configuri questi background worker usando la specifica Async SubAgent. Quando fai il deploy della tua applicazione su LangSmith Deployments, questi async subagent vengono hostati in modo indipendente. Il supervisor principale comunica con loro tramite transport protocol standard. Se fai il deploy del worker sullo stesso identico server del supervisor, comunicano usando ASGI, che è super efficiente per il local routing. Se il worker si trova su un server remoto separato, il supervisor si connette in HTTP. Per orchestrare questi remote worker, il supervisor è dotato di una suite specifica di async tool. Ripensa a quella richiesta di refactor della codebase. L'utente chiede la riscrittura. Il supervisor decide che ci vorrà molto tempo e chiama il tool start async task. Questo tool avvia il subagent coder e passa al supervisor un job ID. Il supervisor risponde all'utente, confermando che il background job è in esecuzione. Dato che il main thread è libero, l'utente può continuare la conversazione. Qualche minuto dopo, l'utente potrebbe chiedere come sta andando il refactor. Il supervisor chiama il tool check async task, passando il job ID, e recupera lo stato di esecuzione corrente dal worker. Ecco il punto chiave. L'utente non è tagliato fuori dal processo mentre il worker gira. Se l'utente si rende improvvisamente conto che il refactor deve forzare uno strict type hinting, può semplicemente dirlo al supervisor. Il supervisor a quel punto chiama il tool update async task. Questo invia nuove istruzioni di mid-flight steering direttamente al subagent in esecuzione, senza far ripartire il job da zero. Se l'utente decide che il refactor era un'idea pessima, il supervisor usa il tool cancel async task per terminare in modo pulito il background process. Un dubbio comune è come il supervisor si ricordi di questi job durante una sessione lunga. Col tempo, le chat history vengono compattate per risparmiare context token. Se il job ID esistesse solo come testo nella conversation history, il supervisor finirebbe per dimenticarlo e perderebbe le tracce del worker. Per evitare questo, i task metadata non vengono mai salvati solo nel chat log. Vengono salvati in uno state channel dedicato chiamato async tasks. Questo state channel opera in modo indipendente dalla message list, garantendo che i job ID attivi sopravvivano a qualsiasi compattazione della conversazione. Passare dalle blocking call ai background worker trasforma la tua architettura da una semplice chat interface a un motore di orchestrazione parallelo in grado di gestire workload massicci. Dato che questo conclude la nostra serie attuale, ti incoraggio a leggere la documentazione ufficiale, a provare a fare il deploy di un async worker tu stesso, o a visitare devstories dot eu per suggerire argomenti per la nostra prossima stagione. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.