Il modello dominante degli agenti AI basati sul cosiddetto MCP (Memory, Computation, Perception) sembrava il Santo Graal. La promessa era seducente: una struttura modulare dove ogni componente è specializzato, orchestrato da un protocollo che coordina tutto con precisione svizzera. Una sinfonia di moduli che collaborano attraverso API pulite, endpoint ben documentati e logiche preconfezionate. Peccato che, nella realtà, sembri più un’orchestra di strumenti scordati che suona in una sala prove senza elettricità.

Aravind Srinivas, co-fondatore e CEO di Perplexity AI, non è tipo da risparmiarsi nei giudizi. E ha detto a voce alta quello che molti sviluppatori pensano sottovoce: “Il paradigma MCP rende gli agenti fragili. Li costringe a dipendere da server esterni che devono funzionare perfettamente, sempre”. Tradotto in linguaggio meno polite: se il tuo agente AI per interagire con il mondo ha bisogno che qualcun altro implementi bene un protocollo, stai costruendo sabbie mobili e vendendole come cemento armato.

Comet, il framework che Srinivas propone come alternativa, rovescia completamente il tavolo. Invece di affidarsi a una coreografia di microservizi perfettamente sincronizzati, dà agli agenti un browser vero. Con tanto di schede, link cliccabili, JavaScript in esecuzione e tutte le inconsistenze, pop-up pubblicitari e HTML malformato che rendono il web… beh, il web. Non è una scorciatoia. È un atto deliberato di anarchia tecnica mascherata da pragmatismo.

Perché è importante? Perché la differenza non è solo architetturale. È filosofica, quasi politica. Un agente che deve dipendere da una middle layer controllata da terzi è come un bambino con le rotelle: funziona finché il genitore tiene la mano. Ma il giorno che l’endpoint dell’API cambia, o il server remoto crasha, o un aggiornamento rompe la compatibilità retroattiva, ecco che l’intero castello crolla. Un agente basato su browser, al contrario, vive nel caos nativo dell’internet reale. Come un utente umano, sa che nulla è perfettamente strutturato e che la resilienza non nasce dalla rigidità, ma dall’adattabilità.

A qualcuno sembrerà una regressione. Perché far fare scraping a un agente AI, con tutti i rischi legati a DOM dinamici, CAPTCHA e interfacce non standardizzate, quando potresti avere un’API REST ben documentata? La risposta è semplice: perché le API ben documentate sono un’illusione temporanea. Sono castelli di carta che crollano al primo refactor non coordinato. L’internet vero, quello su cui le persone vivono, comprano, leggono, cliccano, non è fatto di interfacce semantiche. È fatto di click, scroll, form e iframe. E se vogliamo agenti che sopravvivano al tempo e ai bug degli altri, dobbiamo allenarli nel fango, non nella palestra sterilizzata del protocollo MCP.

C’è un parallelo interessante con la storia del software. Negli anni 2000, tutto ruotava attorno ai “middleware”. Oracle, IBM, SAP vendevano stack interi per orchestrare flussi e transazioni, ma bastava che un nodo fallisse per bloccare l’intera pipeline. Poi sono arrivati gli sviluppatori con il linguaggio Python, i microservizi, le architetture loosely coupled e, soprattutto, un’idea molto chiara: meno dipendenze forti, più antifragilità. Comet sembra voler portare quella stessa filosofia nel mondo degli agenti.

Certo, usare un browser comporta una serie di nuove sfide. Devi costruire agenti capaci di gestire interfacce imprevedibili, riconoscere pattern visivi, simulare comportamenti umani realistici. Ma questi non sono bug. Sono feature. Perché l’obiettivo non è creare un agente che esegue task in condizioni ideali, ma uno che riesce a portare a termine il compito anche quando il sito cambia il layout, l’elemento HTML ha un ID diverso, o compare un popup inaspettato. Non perfetto, ma adattabile. Non elegante, ma robusto.

La logica di Comet è brutale nella sua semplicità: se vuoi che i tuoi agenti si comportino come utenti umani, devono usare lo stesso strumento che usano gli umani. E quel strumento si chiama browser, non “getProductDetails” o “/v1/submitForm”. Ecco perché ogni agente basato su Comet ha accesso diretto al browser. Non passa da un interprete. Non media con un’altra AI. Non chiede il permesso a un protocollo. Clicca, esplora, sbaglia, corregge. Come farebbe un essere umano con un po’ di senno e molta curiosità.

La provocazione vera, in tutto questo, è che l’approccio browser-first non è solo una scelta tecnica. È una critica implicita a tutta l’idea di AI “safe by design”. Comet suggerisce che la sicurezza, l’affidabilità e la capacità di portare a termine un compito non si ottengono sterilizzando l’ambiente, ma esponendo l’agente alla realtà più caotica possibile. Perché il caos non è un’eccezione. È la normalità. E un agente che sa nuotare solo in piscina non sopravvivrà mai in mare aperto.

Srinivas lo dice con parole taglienti: “Non devi fare affidamento sul fatto che qualcun altro faccia ingegneria bene dalla sua parte”. Il che, detto in maniera meno diplomatica, significa: costruisci agenti che non si fidano di nessuno. Neppure di te. Perché in un mondo distribuito, asincrono, buggato e in continua evoluzione, la fiducia cieca è una vulnerabilità, non un vantaggio competitivo.

Questo approccio potrebbe far storcere il naso ai puristi. Ma il purismo architetturale ha già prodotto abbastanza fragilità per un paio di decenni. Quello che serve ora sono sistemi resilienti, agenti che non si spezzano alla prima dissonanza, intelligenze artificiali che si muovono nel web come hacker gentili, pronti a tutto, anche a interpretare un bottone senza ID o a compilare un form con un layout bizzarro.

In fondo, non è un’utopia. È una semplice constatazione darwiniana: sopravvive chi sa adattarsi. E un agente che ha bisogno di un MCP server sempre online, ben configurato, aggiornato e in grado di interpretare esattamente le richieste… non è un sopravvissuto. È un candidato al fallimento silenzioso.

Comet non promette eleganza. Promette resilienza. E se il web è un campo di battaglia, meglio avere un agente armato di browser piuttosto che di sogni protocollari.