Mathis Joffre, co-fondatore e responsabile dell'ingegneria presso Blaxel – Serie di interviste

Mathis Joffre, co-fondatore e responsabile dell'ingegneria di Blaxel, è un esperto ingegnere infrastrutturale che in precedenza ha contribuito a far crescere una delle più grandi piattaforme cloud europee presso OVHcloud. In Blaxel, guida lo sviluppo di sistemi scalabili a bassa latenza, su misura per gli agenti di intelligenza artificiale, ed è un collaboratore chiave degli strumenti open source dell'azienda a supporto di un deployment basato sulle prestazioni.

Blaxel è una piattaforma di elaborazione progettata appositamente per agenti di intelligenza artificiale autonomi, che consente agli sviluppatori di creare, testare ed eseguire flussi di lavoro agentici senza dover gestire l'infrastruttura. La sua architettura include microVM ultraveloci, esecuzione di processi batch e un gateway globale per il routing e il fallback. Blaxel privilegia sandboxing sicuro, osservabilità in tempo reale e scalabilità fluida per supportare distribuzioni di agenti di livello produttivo.

Hai trascorso tre anni lavorando con OVHcloud nel settore della ricerca e sviluppo di infrastrutture dati e intelligenza artificiale: qual è stato il momento chiave o l'intuizione che ti ha ispirato a creare Blaxel come cloud appositamente progettato per gli agenti di intelligenza artificiale?

Mentre lavoravo su AI Endpoints, uno dei prodotti di punta di OVHcloud per l'intelligenza artificiale, mi sono reso conto di quanto complessa diventerà la prossima generazione di architetture cloud e di casi d'uso dell'intelligenza artificiale. Stiamo passando dai chatbot tradizionali a sistemi completamente autonomi. Questa rivoluzione agentiva non riguarda solo applicazioni più intelligenti; sta imponendo un ripensamento di tutto, dallo stack software all'architettura del data center. Questa consapevolezza è ciò che mi ha spinto a creare Blaxel.

Ripensando al tuo percorso iniziale di ingegneria, dalla creazione di strumenti di rete presso Orange Business alla definizione di stack presso OVHcloud, in che modo questa esperienza ha influenzato l'architettura e la filosofia di Blaxel?

Direi: restate con i piedi per terra. Anche se questa rivoluzione può sembrare ipotetica o sopravvalutata, l'unico modo per renderla reale è concentrarsi su casi d'uso concreti e risolverli al meglio. Questa mentalità ha plasmato Blaxel fin dall'inizio: l'abbiamo costruita attorno alle esigenze reali dei nostri clienti, dalla generazione di codice all'analisi video. Invece di inseguire le tendenze, volevamo offrire una piattaforma progettata appositamente per offrire agli agenti esattamente ciò di cui hanno bisogno per operare in modo efficace.

Puoi illustrarci il ruolo del Model Context Protocol (MCP) e dei gateway modello multi-regione? In che modo ciò migliora la tolleranza agli errori e la scalabilità per gli agenti?

Gli agenti sono strettamente legati al contesto: la loro capacità di accedere a informazioni rilevanti è fondamentale per agire in modo efficace. MCP funge da interfaccia principale per l'integrazione degli agenti con la nostra infrastruttura, poiché affronta questa sfida. Proprio come gli sviluppatori utilizzano le API REST per connettere le app nel mondo SaaS, ora utilizzeranno il Model Context Protocol per fornire un contesto specifico ed elaborabile ai propri agenti.

Ma il contesto da solo non basta: gli agenti si affidano anche a LLM, come quelli forniti da OpenAI o Anthropic. Data la crescente domanda, i server di questi provider possono occasionalmente essere sovraccaricati dal traffico. È qui che entrano in gioco i gateway con modello multi-regione.

I gateway modello consentono di reindirizzare dinamicamente il traffico verso l'endpoint LLM disponibile più vicino (in termini di latenza), che si tratti di OpenAI, Anthropic o di un altro provider. Questo non solo migliora i tempi di risposta, ma garantisce anche tolleranza agli errori (eseguendo il failover su provider alternativi) e scalabilità (distribuendo il carico su più regioni e modelli).

Blaxel supporta strumenti per sviluppatori che gli agenti stessi possono richiamare: cosa ha spinto a progettare API utilizzabili dagli agenti anziché dagli esseri umani? Come prevedete l'evoluzione di questo approccio?

Per me, il rilascio di OpenAI di Operatore È stato illuminante: mi ha fatto capire che il futuro prevede che gli agenti utilizzino direttamente l'infrastruttura. Gli agenti hanno iniziato analizzando i dati storici e rispondendo alle domande. Poi sono passati alla generazione del codice. Il passo logico successivo è che distribuiscano quel codice in modo autonomo.

Ecco perché crediamo che gli agenti abbiano bisogno di un proprio cloud, appositamente progettato attorno all'idea che il futuro delle operazioni IT sarà guidato da agenti autonomi.

Riflettendo sui provider cloud e sulle piattaforme di hosting degli agenti esistenti (come Modal, RunPod, Replicate, ecc.), dove riscontri le lacune più comuni quando si distribuiscono agenti su larga scala?

La maggior parte delle piattaforme odierne non è stata progettata per agenti persistenti, con stato e autonomi, ma per processi senza stato o API di inferenza. Quindi si finisce per combinare elaborazione, memoria, storage e networking in modi che non erano pensati per supportare processi di lunga durata con memoria, cicli di feedback e I/O complessi. Il risultato sono sistemi fragili o elevati costi operativi. Questo è il divario: abbiamo bisogno di infrastrutture in cui gli agenti siano cittadini di prima classe, non un ripensamento.

Quali sono gli anti-pattern più comuni che vedi e in cosa inciampano i costruttori quando distribuiscono agenti autonomi in produzione rispetto a sviluppo/test?

L'errore più comune è trattare gli agenti come funzioni: invocati, eseguiti e poi dimenticati. In produzione, gli agenti devono mantenere il contesto, gestire gli strumenti e talvolta reagire a segnali esterni in tempo reale. Si sottovaluta anche quanto siano caotici gli ambienti reali: API instabili, dati incoerenti, transizioni di stato inaspettate. I builder spesso testano in condizioni ideali, ma la realtà produttiva richiede solide strategie di osservabilità, sandboxing e ripristino.

La vostra roadmap include funzionalità come il fork degli snapshot, il failover automatico e un'ottimizzazione più approfondita del calcolo. Quali considerate più trasformative per i sistemi agent-first?

Snapshot fork, senza dubbio. Sblocca debug, sperimentazione e modelli di ragionamento parallelo che non sono possibili negli ambienti cloud convenzionali. Immaginate un agente che raggiunge un punto decisionale: divide la sua sandbox in più rami, esplora diversi risultati in parallelo e quindi sceglie il percorso migliore da seguire. Questo tipo di logica di ramificazione è nativa dei flussi di lavoro degli agenti, ma completamente estranea ai runtime cloud tradizionali. Cambia radicalmente il nostro modo di concepire l'autonomia e il flusso di controllo.

Gartner prevede che entro il 75 il 2028% delle app utilizzerà agenti di intelligenza artificiale: come prevedi che si evolverà Blaxel man mano che gli agenti di intelligenza artificiale diventeranno onnipresenti in tutti i settori?

Con la diffusione degli agenti, ci aspettiamo che Blaxel si evolva da "infrastruttura per agenti di intelligenza artificiale" a "livello operativo" su cui si basano, gestendo il ciclo di vita, il coordinamento e persino le interazioni con il marketplace. Non ci si limiterà a distribuire agenti su Blaxel: li si comporrà, li si monitorerà e si avranno agenti che gestiscono altri agenti. Stiamo già assistendo all'emergere di casi d'uso in ambito finanziario, della sicurezza e dell'automazione aziendale che puntano in questa direzione.

Immaginate un futuro in cui gli agenti non solo eseguono le applicazioni, ma gestiscono e riconfigurano anche l'infrastruttura in modo autonomo? Quali sono le implicazioni culturali e di sicurezza di questo cambiamento?

Sì, ed è allo stesso tempo entusiasmante e snervante. Tecnicamente, ha senso: gli agenti possono monitorare lo stato del sistema, applicare patch, ottimizzare i carichi di lavoro. Ma culturalmente, mette in discussione il nostro modo di concepire il controllo e la fiducia nelle operazioni. Dal punto di vista della sicurezza, significa ripensare i modelli di autorizzazione: non solo chi può agire, ma ciò che un agente può diventareAvremo bisogno di nuove astrazioni per un'autonomia verificabile e un miglioramento personale vincolato.

Qual è il più grande equivoco su ciò che rende unica l'infrastruttura nativa dell'agente?

Che si tratta semplicemente di più GPU o tempi di esecuzione più lunghi. L'infrastruttura nativa degli agenti riguarda le affordance comportamentali, ovvero dare agli agenti la capacità di ricordare, esplorare, adattarsi e recuperare. Ciò richiede cambiamenti nell'intero stack: storage che tiene traccia dello stato in evoluzione, modelli di esecuzione che supportano concorrenza e ramificazione, osservabilità ottimizzata per il ragionamento, non solo per la latenza. È un cambiamento di mentalità, non solo un aumento delle risorse.

Quale rimpianto o limitazione tecnica del tuo periodo in OVHcloud sei più felice di aver risolto in Blaxel?

In OVHcloud, molto di ciò che abbiamo realizzato era vincolato da astrazioni legacy (VM, container, reti) ottimizzate per carichi di lavoro gestiti da utenti. Non potevamo facilmente abbandonare questi paradigmi. Con Blaxel, partiamo da zero. Non c'è bisogno di fingere che un agente sia un batch job o un microservizio. Possiamo integrare elementi primitivi come memoria, strumenti e obiettivi direttamente nel runtime, aprendo così uno spazio di progettazione completamente nuovo.

Grazie per l'ottima intervista, i lettori che desiderano saperne di più dovrebbero visitare Blaxel.