L'infrastruttura agentica e il nuovo backend

spinny:~/writing $ vim 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~

NORMAL · agentic-infrastructure-stack.md [readonly]210 lines · :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.

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~