Un agente AI in produzione è un progetto. Dieci agenti AI in produzione sono un problema di infrastruttura. È la lezione più utile che si ricava dall’architettura con cui DoorDash ha messo in piedi la sua piattaforma agentica: non un modello più grande, non un prompt più furbo, ma uno strato di rete che sta davanti a tutto e decide chi può chiamare cosa. Un gateway per agenti AI in azienda non è un lusso da Big Tech: è il momento in cui la sperimentazione smette di essere sperimentazione.
Il caso DoorDash è interessante proprio perché non è esotico. Le scelte che ha fatto, un punto d’ingresso unico, uno strato MCP condiviso, tracing distribuito attivato per default, sono le stesse che si trovano davanti un CTO italiano quando il terzo reparto chiede “anche noi vogliamo un agente”.
In questo articolo scoprirai:
- Cosa ha costruito DoorDash: un punto d'ingresso unico per gli agenti
- Perché serve un gateway per agenti AI quando si passa da uno a dieci
- Le quattro funzioni di un gateway per agenti AI in azienda
- Il mercato si è già mosso: cosa offrono i vendor
- Portare un gateway per agenti AI in una PMI italiana
- Chi configura e chi mantiene il gateway per agenti AI
Cosa ha costruito DoorDash: un punto d’ingresso unico per gli agenti
L’architettura di “Ask DoorDash” ruota attorno a tre componenti separati con responsabilità nette. Il Gateway è l’unico punto d’ingresso: autentica l’utente, assembla il contesto e traduce le richieste HTTP dei client nel protocollo A2A, gestendo lo streaming verso l’interfaccia. Come racconta il blog di ingegneria di DoorDash, questo concentra in un solo posto lavoro che altrimenti si duplicherebbe in ogni applicazione client.
Dietro il gateway c’è l’Orchestrator, che sceglie a quale agente di dominio affidare ogni turno di conversazione. E dietro gli agenti c’è lo strato MCP: un confine condiviso tra gli agenti e le API interne, che espone la logica di business come strumenti tipizzati. Secondo la ricostruzione pubblicata da ZenML nella sua LLMOps Database, la piattaforma espone “più di 60 strumenti tra workflow agentici pubblici e interni”, riusabili da qualunque agente e anche dalle integrazioni esterne.
I numeri che giustificano il gateway per agenti AI
La parte che conta per chi deve firmare il budget è l’effetto composto. Il tracing distribuito, propagato attraverso le chiamate A2A e gli strumenti MCP, fa risparmiare al team circa un mese di lavoro di osservabilità per ogni nuovo agente lanciato. I primi domini (Ristoranti, Spesa) hanno richiesto due mesi ciascuno; il dominio Prenotazioni è andato live in una settimana. E quando è uscito un nuovo modello, l’harness di valutazione condiviso ha permesso di testarlo e deployarlo in sette giorni, tagliando la latenza mediana del 35% senza perdere qualità.
Come riporta InfoQ nella sua analisi dell’assistente DoorDash, l’altra scelta strutturale è la diffidenza verso il modello: “le azioni deterministiche aggiornano artefatti versionati senza invocare il language model”. La memoria conversazionale, recuperata tramite ricerca vettoriale semantica e poi riclassificata prima di entrare nel prompt, segue la stessa logica di un’architettura RAG ben fatta: il modello non ricorda, il sistema gli passa il contesto giusto. Risultato dichiarato: conversione al checkout della spesa migliorata di circa il 24% e oltre 2.000 valutazioni automatiche eseguite ogni giorno.
Perché serve un gateway per agenti AI quando si passa da uno a dieci
Con un solo agente si può fare tutto a mano. Le credenziali stanno in un file di configurazione, i log si leggono direttamente, i permessi sono quelli dell’account di servizio che qualcuno ha creato in fretta. Il problema è che questa architettura non degrada gradualmente: collassa.
Kong descrive il fenomeno come “MCP sprawl”: senza centralizzazione ogni client mantiene connessioni verso ogni server, la configurazione si frammenta tra sistemi diversi, le credenziali si moltiplicano e ogni aggiornamento si propaga in modo incontrollato attraverso tutti i punti di connessione. Il costo non cresce linearmente col numero di agenti, ma col numero di coppie agente-strumento.
I tre buchi di governance che emergono subito
L’analisi di Airia sui motivi per cui le aziende chiedono un MCP gateway li elenca senza giri di parole: nessuna visibilità centrale (il team sicurezza non sa quale agente si collega a quale sistema), nessun controllo degli accessi (i permessi sono sparsi nelle singole integrazioni) e nessun audit trail, l’impossibilità forense di ricostruire cosa è successo, quale agente ha agito e a quali dati ha avuto accesso.
Il terzo punto è quello che diventa urgente per motivi non tecnici. Gli auditor chiedono visibilità sulla governance dell’AI e “non abbiamo visibilità” non è più una risposta accettabile, un tema che si intreccia direttamente con gli obblighi di tracciabilità che l’AI Act impone alle imprese. Chi deve scrivere le policy interne prima di scalare troverà utile la nostra guida su governance degli agenti AI, ruoli e AI Act, che affronta il livello organizzativo di cui il gateway è la controparte tecnica.
Le quattro funzioni di un gateway per agenti AI in azienda
Al netto del marketing dei vendor, un gateway per agenti fa quattro cose. IBM definisce l’AI gateway come lo strato middleware che si interpone tra le applicazioni e i servizi di intelligenza artificiale, centralizzando autenticazione, routing e osservabilità; la guida tecnica di Tyk all’architettura MCP gateway declina lo stesso principio sul traffico verso gli strumenti, con precisione utile.
Identità e autorizzazione fine
Il gateway valida l’identità dell’agente all’ingresso, ispezionando la richiesta per credenziali come API key o token JWT. Poi applica permessi granulari: un agente può leggere da un database, un altro può scriverci. La funzione più sottovalutata è la filtered discovery: il gateway restituisce all’agente solo gli strumenti che è autorizzato a usare, e l’agente non ha alcuna visibilità su quelli che non può chiamare. Un tool che non esiste nel catalogo dell’agente non può essere invocato per errore né indotto via prompt injection.
Rate limit e quote per contenere i costi
I limiti si applicano per agente, per strumento o globalmente: mille richieste all’ora per un agente, cento chiamate al giorno verso un’API di terze parti costosa. Sul fronte LLM il ragionamento si sposta sui token: la documentazione Microsoft sul gateway AI di Azure API Management spiega che il problema nasce quando più applicazioni condividono la stessa quota token-per-minuto, e serve garantire che “un’app non usi l’intera quota TPM impedendo alle altre di accedere ai back-end necessari”. La policy di token limit può anche stimare i token del prompt in anticipo, bloccando la richiesta prima di sprecare una chiamata al modello.
Routing e resilienza verso modelli e provider
È la funzione che parla al budget più direttamente di tutte. Il gateway decide a quale modello o provider mandare ogni richiesta, e può servire dalla cache le risposte semanticamente equivalenti a domande già viste: il semantic caching taglia costo e latenza sulle richieste ripetitive, che in un assistente interno sono la maggioranza. Sul fronte affidabilità, il circuit breaker smette di insistere su un backend che sta fallendo e il fallback dirotta il traffico su un modello alternativo, così un rate limit del provider non diventa un fermo del servizio. È anche il punto in cui cambiare modello diventa una modifica di configurazione e non un intervento su ogni agente.
Osservabilità e audit trail immutabile
Il gateway genera un registro immutabile di ogni singola richiesta: quale agente, quale strumento, con quali parametri, a che ora, con quale esito. Insieme alle metriche di latenza, error rate per strumento e consumo di token, è la base di qualsiasi strategia di osservabilità per agenti in produzione. E costa poco: un gateway ben ingegnerizzato aggiunge tipicamente pochi millisecondi di overhead per richiesta. Senza gateway, invece, il debug richiede di ricucire a mano i log di ogni agente e di ogni strumento.
Il mercato si è già mosso: cosa offrono i vendor
La conferma che questo non è un pattern di nicchia arriva dalla velocità con cui i grandi cloud lo hanno prodotto. L’Agent Gateway di Google Cloud è descritto come “il componente di rete dell’ecosistema Gemini Enterprise Agent Platform” e lavora in due direzioni: client-to-agent in ingresso, agent-to-anywhere in uscita. Include un Agent Registry, un repository centrale dove vengono catalogati agenti, strumenti e server MCP approvati, e una Agent Identity che fornisce “una persona unica e tracciabile per ogni agente”. Il default è la scelta più significativa: l’accesso a qualunque server MCP remoto non registrato è bloccato.
Azure API Management ha esteso il gateway API esistente invece di crearne uno nuovo, aggiungendo gestione dei server MCP remoti, API agente A2A, semantic caching e circuit breaker sui backend. Sul fronte open source, agentgateway è un proxy Apache 2.0 sotto Linux Foundation costruito nativamente su MCP e A2A, con RBAC via policy CEL, federazione dei tool e supporto OpenTelemetry.
Tradotto: chi sta valutando come orchestrare più agenti in azienda non deve inventarsi il livello di controllo da zero. Deve decidere quale adottare e, soprattutto, chi lo configura.
Portare un gateway per agenti AI in una PMI italiana
Qui sta lo scarto tra il caso DoorDash e la realtà di un’azienda da 80 persone. DoorDash ha un platform team che costruisce infrastruttura per altri team interni. Una PMI italiana ha un IT manager che porta già tre cappelli, e la domanda giusta non è “quale gateway” ma “chi lo mette in piedi e chi lo mantiene quando l’agente numero quattro arriva”.
Il setup minimo che regge davvero
Per un’azienda di quella taglia il punto di partenza sensato è il gateway gestito del cloud che si usa già, se la posta e i file sono su Microsoft 365, estendere API Management costa molto meno che introdurre uno stack nuovo da presidiare. Serve poi un registro dei tool approvati, anche un semplice elenco versionato in cui ogni strumento ha un proprietario e una motivazione: è ciò che impedisce che il quarto agente si colleghi al gestionale perché “serviva per una prova”. E serve un’identità per ogni agente, mai un service account condiviso: senza identità distinte l’audit trail registra tutto e non spiega niente. Tre cose, non una piattaforma.
Le decisioni che vengono prima del gateway
Prima di scegliere un prodotto servono tre risposte. Quali sistemi gli agenti devono davvero raggiungere, ed è lì che emerge il vero costo, perché integrare agenti AI con ERP e CRM legacy è più difficile che esporre un tool MCP. Quale identità hanno gli agenti: un account di servizio condiviso è la scorciatoia che rende l’audit trail inutile. E quali strumenti ogni agente può vedere, perché il principio del minimo privilegio vale per gli agenti esattamente come per le persone.
Chi configura e chi mantiene il gateway per agenti AI
Un owner unico, dalla parte della piattaforma
La risposta corta è che il gateway ha un owner unico, e sta dalla parte della piattaforma: il team IT o platform che già presidia rete, identità e accessi, non il team funzionale che ha chiesto l’agente. Non è un dettaglio organizzativo: se la configurazione la fa chi costruisce gli agenti, il minimo privilegio dura fino al primo permesso scomodo.
Manutenzione e revisione: un lavoro che non finisce al go-live
Ogni nuovo tool esposto è una policy nuova da scrivere e approvare, le credenziali verso i sistemi a valle vanno ruotate su un calendario e non quando qualcuno se ne ricorda, e i permessi accumulati vanno ripuliti: una revisione trimestrale dei tool attivi e degli agenti autorizzati è la cadenza minima realistica, con un controllo dei log di rifiuto molto più frequente, è lì che si vede un agente che sta provando a fare qualcosa che non dovrebbe.
Per questo in MIMIR trattiamo il livello di controllo come parte dell’onboarding assistito, non come una fase successiva: identità degli agenti, permessi sui tool, logging e limiti di spesa vengono definiti insieme al cliente mentre il primo agente entra in produzione, così che il secondo e il terzo si innestino su un’infrastruttura già pronta.
È la ragione per cui sosteniamo che, su questi progetti, il servizio conta più del modello: il modello lo cambi in una settimana, la governance no. E dopo il go-live resta il tema della manutenzione continua, che è dove gli agenti mal governati presentano il conto.
Se stai valutando di portare agenti AI in azienda e vuoi capire quale livello di controllo ti serve davvero, o se hai già un agente in produzione e ti accorgi che nessuno sa cosa sta chiamando, puoi parlarne con noi. Su MIMIR trovi come richiedere una consulenza per inquadrare l’architettura prima di scrivere codice.
Fonti:
- DoorDash Engineering — Beyond single agents: building a collaborative AI ecosystem
- ZenML LLMOps Database — Building a multi-domain agent platform with shared infrastructure and specialized agents
- InfoQ — DoorDash builds Ask DoorDash AI assistant
- Kong — What is an MCP gateway
- Airia — The MCP gateway: what it is, why it matters and why enterprises are asking for it
- Tyk — MCP gateway architecture: a technical guide
- IBM Think — Che cos’è un AI gateway
- Microsoft Learn — AI gateway capabilities in Azure API Management
- Google Cloud — Agent Gateway overview
- GitHub — agentgateway: open source AI gateway for MCP and A2A
