NAME
agentic-infrastructure-stack — L'infrastruttura agentica e il nuovo backend
SYNOPSIS
cat agentic-infrastructure-stack.md
DESCRIPTION
Abbiamo parlato spesso di framework agentici. LangGraph, CrewAI, AutoGen, SDK vari, loop, tool calling, memory, planner, critic, supervisor. Tutte parole utili, per carità. Però più guardo gli agenti usati davvero, più mi sembra che la parte interessante si sia spostata sotto il livello del framework.
La domanda non è più solo: quale libreria uso per far ragionare un modello a step?
La domanda vera è: dove vive questo agente quando smette di essere una demo?
Perché un agente serio non è una funzione che chiama un modello e restituisce testo. È un piccolo sistema distribuito. Deve leggere contesto, usare strumenti, eseguire codice, toccare file, ricordare decisioni, chiedere permessi, fallire bene, ripartire, lasciare log, non bruciare il budget e non trasformarsi in una ruspa dentro il repository di produzione.
Il framework è il volante. L'infrastruttura è la strada, i freni, il garage, l'assicurazione e la persona che sa dove sono le chiavi.
Perché adesso se ne parla tanto
Nel 2023 e 2024 il discorso era molto centrato sul modello. Quale LLM? Quanto contesto? Quanto costa? Quanto è bravo a programmare?
Nel 2025 e 2026 la conversazione si è spostata. I modelli sono abbastanza bravi da fare lavoro reale, ma proprio per questo diventano visibili i pezzi noiosi: runtime, sicurezza, connettori, identità, osservabilità, code execution, deployment, rollback.
È il passaggio naturale da magia a ingegneria.
Quando un agente deve solo generare una risposta, basta una chat. Quando deve aprire una pull request, interrogare un database, chiamare un CRM, avviare un job, navigare un sito, leggere Slack, compilare codice e aggiornare un documento, serve un sistema operativo intorno.
Non in senso letterale. In senso organizzativo.
Il primo pezzo: un runtime dove l'agente può durare
Un agente lavora spesso a step. Guarda lo stato, sceglie un'azione, usa un tool, osserva il risultato, aggiorna il piano, ripete.
Se questo ciclo vive dentro una singola request HTTP, hai subito un problema. Alcune azioni sono lente. Alcune aspettano input umano. Alcune falliscono e vanno ritentate. Alcune devono sopravvivere a un deploy o a un timeout.
Qui entrano in gioco workflow durevoli, code, job background e state machine. Non sono glamour, ma sono la differenza tra un agente che sembra intelligente in demo e uno che puoi lasciare lavorare mentre vai a prendere un caffè.
Per me il runtime agentico deve rispondere a domande molto concrete:
- dove salvo lo stato tra uno step e l'altro?
- cosa succede se il processo muore a metà?
- posso mettere in pausa e chiedere approvazione?
- posso riprodurre una run per capire perché ha fatto quella scelta?
- posso limitare durata, memoria, strumenti e costo?
Vercel sta spingendo molto su questo fronte con AI SDK, funzioni, workflow e strumenti per costruire agenti dentro applicazioni web. Ma il punto non è solo Vercel. Il punto è che l'agente ha bisogno di una casa operativa, non di un singolo endpoint.
Il secondo pezzo: sandbox, perché l'agente deve poter sporcare senza rompere
Appena un agente scrive codice o esegue comandi, serve una sandbox.
Sembra una parola tecnica, ma l'idea è domestica: gli dai un banco da lavoro. Può aprire file, installare dipendenze, lanciare test, fare esperimenti, generare output. Se sbaglia, hai contenuto il danno. Se funziona, promuovi il risultato.
Una sandbox agentica dovrebbe avere alcune proprietà:
- filesystem isolato;
- limiti di CPU, memoria e tempo;
- rete controllata;
- segreti montati solo quando servono;
- log completi;
- possibilità di esportare artefatti;
- reset pulito tra run, quando necessario.
Vercel Sandbox va esattamente in questa direzione: ambienti isolati per eseguire codice, installare dipendenze, lavorare con file e produrre artefatti senza far girare tutto nel runtime principale dell'applicazione.
Questa cosa è più importante di quanto sembri. Molti prototipi agentici saltano direttamente dal modello al sistema reale. Il modello può chiamare tool. I tool possono fare cose. Sembra tutto elegante fino al primo comando sbagliato, alla prima dipendenza installata nel posto sbagliato, al primo token finito in un log.
La sandbox è il modo adulto di dire: prova pure, ma qui dentro.
Il terzo pezzo: MCP e il problema dei connettori
Il Model Context Protocol è diventato una delle parti più interessanti dell'ecosistema perché prova a standardizzare una cosa che altrimenti diventa rapidamente ingestibile: come un modello scopre e usa strumenti esterni.
Senza uno standard, ogni integrazione è una piccola isola. Un connettore per GitHub fatto in un modo, uno per Slack fatto in un altro, uno per database con una semantica diversa, uno per browser automation che non somiglia a niente.
MCP propone un linguaggio comune tra client e server: strumenti, risorse, prompt, autorizzazioni, trasporto, discovery. Non risolve magicamente governance e sicurezza, ma dà una grammatica.
E la grammatica conta. Quando un agente può collegarsi a molti strumenti, il problema non è solo "può farlo?". Il problema è "capisce cosa può fare, con quali limiti, per conto di chi, e lasciando quale traccia?".
Per me MCP non è hype perché "fa tool calling". Quello lo facevamo già. È hype perché sposta il baricentro dall'integrazione singola al catalogo operativo di strumenti.
In una buona architettura agentica, MCP diventa una specie di pannello patch:
- GitHub per codice e issue;
- Slack per contesto conversazionale;
- Linear o Jira per lavoro pianificato;
- database in sola lettura per analytics;
- browser o scraper controllato per siti esterni;
- storage documentale;
- ambienti di esecuzione isolati;
- sistemi interni esposti con permessi stretti.
La parte delicata è che un catalogo di tool senza politica è solo un modo più elegante per creare caos.
Il quarto pezzo: identità e permessi
Questa è la zona in cui tante demo fanno finta di niente.
Un agente agisce per conto di qualcuno. Quindi deve essere chiaro chi è il soggetto dell'azione.
Sta usando i permessi dell'utente? Di un service account? Di un workspace? Ha accesso temporaneo o permanente? Può leggere tutto o solo alcune risorse? Può scrivere? Può cancellare? Può mandare messaggi a persone reali?
Se non rispondi bene a queste domande, prima o poi costruisci un assistente con le chiavi di casa e nessuna memoria di chi gliele ha date.
La regola pratica che mi piace è questa: l'agente deve poter fare meno dell'umano, non più dell'umano. E quando deve fare qualcosa di più rischioso, deve fermarsi e chiedere.
Questo significa OAuth, token scoped, secret management, audit log, policy per tool, allowlist, approval step. Roba poco romantica. Roba necessaria.
Il quinto pezzo: memoria e contesto, ma senza accumulare spazzatura
Gli agenti hanno bisogno di memoria, ma la memoria è pericolosa quando diventa una soffitta.
Ci sono almeno tre tipi di memoria:
- memoria di run: cosa è successo in questa esecuzione;
- memoria di progetto: convenzioni, decisioni, vincoli;
- memoria personale o di team: preferenze, tono, rituali, processi.
Mettere tutto nel prompt è la scorciatoia. Funziona fino a quando non funziona più. La memoria utile va curata: indicizzata, aggiornata, scaduta, verificata, resa citabile.
Un agente che ricorda male è peggio di un agente che non ricorda. Perché parla con sicurezza.
Quindi l'infrastruttura deve prevedere retrieval, file di istruzioni, knowledge base, embedding quando serve, ma anche pulizia. Serve una cultura della memoria: cosa entra, chi lo approva, quando decade, come lo correggo.
Il sesto pezzo: osservabilità, eval e replay
Se un agente sbaglia, il log "ha chiamato il modello" non basta.
Vuoi vedere il percorso. Quale contesto ha ricevuto? Quali tool erano disponibili? Quale tool ha scelto? Con quali argomenti? Che risposta ha ottenuto? Quanto è costato? Dove si è bloccato? L'umano ha approvato qualcosa? L'errore è del modello, del tool, del prompt, del dato o del permesso?
Qui gli agenti somigliano più a sistemi distribuiti che a chatbot.
Servono trace leggibili, non solo log testuali. Serve poter rigiocare una run. Serve confrontare due versioni dello stesso agente su task noti. Serve misurare regressioni: non solo "risponde meglio", ma "chiude il ticket giusto senza toccare file non richiesti".
Gli eval agentici sono più difficili degli eval testuali perché includono azioni. Non basta confrontare una stringa attesa. Devi guardare sequenze, side effect, qualità dell'artefatto, tempo, costo, numero di interventi umani.
La cosa buffa è che torniamo sempre lì: ingegneria del software. Test, ambienti, trace, rollback. Solo che il codice adesso decide anche cosa fare dopo.
Il settimo pezzo: interfacce umane
L'agente non deve vivere solo in una chat.
Alcuni agenti hanno bisogno di una board. Altri di una pagina con stato e log. Altri di un bottone "approva". Altri di commenti inline. Altri ancora di una CLI.
La UI cambia il comportamento. Se l'unico modo per controllare un agente è scrivere un messaggio lungo, l'utente gli darà istruzioni vaghe. Se invece vede piano, diff, fonti, rischi e prossima azione, può intervenire in modo preciso.
Un'infrastruttura agentica decente include superfici di controllo:
- stato corrente;
- piano modificabile;
- artefatti prodotti;
- diff;
- richieste di approvazione;
- cronologia;
- pulsante stop;
- pulsante retry;
- permessi visibili.
Sembra banale, ma non lo è. La differenza tra "AI inquietante" e "assistente affidabile" spesso è solo che la seconda ti fa vedere dove ha le mani.
La stack mentale
Se dovessi disegnarla oggi, la stack agentica minima sarebbe questa:
- Modello: ragionamento, generazione, tool calling, multimodale se serve.
- Orchestrazione: loop, step, planner, policy, human-in-the-loop.
- Runtime durevole: workflow, queue, retry, pause, resume.
- Sandbox: code execution, file system isolato, limiti, artefatti.
- Tool layer: MCP, API interne, browser, database, repository.
- Identity layer: OAuth, scope, secret, audit, policy.
- Memory layer: contesto di progetto, retrieval, istruzioni, scadenza.
- Observability: trace, replay, eval, metriche di costo e qualità.
- Product surface: chat quando basta, dashboard quando serve, review quando conta.
Il framework agentico copre soprattutto i punti 2 e un pezzo del punto 1. Il resto è il lavoro vero.
Cosa farei in pratica
Se un team mi dicesse "vogliamo agenti in produzione", non partirei con dieci agenti.
Partirei da un workflow piccolo, ripetitivo e osservabile. Per esempio: aprire PR di manutenzione, aggiornare documentazione da issue chiuse, preparare una weekly review, triagiare bug duplicati, generare test per file toccati.
Poi metterei paletti molto chiari:
- niente scrittura senza branch o sandbox;
- niente segreti nel prompt;
- tool in allowlist;
- approvazione umana per azioni esterne;
- log e trace obbligatori;
- budget per run;
- output sempre ispezionabile.
Solo dopo allargherei.
Gli agenti non falliscono solo perché i modelli sbagliano. Falliscono perché li mettiamo in ambienti vaghi, con permessi confusi e aspettative teatrali.
La mia lettura
L'infrastruttura agentica è noiosa nel modo migliore.
Non è la parte che fa applaudire in demo. È la parte che ti permette di usare davvero la demo lunedì mattina, con persone vere, dati veri e conseguenze vere.
Il futuro degli agenti non sarà deciso solo da chi ha il modello più bravo. Sarà deciso da chi costruisce il posto migliore in cui farlo lavorare: isolato quando sperimenta, connesso quando serve, osservabile sempre, autorizzato con criterio e abbastanza umile da fermarsi quando non sa.
È lì che gli agenti smettono di essere un giocattolo e diventano infrastruttura.
Fonti
METADATA
- date: 2026-06-30
- reading: 9 min
- author: Filippo Spinella
- tags: AI, Agents, Infrastructure, Developer Tools, Vercel