Quando un agente diventa un sistema distribuito
La settimana appena conclusa ha prodotto poche novità davvero interessanti, ma alcune sono abbastanza sostanziali da meritare un'analisi architetturale. Il tema dominante è il passaggio dall'AI “a richiesta e risposta” verso sistemi agentici persistenti, osservabili, recuperabili dopo un fault e collegati a UI e tool reali.
In parallelo, Esri ha pubblicato indicazioni concrete per ArcGIS Pro su Azure e, soprattutto, un nuovo security bulletin per Portal for ArcGIS. Sul fronte LLM, GPT-6 Sol e Luna spostano ancora di più la discussione dalla pura qualità del modello al costo per task riuscito, al caching e al routing.
Questa settimana quindi niente riempitivi: Microsoft Agent Framework e AG-UI, GPT-6 e AI FinOps, ArcGIS Pro su Azure, ArcGIS Security Watch, .NET production diagnostics e un nuovo From the Lab dedicato a NeuralPad.
Microsoft Agent Framework: non è più una chat, è un runtime applicativo
Il 24 settembre Microsoft ha pubblicato un aggiornamento importante di Microsoft Agent Framework che mette insieme quattro capacità che, prese singolarmente, sembrano feature; viste insieme, invece, descrivono una direzione architetturale precisa: AG-UI, memory, CodeAct e resilient execution.
Il cambio di prospettiva è questo:
LLM call
↓
Agent loop
↓
Tools
↓
Memory
↓
Checkpoint / recovery
↓
User-facing event stream
Un agente che esegue lavoro reale non può essere trattato come una singola chiamata HTTP lunga. Deve possedere stato, un modello di recovery, isolamento, autorizzazione, telemetria e semantica dei side effect.
AG-UI: un protocollo tra agent backend e applicazione
Il giorno successivo, il team .NET ha annunciato un SDK .NET first-class per AG-UI. Il protocollo standardizza gli eventi che un agent backend invia al client: inizio/fine run, streaming del testo, reasoning, tool invocation, state delta, interrupt e altri eventi tipizzati.
L'elemento interessante è che AG-UI non richiede Microsoft Agent Framework. Il server può essere costruito direttamente attorno a IChatClient di Microsoft.Extensions.AI, mentre Agent Framework usa ora lo stesso SDK AG-UI come base della propria integrazione ASP.NET Core.
Web / Mobile / Terminal / Teams
│
│ AG-UI events
▼
ASP.NET Core
│
▼
IChatClient
│
┌──────┼─────────┐
│ │ │
Model Tools State
Il trasporto predefinito è Server-Sent Events; esiste anche un codec Protobuf opzionale che copre un sottoinsieme degli eventi. Il client .NET espone a sua volta l'agente remoto come IChatClient, quindi un backend scritto in Python o TypeScript può essere consumato da codice .NET senza cambiare il contratto applicativo.
Analisi. Questa separazione è più importante dell'ennesimo componente UI per una chat. Significa che il confine tra agent runtime e presentation layer inizia ad assomigliare al confine che abbiamo già imparato a gestire fra backend e frontend nelle applicazioni distribuite. L'UI non deve conoscere il framework agentico, ma soltanto un protocollo di eventi.
Conversation state, memory e sandbox sono tre cose diverse
Un secondo punto molto importante è la separazione fra conversazione, memoria e sessione hosted. Microsoft specifica esplicitamente che una Foundry hosted session non è una conversazione: la conversazione contiene messaggi e tool call, mentre la hosted session rappresenta un sandbox VM-isolated con filesystem e stato di lavoro persistente.
User identity
│
├── Conversation history
│
├── Long-term memory
│
└── Hosted sandbox session
│
├── files
├── code
└── working state
Inoltre, user isolation e session isolation sono controlli indipendenti. L'identità può derivare direttamente dal token Microsoft Entra oppure essere delegata da un middle tier fidato; la sessione del sandbox può invece essere creata dal servizio o gestita esplicitamente dall'applicazione.
Questo evita un errore concettuale frequente nei progetti agentici: usare un thread ID o un conversation ID come se fosse una boundary di sicurezza. Microsoft lo dice chiaramente anche per AG-UI: un thread identifica una conversazione, ma non dimostra chi sia autorizzato a leggerla.
Memory: non è “salvare tutta la chat”
Il nuovo FoundryMemoryProvider recupera memorie rilevanti prima del run e invia informazioni della conversazione al memory store per l'estrazione asincrona dopo il run. Il punto chiave è che la long-term memory può essere usata senza ricaricare ogni volta l'intera transcript.
Valutazione. Il modello corretto per un sistema enterprise dovrebbe essere:
short-term transcript
│
├── current reasoning context
│
long-term memory
│
├── selected / retrieved facts
│
application database
│
└── authoritative state
Queste tre sorgenti non dovrebbero essere confuse. La memoria di un agente non sostituisce il database applicativo e non dovrebbe diventare una fonte autorevole per dati transazionali.
Resilient execution: retry non significa exactly-once
La parte più interessante, da architetto, è probabilmente la resilient execution. Agent Framework può collegare checkpoint di workflow e sessioni hosted alle background responses persistenti. Un processo può essere interrotto, riavviato e riconnettersi al lavoro salvato.
Ma Microsoft evidenzia un punto fondamentale: il recovery non garantisce exactly-once execution degli effetti esterni. Uno step interrotto può essere rieseguito.
Agent step
│
├── write DB
├── send email
└── call external API
│
process crash
│
checkpoint restore
│
step may run again
Quindi ogni tool con side effect dovrebbe essere progettato con idempotency key, deduplica o compensating action.
È lo stesso problema che conosciamo da workflow engine, code di messaggi e sistemi distribuiti: l'LLM cambia la logica decisionale, non le leggi della distributed systems engineering.
CodeAct e il confine di sicurezza
CodeAct consente al modello di esprimere una sequenza di operazioni come programma e di ottenere un risultato consolidato, riducendo il ping-pong model → tool → model → tool per task adatti a questo pattern.
Ma Microsoft fa una distinzione fondamentale: Hyperlight isola il codice generato dal modello; i tool registrati vengono invece eseguiti nel runtime dell'applicazione e mantengono i propri privilegi.
Analisi. La sandbox protegge dal codice generato, ma non trasforma automaticamente in sicuro un tool pericoloso. Un tool DeleteDatabase() rimane pericoloso anche se il programma che lo invoca gira in una sandbox. L'autorizzazione deve stare sul confine del tool.
Fonti primarie: Microsoft Agent Framework — Interactive experiences, memory and resilient execution; .NET Blog — AG-UI Protocol now has a first-class .NET SDK; Microsoft Agent Framework — Foundry hosted agent isolation.
GPT-6 Sol e Luna: il modello migliore non è necessariamente il modello corretto
OpenAI ha rilasciato il 22 settembre GPT-6 Sol e GPT-6 Luna nell'API, in Codex e in ChatGPT Work. Per l'API, il prezzo standard dichiarato per prompt fino a 272K token è:
| Modello | Input / 1M | Cached input / 1M | Output / 1M |
|---|---|---|---|
| GPT-6 Sol | $2.00 | $0.20 | $10.00 |
| GPT-6 Luna | $0.10 | $0.01 | $0.50 |
Il dato interessante non è solo il prezzo. OpenAI ha modificato anche il prompt caching per GPT-6: i cached input-token reads ricevono uno sconto del 90%, e reasoning effort e disponibilità dei tool possono essere modificati senza invalidare automaticamente il prefisso già riutilizzabile.
Questo porta direttamente a un problema di AI FinOps.
Task
│
├── cheap model
│ ├── success → done
│ └── fail → retry/escalation
│
└── expensive model
└── success → done
Con rapporti di prezzo molto diversi, la metrica corretta non è semplicemente $/1M tokens.
Effective cost =
total inference cost
+ retry cost
+ tool cost
+ latency cost
+ escalation cost
Cost-per-successful-task =
Effective cost / successful tasks
Analisi. Un modello che costa un decimo può risultare più caro se aumenta significativamente retry, tool call, correzioni o escalation. Il routing va quindi valutato su workload reali con metriche di successo applicative, non solo sui benchmark del vendor.
Session affinity: un dettaglio apparentemente piccolo che tocca caching e continuità
Microsoft Foundry Model Router ha introdotto a settembre una session affinity in preview per Chat Completions. L'applicazione può inviare un session ID opaco e chiedere al router di tentare lo stesso modello eleggibile nei turni successivi.
L'affinità è best-effort: policy, safety, capability, quota, availability e fallback hanno precedenza. L'associazione scade dopo 30 minuti senza una richiesta riuscita e non garantisce un cache hit.
Conversation turn N
│
▼
Router
│
├── same model → behavioral continuity
│ + better cache opportunity
│
└── fallback → availability/capability wins
Nota importante. La documentazione attuale del Model Router elenca ancora la famiglia GPT-5.6 nel pool documentato; non va quindi interpretata questa sezione come una dichiarazione che GPT-6 Sol/Luna siano già instradati dal Model Router.
Operational note: rerun delle evaluation multimodali
Il 25 settembre OpenAI ha corretto un bug nell'image encoding che degradava la comprensione delle immagini per GPT-6 Sol e Luna nell'API e in Codex. Per workload con input visuali OpenAI raccomanda di rieseguire le evaluation e riprovare i workflow eventualmente interessati.
Questo è un buon promemoria operativo: quando un modello cambia anche senza cambiare model ID, una regression suite applicativa è più importante del semplice controllo della versione.
Fonti primarie: OpenAI — Introducing GPT-6 Sol and Luna; OpenAI API Changelog; Microsoft Foundry — What's new in Model Router e How to use Model Router.
ArcGIS Pro su Azure: la GPU è solo una parte del problema
Il 21 settembre Esri ha pubblicato una nuova guida specifica per il deployment e il dimensionamento di ArcGIS Pro su Microsoft Azure.
La raccomandazione corrente di Esri è significativa: per la maggior parte dei deployment ArcGIS Pro, NVadsA10_v5 è la famiglia GPU preferita; NCasT4_v3 rimane una buona alternativa quando è già in uso o quando disponibilità regionale e altri vincoli Azure la rendono più pratica.
Single-session: partire dal workload, non dalla SKU
| Profilo | NVadsA10_v5 | NCasT4_v3 |
|---|---|---|
| Light — 2D / viewing | NV6ads_A10_v5 | NC4as_T4_v3 |
| Medium — editing / 2D-3D | NV12ads_A10_v5 | NC8as_T4_v3 |
| Heavy — 3D / analysis | NV18ads_A10_v5 | NC16as_T4_v3 |
Esri specifica esplicitamente che questi valori sono punti di partenza e devono essere verificati con workload reali.
A10 vs T4: non è soltanto una questione di VRAM
La serie NVadsA10_v5 usa GPU NVIDIA A10 e CPU AMD EPYC 74F3v. Azure consente configurazioni frazionarie della GPU A10 a partire da 1/6 della GPU con 4 GiB di frame buffer, fino alla GPU completa da 24 GiB. Le VM della serie includono una licenza NVIDIA GRID.
NCasT4_v3 usa invece NVIDIA T4 da 16 GB e AMD EPYC 7V12. Azure documenta questa famiglia sia per real-time AI inference sia per grafica e visualizzazione interattiva; per i workload grafici è necessario installare il driver GRID supportato.
ArcGIS Pro workload
│
├── 2D / editing
│ └── CPU + latency + storage
│
├── 3D / scene
│ └── GPU + VRAM + remote display
│
├── raster / imagery
│ └── CPU/GPU + storage throughput
│
└── deep learning
└── CUDA capability + VRAM + compute
Analisi. La VM “più potente” non è automaticamente quella più corretta. Un flusso 2D che legge feature o file geodatabase attraverso una rete lenta può essere limitato da data locality e round trip molto prima di saturare la GPU. Una scena 3D sposta invece il collo di bottiglia verso rendering e VRAM; un task GeoAI può dipendere più da CUDA compute e memoria GPU che dal desktop remoto.
AVD: la user density è una metrica, non un numero fisso
Esri indica come starting point per ambienti multi-session:
| Profilo | SKU di riferimento | Densità indicativa |
|---|---|---|
| Light | NV18ads_A10_v5 / NC16as_T4_v3 | fino a 6 utenti |
| Medium | NV18ads_A10_v5 / NC16as_T4_v3 | fino a 4 utenti |
| Heavy | NV36ads_A10_v5 / NC64as_T4_v3 | fino a 3 utenti |
La densità dipende da CPU, RAM, VRAM, storage, data performance e concorrenza. In altre parole: la user density deve essere misurata con progetti reali, non estrapolata da un foglio Excel.
Data locality: spesso il vero collo di bottiglia
Esri raccomanda di tenere compute e dati nella stessa regione Azure e, per shared file-based GIS data ad alte prestazioni, indica Azure NetApp Files. Per il dimensionamento vanno considerate contemporaneamente latenza, throughput, IOPS, concurrency e caratteristiche dei dataset.
Questo è particolarmente importante nel GIS: un'applicazione desktop GPU-accelerated che apre dataset remoti non è un benchmark della GPU, ma dell'intera catena:
ArcGIS Pro
↓
GPU / CPU
↓
virtual desktop protocol
↓
network
↓
file service / geodatabase / feature service
↓
storage
Per creare baseline ripetibili Esri continua a raccomandare ArcGIS Pro Performance Assessment Tool, che misura startup, caricamento mappe/bookmark e rendering dei layer e permette anche script personalizzati.
Fonti primarie: Esri — ArcGIS Pro on Microsoft Azure: Deployment and Performance Guidance; Microsoft Learn — NVadsA10_v5 e NC family; Esri — ArcGIS Pro Performance Assessment Tool.
ArcGIS Security Watch: Portal for ArcGIS 2026 Security Update 4
Questa settimana la parte security non è un box secondario. Il 24 settembre Esri ha pubblicato Portal for ArcGIS 2026 Security Update 4 e raccomanda ai clienti ArcGIS Enterprise di applicarlo il prima possibile.
Il patch è cumulativo e non richiede l'installazione preventiva dei precedenti Portal security patch.
| CVE | CWE | CVSS base pubblicato | Versioni coinvolte |
|---|---|---|---|
| CVE-2026-69227 | CWE-306 — Missing Authentication for Critical Function | 9.8 — Critical | Portal 12.1 e precedenti |
| CVE-2026-69226 | CWE-863 — Incorrect Authorization | 6.5 — Medium | Portal 12.1 e precedenti |
| CVE-2026-10759 | CWE-90 — LDAP Injection | 5.5 — Medium | Portal 12.1 e precedenti |
C'è una particolarità che vale la pena segnalare: il testo introduttivo del bulletin Esri parla di “one medium and two critical severity vulnerabilities”, mentre la tabella dettagliata dello stesso bulletin riporta un CVSS critical e due medium. Fino a eventuale correzione del testo, la cosa corretta è riportare i valori individuali pubblicati per ogni CVE e non dedurre una classificazione diversa.
Dal punto di vista operativo, questa incongruenza non cambia la priorità: un CVSS 9.8 su una funzione critica di autenticazione è già sufficiente per trattare l'aggiornamento come urgente.
Mitigation non significa remediation
Esri indica alcune mitigazioni: un WAF può contribuire a bloccare pattern malevoli e il profilo base dell'ArcGIS Hardening Guide riduce l'esposizione. Per CVE-2026-69227, Esri indica inoltre che rimuovere un eventuale default role mitiga il bypass delle restrizioni di creazione account.
Ma la mitigazione non sostituisce il patch.
Advisory
↓
Exposure analysis
↓
Temporary mitigation
↓
Patch in staging
↓
Regression test
↓
Production rollout
↓
Post-patch validation
Analisi. In un'architettura ArcGIS Enterprise sarebbe utile trattare Portal come un componente identitario, non solo come un frontend GIS. Patch che toccano autenticazione, autorizzazione o directory integration hanno una priorità diversa da una normale correzione funzionale.
Fonte primaria: Esri — September 2026 ArcGIS Security Bulletin.
.NET Production Watch: dump di memoria e supply-chain trust
Creare un memory dump direttamente da C#
Il 22 settembre il .NET Blog ha pubblicato un esempio per generare programmaticamente un memory dump da C# quando viene rilevata una possibile saturazione del ThreadPool.
L'esempio usa un watcher thread che periodicamente invia un lavoro al ThreadPool e misura quanto impiega a partire. Se il ritardo supera una soglia, il processo genera un dump.
Su Windows l'esempio usa MiniDumpWriteDump da dbghelp.dll; su Linux usa l'utility createdump distribuita con il runtime .NET.
La parte più importante è però la nota di sicurezza: un full dump può contenere credenziali, token, connection string e altri dati sensibili.
dump trigger
↓
rate limit / cooldown
↓
restricted storage
↓
retention policy
↓
secure transfer
↓
analysis
↓
deletion
Analisi. In produzione un dump non è semplicemente “un file di diagnostica”: è potenzialmente una fotografia di segreti in memoria. Va gestito come materiale sensibile.
NuGet: rotazione del certificato Microsoft di author signing
Dal 23 settembre Microsoft ha iniziato a usare un nuovo certificato X.509 per firmare i nuovi package NuGet Microsoft.
Il cambiamento impatta soprattutto chi usa signatureValidationMode=require, trustedSigners in nuget.config oppure verifica esplicitamente fingerprint con dotnet nuget verify.
Il nuovo fingerprint SHA-256 pubblicato da Microsoft è:
9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630
Per aggiungerlo alla policy:
dotnet nuget trust author Microsoft \
9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 \
--algorithm SHA256
I vecchi certificati vanno mantenuti nella allow list per continuare a validare i package già firmati in passato. Se una pipeline applica una trusted signer policy ma non conosce il nuovo certificato, il restore può fallire con NU3034.
Analisi. È un esempio perfetto di supply-chain control che funziona: il blocco della pipeline non è un bug della pipeline, ma l'effetto previsto di una policy che non riconosce più il signer. Il problema operativo è assicurarsi che la rotazione dei trust anchor faccia parte della manutenzione della CI/CD.
Fonti primarie: .NET Blog — Creating a memory dump in C#; .NET Blog — Microsoft author-signing certificate update.
From the Lab — NeuralPad: rendere osservabile una rete neurale
Questa settimana inauguro anche una piccola sezione dedicata ai progetti che sto costruendo o sperimentando direttamente.
NeuralPad è un visual neural network debugger sperimentale per .NET, pensato con una filosofia volutamente simile a LINQPad: invece di nascondere la rete dietro poche API di training, prova a rendere direttamente osservabili matematica e stato runtime.
C#
↓
network definition
↓
forward pass
↓
weighted contributions
↓
activations
↓
loss
↓
backpropagation
↓
gradients
↓
optimizer step
↓
updated parameters
Il progetto è attualmente basato su .NET 10, WPF e DevExpress WPF. La soluzione separa il motore di calcolo dalla UI:
NeuralPad.Core: motore deterministico senza dipendenza WPF;NeuralPad.App: debugger visuale, scripting, training UI e visualizzazione.
La caratteristica progettuale a cui tengo di più è che uno step del debugger corrisponde a una vera operazione matematica, non a un'animazione costruita sopra un training già avvenuto.
Tra le funzionalità già presenti ci sono forward e backward incrementali, ReLU/Sigmoid/Tanh/Linear, Binary Cross Entropy, reti dense configurabili, watch su attivazioni, bias e pesi, training breakpoint, snapshot/compare dei parametri, separazione fra Forward/Backward/Optimizer, grafico visuale della rete e C# scripting tramite Roslyn con editor AvalonEdit e primi servizi di IntelliSense/diagnostica.
Analisi. L'interesse del progetto non è competere con PyTorch o ML.NET come framework di training. È il contrario: rimuovere deliberatamente parte dell'astrazione per poter osservare cosa significa realmente:
gradient computed
≠
parameter updated
Backpropagation calcola i gradienti; l'optimizer step modifica i parametri. Separare visualmente questi momenti aiuta a capire molte cose che nei framework moderni vengono compresse in pochissime righe.
Repository pubblico: nicogis/NeuralPad.
Technical Takeaways
- Gli agent stanno diventando runtime applicativi. Memory, session isolation, checkpointing, protocollo UI e recovery sono problemi di software architecture, non funzionalità decorative intorno all'LLM.
- Exactly-once non compare magicamente perché esiste un checkpoint. I tool con side effect devono essere idempotenti o compensabili.
- Protocollo e framework sono concetti separati. AG-UI permette di disaccoppiare backend agentico e client;
IChatClientrende questa separazione particolarmente naturale in .NET. - L'AI FinOps va misurata a livello di task. Il costo per token è solo una componente di retry, escalation, cache reuse, tool call e latenza.
- Nel GIS cloud la GPU non è il sistema. CPU, VRAM, protocollo di remote display, rete, data locality e storage possono diventare il collo di bottiglia prima della GPU.
- Portal for ArcGIS va trattato come componente security-sensitive. Il nuovo security update include almeno una vulnerabilità CVSS 9.8 e deve entrare rapidamente nel normale ciclo staging → regression → production.
- La supply chain ha stato. Una trusted signer policy richiede manutenzione dei certificati esattamente come qualsiasi altra root of trust.
Lab della settimana
Lab 1 — Esporre un agente .NET via AG-UI
Creare un ASP.NET Core minimal endpoint con AGUI.Server, usare un IChatClient locale o remoto e osservare gli eventi SSE generati durante streaming e tool call.
Obiettivo: verificare in pratica la separazione fra agent implementation e presentation protocol.
Lab 2 — Benchmark ArcGIS Pro A10 vs T4
Usare lo stesso progetto ArcGIS Pro e gli stessi dati su una VM NVadsA10_v5 e una NCasT4_v3 comparabile. Eseguire ArcGIS Pro Performance Assessment Tool e raccogliere startup time, map loading, layer rendering e utilizzo GPU.
Aggiungere una seconda prova spostando i dati lontano dal compute: è un modo semplice per dimostrare quanto la data locality possa falsare un confronto puramente GPU.
Lab 3 — Cost-per-successful-task: Sol vs Luna
Creare un piccolo set di 30-50 task reali — coding, estrazione strutturata, tool calling — ed eseguirli su GPT-6 Luna e GPT-6 Sol registrando:
input tokens
cached input tokens
output tokens
latency
tool calls
retries
task success
estimated cost
La metrica finale non deve essere il costo medio della chiamata, ma il costo medio del task completato correttamente.
