Cloudflare ha fuso Workers AI e AI Gateway in un unico control plane. Chi gestisce agenti in produzione ora ha osservabilità, billing e routing dinamico su GPU gestite e provider esterni da una singola interfaccia, con binding unificati e model-first routing.

Perché ti riguarda. Se stai portando agenti in produzione, il problema è gestire chi chiama cosa, quanto costa ogni chiamata, e cosa succede quando un provider va giù, piuttosto che quale modello scegliere. Finora chi usava Cloudflare doveva trattare l’inferenza gestita (Workers AI) e il gateway di routing (AI Gateway) come due cose separate: due sistemi di log, due contatori, due configurazioni.

Adesso il routing decide al runtime in base al modello richiesto e allo stato dei provider. Se un endpoint è lento o ha un rate limit attivo, la richiesta passa a un’altra rotta senza che l’agente se ne accorga. Per chi ha agenti che girano tutta la notte, significa meno pipeline custom e meno tempo a rincorrere log sparpagliate.

Questa mossa si inserisce nel filone che abbiamo seguito questa settimana: il 5 agosto Cloudflare aveva composto il modello zero trust per mandare gli agenti in produzione, e il 7 agosto aveva chiuso la pila infrastrutturale con browser stateless, MCP senza stato e pagamenti. Il control plane unificato è il pezzo che tiene insieme governance e routing: l’ultimo strato della stessa architettura.

Se vuoi provarci. La documentazione del control plane unificato è sul blog di Cloudflare. Prima di configurare i binding unificati sui tuoi agenti, vale la pena verificare la disponibilità effettiva dei modelli che usi sulle GPU gestite di Cloudflare, perché il catalogo non coincide con quello dei provider esterni.

Nel dettaglio

Cos’era prima.

Workers AI e AI Gateway erano due prodotti con due scopi. Workers AI faceva girare modelli open-weight sulle GPU di Cloudflare all’edge: inferenza gestita, prezzo per token, niente da orchestrare. AI Gateway era un proxy che stava davanti ai provider esterni (OpenAI, Anthropic, Google) per aggiungere caching, rate limiting, logging e fallback. Chi voleva entrambe le cose doveva gestirle a mano: due dashboard, due logiche di routing, due sistemi di fatturazione.

Cosa cambia.

L’unificazione porta tutto sotto un unico control plane. I concetti chiave per chi non sviluppa:

• Binding unificati. In Cloudflare Workers, un binding è il modo in cui il codice si collega a un servizio. Adesso un solo binding dà accesso sia ai modelli gestiti sulle GPU di Cloudflare sia ai provider esterni. Niente più due configurazioni separate.
• Model-first routing. Invece di specificare un endpoint e un provider, chiedi un modello per nome. Il sistema capisce da solo dove servirlo: sulla propria infrastruttura, su un provider esterno, o su entrambi con fallback.
• Osservabilità e billing in un posto. Log, metriche e fatturazione convergono in una sola vista. Per chi ha agenti in produzione, questo risolve il problema pratico di capire quanto costa davvero ogni chiamata e dove si rompe.

Come si inserisce nel quadro.

Cloudflare sta costruendo una pila completa per agenti in produzione: runtime, browser stateless, MCP senza stato, pagamenti autonomi, zero trust. Il control plane unificato è lo strato di governance che tiene insieme gli altri. Se il runtime decide dove gira l’agente e il protocollo decide come parla con gli strumenti, il control plane decide quale modello risponde e quanto costa.

Limiti e domande aperte.

Il catalogo di Workers AI (modelli gestiti sulle GPU di Cloudflare) resta più piccolo di quello dei provider esterni. Se un agente ha bisogno di un frontier model specifico, il model-first routing lo instrada sul provider esterno, ma il vantaggio del single-pane-of-glass si riduce alla governance, senza riduzione dei costi di inferenza. Il post non entra nei dettagli su come il routing dinamico valuta latenza e disponibilità in tempo reale, né su quanto il fallback fra provider sia trasparente per l’agente o richieda gestione dello stato.

Come per tutti gli annunci di questa settimana, la prova sul campo dirà se l’unificazione è reale nel billing e nei log o se è un livello cosmetico sopra due sistemi ancora distinti.