L'infrastruttura agentica e il nuovo backend

spinny:~/writing $ less agentic-infrastructure-stack.md

1 
2Abbiamo 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.
3 
4La domanda non è più solo: quale libreria uso per far ragionare un modello a step?
5 
6La domanda vera è: dove vive questo agente quando smette di essere una demo?
7 
8Perché 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.
9 
10Il framework è il volante. L'infrastruttura è la strada, i freni, il garage, l'assicurazione e la persona che sa dove sono le chiavi.
11 
12## Perché adesso se ne parla tanto
13 
14Nel 2023 e 2024 il discorso era molto centrato sul modello. Quale LLM? Quanto contesto? Quanto costa? Quanto è bravo a programmare?
15 
16Nel 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.
17 
18È il passaggio naturale da magia a ingegneria.
19 
20Quando 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.
21 
22Non in senso letterale. In senso organizzativo.
23 
24## Il primo pezzo: un runtime dove l'agente può durare
25 
26Un agente lavora spesso a step. Guarda lo stato, sceglie un'azione, usa un tool, osserva il risultato, aggiorna il piano, ripete.
27 
28Se 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.
29 
30Qui 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è.
31 
32Per me il runtime agentico deve rispondere a domande molto concrete:
33 
34- dove salvo lo stato tra uno step e l'altro?
35- cosa succede se il processo muore a metà?
36- posso mettere in pausa e chiedere approvazione?
37- posso riprodurre una run per capire perché ha fatto quella scelta?
38- posso limitare durata, memoria, strumenti e costo?
39 
40Vercel 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.
41 
42## Il secondo pezzo: sandbox, perché l'agente deve poter sporcare senza rompere
43 
44Appena un agente scrive codice o esegue comandi, serve una sandbox.
45 
46Sembra 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.
47 
48Una sandbox agentica dovrebbe avere alcune proprietà:
49 
50- filesystem isolato;
51- limiti di CPU, memoria e tempo;
52- rete controllata;
53- segreti montati solo quando servono;
54- log completi;
55- possibilità di esportare artefatti;
56- reset pulito tra run, quando necessario.
57 
58Vercel 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.
59 
60Questa 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.
61 
62La sandbox è il modo adulto di dire: prova pure, ma qui dentro.
63 
64## Il terzo pezzo: MCP e il problema dei connettori
65 
66Il 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.
67 
68Senza 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.
69 
70MCP propone un linguaggio comune tra client e server: strumenti, risorse, prompt, autorizzazioni, trasporto, discovery. Non risolve magicamente governance e sicurezza, ma dà una grammatica.
71 
72E 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?".
73 
74Per 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.
75 
76In una buona architettura agentica, MCP diventa una specie di pannello patch:
77 
78- GitHub per codice e issue;
79- Slack per contesto conversazionale;
80- Linear o Jira per lavoro pianificato;
81- database in sola lettura per analytics;
82- browser o scraper controllato per siti esterni;
83- storage documentale;
84- ambienti di esecuzione isolati;
85- sistemi interni esposti con permessi stretti.
86 
87La parte delicata è che un catalogo di tool senza politica è solo un modo più elegante per creare caos.
88 
89## Il quarto pezzo: identità e permessi
90 
91Questa è la zona in cui tante demo fanno finta di niente.
92 
93Un agente agisce per conto di qualcuno. Quindi deve essere chiaro chi è il soggetto dell'azione.
94 
95Sta 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?
96 
97Se 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.
98 
99La 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.
100 
101Questo significa OAuth, token scoped, secret management, audit log, policy per tool, allowlist, approval step. Roba poco romantica. Roba necessaria.
102 
103## Il quinto pezzo: memoria e contesto, ma senza accumulare spazzatura
104 
105Gli agenti hanno bisogno di memoria, ma la memoria è pericolosa quando diventa una soffitta.
106 
107Ci sono almeno tre tipi di memoria:
108 
109- memoria di run: cosa è successo in questa esecuzione;
110- memoria di progetto: convenzioni, decisioni, vincoli;
111- memoria personale o di team: preferenze, tono, rituali, processi.
112 
113Mettere tutto nel prompt è la scorciatoia. Funziona fino a quando non funziona più. La memoria utile va curata: indicizzata, aggiornata, scaduta, verificata, resa citabile.
114 
115Un agente che ricorda male è peggio di un agente che non ricorda. Perché parla con sicurezza.
116 
117Quindi 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.
118 
119## Il sesto pezzo: osservabilità, eval e replay
120 
121Se un agente sbaglia, il log "ha chiamato il modello" non basta.
122 
123Vuoi 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?
124 
125Qui gli agenti somigliano più a sistemi distribuiti che a chatbot.
126 
127Servono 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".
128 
129Gli 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.
130 
131La cosa buffa è che torniamo sempre lì: ingegneria del software. Test, ambienti, trace, rollback. Solo che il codice adesso decide anche cosa fare dopo.
132 
133## Il settimo pezzo: interfacce umane
134 
135L'agente non deve vivere solo in una chat.
136 
137Alcuni 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.
138 
139La 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.
140 
141Un'infrastruttura agentica decente include superfici di controllo:
142 
143- stato corrente;
144- piano modificabile;
145- artefatti prodotti;
146- diff;
147- richieste di approvazione;
148- cronologia;
149- pulsante stop;
150- pulsante retry;
151- permessi visibili.
152 
153Sembra banale, ma non lo è. La differenza tra "AI inquietante" e "assistente affidabile" spesso è solo che la seconda ti fa vedere dove ha le mani.
154 
155## La stack mentale
156 
157Se dovessi disegnarla oggi, la stack agentica minima sarebbe questa:
158 
1591. Modello: ragionamento, generazione, tool calling, multimodale se serve.
1602. Orchestrazione: loop, step, planner, policy, human-in-the-loop.
1613. Runtime durevole: workflow, queue, retry, pause, resume.
1624. Sandbox: code execution, file system isolato, limiti, artefatti.
1635. Tool layer: MCP, API interne, browser, database, repository.
1646. Identity layer: OAuth, scope, secret, audit, policy.
1657. Memory layer: contesto di progetto, retrieval, istruzioni, scadenza.
1668. Observability: trace, replay, eval, metriche di costo e qualità.
1679. Product surface: chat quando basta, dashboard quando serve, review quando conta.
168 
169Il framework agentico copre soprattutto i punti 2 e un pezzo del punto 1. Il resto è il lavoro vero.
170 
171## Cosa farei in pratica
172 
173Se un team mi dicesse "vogliamo agenti in produzione", non partirei con dieci agenti.
174 
175Partirei 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.
176 
177Poi metterei paletti molto chiari:
178 
179- niente scrittura senza branch o sandbox;
180- niente segreti nel prompt;
181- tool in allowlist;
182- approvazione umana per azioni esterne;
183- log e trace obbligatori;
184- budget per run;
185- output sempre ispezionabile.
186 
187Solo dopo allargherei.
188 
189Gli agenti non falliscono solo perché i modelli sbagliano. Falliscono perché li mettiamo in ambienti vaghi, con permessi confusi e aspettative teatrali.
190 
191## La mia lettura
192 
193L'infrastruttura agentica è noiosa nel modo migliore.
194 
195Non è 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.
196 
197Il 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.
198 
199È lì che gli agenti smettono di essere un giocattolo e diventano infrastruttura.
200 
201## Fonti
202 
203- [Vercel: How to build AI agents with Vercel and the AI SDK](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)
204- [Vercel Docs: Sandbox](https://vercel.com/docs/sandbox)
205- [Vercel Docs: Working with Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)
206- [Vercel Docs: MCP](https://vercel.com/docs/mcp)
207- [Model Context Protocol: Specification](https://modelcontextprotocol.io/specification)
208- [OpenAI: New tools for building agents](https://openai.com/index/new-tools-for-building-agents/)
209- [Cloudflare Blog: Agents on Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)
210

:L'infrastruttura agentica e il nuovo backendlines 1-210 (END) — press q to close

2Abbiamo 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.

4La domanda non è più solo: quale libreria uso per far ragionare un modello a step?

6La domanda vera è: dove vive questo agente quando smette di essere una demo?

8Perché 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.

10Il framework è il volante. L'infrastruttura è la strada, i freni, il garage, l'assicurazione e la persona che sa dove sono le chiavi.

12## Perché adesso se ne parla tanto

14Nel 2023 e 2024 il discorso era molto centrato sul modello. Quale LLM? Quanto contesto? Quanto costa? Quanto è bravo a programmare?

16Nel 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.

18È il passaggio naturale da magia a ingegneria.

20Quando 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.

22Non in senso letterale. In senso organizzativo.

24## Il primo pezzo: un runtime dove l'agente può durare

26Un agente lavora spesso a step. Guarda lo stato, sceglie un'azione, usa un tool, osserva il risultato, aggiorna il piano, ripete.

28Se 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.

30Qui 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è.

32Per me il runtime agentico deve rispondere a domande molto concrete:

34- dove salvo lo stato tra uno step e l'altro?

35- cosa succede se il processo muore a metà?

36- posso mettere in pausa e chiedere approvazione?

37- posso riprodurre una run per capire perché ha fatto quella scelta?

38- posso limitare durata, memoria, strumenti e costo?

40Vercel 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.

42## Il secondo pezzo: sandbox, perché l'agente deve poter sporcare senza rompere

44Appena un agente scrive codice o esegue comandi, serve una sandbox.

46Sembra 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.

48Una sandbox agentica dovrebbe avere alcune proprietà:

50- filesystem isolato;

51- limiti di CPU, memoria e tempo;

52- rete controllata;

53- segreti montati solo quando servono;

54- log completi;

55- possibilità di esportare artefatti;

56- reset pulito tra run, quando necessario.

58Vercel 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.

60Questa 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.

62La sandbox è il modo adulto di dire: prova pure, ma qui dentro.

64## Il terzo pezzo: MCP e il problema dei connettori

66Il 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.

68Senza 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.

70MCP propone un linguaggio comune tra client e server: strumenti, risorse, prompt, autorizzazioni, trasporto, discovery. Non risolve magicamente governance e sicurezza, ma dà una grammatica.

72E 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?".

74Per 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.

76In una buona architettura agentica, MCP diventa una specie di pannello patch:

78- GitHub per codice e issue;

79- Slack per contesto conversazionale;

80- Linear o Jira per lavoro pianificato;

81- database in sola lettura per analytics;

82- browser o scraper controllato per siti esterni;

83- storage documentale;

84- ambienti di esecuzione isolati;

85- sistemi interni esposti con permessi stretti.

87La parte delicata è che un catalogo di tool senza politica è solo un modo più elegante per creare caos.

89## Il quarto pezzo: identità e permessi

91Questa è la zona in cui tante demo fanno finta di niente.

93Un agente agisce per conto di qualcuno. Quindi deve essere chiaro chi è il soggetto dell'azione.

95Sta 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?

97Se 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.

99La 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.

100

101Questo significa OAuth, token scoped, secret management, audit log, policy per tool, allowlist, approval step. Roba poco romantica. Roba necessaria.

102

103## Il quinto pezzo: memoria e contesto, ma senza accumulare spazzatura

104

105Gli agenti hanno bisogno di memoria, ma la memoria è pericolosa quando diventa una soffitta.

106

107Ci sono almeno tre tipi di memoria:

108

109- memoria di run: cosa è successo in questa esecuzione;

110- memoria di progetto: convenzioni, decisioni, vincoli;

111- memoria personale o di team: preferenze, tono, rituali, processi.

112

113Mettere tutto nel prompt è la scorciatoia. Funziona fino a quando non funziona più. La memoria utile va curata: indicizzata, aggiornata, scaduta, verificata, resa citabile.

114

115Un agente che ricorda male è peggio di un agente che non ricorda. Perché parla con sicurezza.

116

117Quindi 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.

118

119## Il sesto pezzo: osservabilità, eval e replay

120

121Se un agente sbaglia, il log "ha chiamato il modello" non basta.

122

123Vuoi 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?

124

125Qui gli agenti somigliano più a sistemi distribuiti che a chatbot.

126

127Servono 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".

128

129Gli 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.

130

131La cosa buffa è che torniamo sempre lì: ingegneria del software. Test, ambienti, trace, rollback. Solo che il codice adesso decide anche cosa fare dopo.

132

133## Il settimo pezzo: interfacce umane

134

135L'agente non deve vivere solo in una chat.

136

137Alcuni 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.

138

139La 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.

140

141Un'infrastruttura agentica decente include superfici di controllo:

142

143- stato corrente;

144- piano modificabile;

145- artefatti prodotti;

146- diff;

147- richieste di approvazione;

148- cronologia;

149- pulsante stop;

150- pulsante retry;

151- permessi visibili.

152

153Sembra banale, ma non lo è. La differenza tra "AI inquietante" e "assistente affidabile" spesso è solo che la seconda ti fa vedere dove ha le mani.

154

155## La stack mentale

156

157Se dovessi disegnarla oggi, la stack agentica minima sarebbe questa:

158

1591. Modello: ragionamento, generazione, tool calling, multimodale se serve.

1602. Orchestrazione: loop, step, planner, policy, human-in-the-loop.

1613. Runtime durevole: workflow, queue, retry, pause, resume.

1624. Sandbox: code execution, file system isolato, limiti, artefatti.

1635. Tool layer: MCP, API interne, browser, database, repository.

1646. Identity layer: OAuth, scope, secret, audit, policy.

1657. Memory layer: contesto di progetto, retrieval, istruzioni, scadenza.

1668. Observability: trace, replay, eval, metriche di costo e qualità.

1679. Product surface: chat quando basta, dashboard quando serve, review quando conta.

168

169Il framework agentico copre soprattutto i punti 2 e un pezzo del punto 1. Il resto è il lavoro vero.

170

171## Cosa farei in pratica

172

173Se un team mi dicesse "vogliamo agenti in produzione", non partirei con dieci agenti.

174

175Partirei 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.

176

177Poi metterei paletti molto chiari:

178

179- niente scrittura senza branch o sandbox;

180- niente segreti nel prompt;

181- tool in allowlist;

182- approvazione umana per azioni esterne;

183- log e trace obbligatori;

184- budget per run;

185- output sempre ispezionabile.

186

187Solo dopo allargherei.

188

189Gli agenti non falliscono solo perché i modelli sbagliano. Falliscono perché li mettiamo in ambienti vaghi, con permessi confusi e aspettative teatrali.

190

191## La mia lettura

192

193L'infrastruttura agentica è noiosa nel modo migliore.

194

195Non è 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.

196

197Il 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.

198

199È lì che gli agenti smettono di essere un giocattolo e diventano infrastruttura.

200

201## Fonti

202

203- [Vercel: How to build AI agents with Vercel and the AI SDK](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)

204- [Vercel Docs: Sandbox](https://vercel.com/docs/sandbox)

205- [Vercel Docs: Working with Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)

206- [Vercel Docs: MCP](https://vercel.com/docs/mcp)

207- [Model Context Protocol: Specification](https://modelcontextprotocol.io/specification)

208- [OpenAI: New tools for building agents](https://openai.com/index/new-tools-for-building-agents/)

209- [Cloudflare Blog: Agents on Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)

210