OpenConnector: il gateway open source che collega gli agenti AI a più di mille software

Perché se ne parla#

Un agente AI che sa solo chiacchierare serve a poco. Diventa utile quando può fare le cose: leggere la posta, aprire una scheda nel CRM, aggiornare una tabella, pubblicare una modifica su GitHub. Per riuscirci deve entrare nei software che l'azienda usa ogni giorno, e ognuno di quei software ha la sua porta, la sua chiave e le sue regole.

OpenConnector nasce proprio per questo. È un progetto open source di OOMOL Lab, rilasciato con licenza Apache 2.0, che si mette in mezzo tra l'agente e i servizi in cloud: una specie di portineria che custodisce tutte le chiavi e apre la porta giusta quando l'agente la chiede. Il catalogo, al momento dell'annuncio, contava 1.127 servizi e 11.017 azioni già pronte.

Il progetto si presenta apertamente come alternativa a Composio, un servizio già noto a chi sviluppa agenti. La prima versione è uscita il 29 giugno 2026; la release 1.3.0, del 17 luglio 2026, ha reso stabile il kit di sviluppo.

La scheda del progetto#

Il problema: ogni software ha la sua serratura#

Prendete un agente che deve preparare un riepilogo settimanale: legge le email in Gmail, controlla le attività su Notion, recupera i numeri da BigQuery e manda il risultato su Slack. Sono quattro servizi, e ognuno chiede di essere trattato in modo diverso.

Senza un gateway#

Chi costruisce l'agente deve occuparsi di tutto da sé, servizio per servizio:

• ottenere e conservare le credenziali;

• gestire l'OAuth, cioè la schermata "Consenti a questa app di accedere al tuo account" che conoscete da quando usate "Accedi con Google";

• rinnovare i refresh token, i permessi a scadenza che vanno aggiornati periodicamente perché l'accesso non si interrompa;

• chiamare direttamente le API di ciascun fornitore, ognuna con il suo formato.

Moltiplicate per ogni servizio e per ogni agente, e il lavoro di "idraulica" supera quello sull'agente vero e proprio. Peggio ancora, le chiavi finiscono sparse in troppi posti.

Con OpenConnector#

Il gateway raccoglie tutto in un unico strato. In concreto offre cinque cose:

1. Un catalogo di servizi: più di 1.100, tra cui Salesforce, Gmail, Supabase, GitHub, Airtable, Slack, Notion e BigQuery.

2. La gestione delle credenziali per ogni tipo di accesso: chiavi API, OAuth2, credenziali personalizzate e anche servizi che non richiedono autenticazione.

3. Contratti delle azioni leggibili: per ogni azione si può vedere cosa riceve, cosa restituisce, quali permessi servono e il codice dell'esecutore, che si carica solo quando serve.

4. Controlli mentre l'agente lavora: identità della connessione, ambiti di accesso, token temporanei, regole che permettono o bloccano singole azioni, file di appoggio e registri delle esecuzioni con i dati sensibili oscurati.

5. Diverse opzioni di installazione, dal computer dello sviluppatore fino al servizio gestito (le vediamo più sotto).

Un'azione, per capirci, è un'operazione già scritta e collaudata: "crea una pagina", "cerca tra le email", "aggiungi una riga alla tabella". L'agente non deve sapere come parlare con Notion o con Airtable: chiede l'azione e il gateway la esegue.

Come funziona, passo per passo#

L'architettura è a strati, e il percorso di una richiesta è lineare:

1. L'agente, o l'applicazione che lo contiene, chiama il gateway attraverso una delle sue interfacce (kit di sviluppo, riga di comando, MCP o HTTP).

2. Il gateway verifica l'autenticazione e, se serve, gestisce il passaggio OAuth con il servizio esterno.

3. Consulta il catalogo per sapere come si esegue l'azione richiesta.

4. La esegue tramite gli esecutori, anch'essi open source.

5. Applica le regole su token, ambiti e liste di azioni consentite o bloccate.

6. Restituisce il risultato e scrive un registro dell'esecuzione.

Il punto più importante per un'azienda è un altro: i segreti dei fornitori non attraversano mai il confine del gateway. L'agente riceve solo metadati, un'etichetta sicura che identifica l'account e l'esito dell'operazione. La password di Gmail o la chiave di Salesforce restano chiuse dentro.

OOMOL mostra anche una console web di amministrazione, da cui si gestiscono connessioni e regole senza passare dal codice.

Quattro modi per collegarlo#

OpenConnector si aggancia a quasi qualsiasi progetto perché offre quattro interfacce diverse. La scelta dipende da come è costruito l'agente.

L'MCP merita due parole: è lo standard, ormai adottato da molti strumenti, con cui un assistente AI scopre quali "attrezzi" ha a disposizione e li usa. Grazie a questa interfaccia, programmi come Claude Code o Cursor possono chiamare le azioni del catalogo senza integrazioni scritte apposta.

Dove installarlo: quattro strade#

L'ultima riga tocca un problema concreto. Per usare l'OAuth di molti servizi bisogna registrare la propria applicazione e, spesso, aspettare che il fornitore la approvi. Con la versione ospitata da OOMOL si parte subito usando le loro autorizzazioni, e in un secondo momento si può passare a un'installazione propria senza riscrivere le integrazioni.

Per chi è pensato#

Gli sviluppatori del progetto indicano tre situazioni tipiche:

• prodotti basati su agenti che hanno bisogno di un accesso riutilizzabile a strumenti di lavoro, piattaforme di sviluppo, sistemi di dati e servizi AI;

• prodotti esistenti che aggiungono funzioni agentiche e vogliono contratti stabili e controllabili per entrare nelle applicazioni dei propri utenti;

• team che vogliono partire in fretta con l'autenticazione ospitata, tenendosi la possibilità di spostarsi su un runtime proprio.

Cosa porta la versione 1.3.0#

La release del 17 luglio 2026 aggiunge tre cose:

• il Connector SDK dichiarato stabile;

• il supporto a Cloudflare Workers, con D1 per lo stato e R2 per i file;

• la console web per gestire connessioni e regole.

Per chi vuole provare la strada Cloudflare, il team ha pubblicato su YouTube un tutorial di avvio rapido che mostra la configurazione in pochi minuti.

Guarda il videoSi apre da YouTube: i suoi cookie partono solo dopo il clic.

Attorno a OpenConnector, OOMOL Lab mantiene anche la oo CLI e il Connector SDK come progetti a sé, più la piattaforma ospitata su oomol.com, che fornisce runtime e autenticazione gestiti.

Cosa significa per un'azienda#

Se in azienda qualcuno sta costruendo agenti (un fornitore, un reparto interno, un consulente), OpenConnector cambia i conti su tre fronti.

• Tempo di sviluppo. Con 11.017 azioni già pronte, anche un progetto che deve toccare solo cinque o sei software risparmia subito il lavoro più noioso: autenticazioni, rinnovi, formati delle API.

• Libertà commerciale. La licenza Apache 2.0 permette di usarlo, modificarlo e inserirlo in prodotti a pagamento senza vincoli.

• Controllo su dati e chiavi. Con l'installazione propria, credenziali e registri restano sui vostri server o sul vostro account cloud.

In più, grazie a MCP, al kit TypeScript e alla riga di comando, si inserisce nella maggior parte degli stack moderni: dagli agenti che lavorano con Claude Code, Codex o Cursor fino alle piattaforme costruite su misura. Se volete capire meglio cosa può fare un agente in pratica, trovate esempi concreti nella guida su cosa sono gli agenti AI.

OpenConnector o Composio?#

OpenConnector si propone come alternativa completa e interamente open source a Composio. Le differenze dichiarate sono due:

• la licenza: OpenConnector è tutto Apache 2.0, mentre Composio include componenti a codice chiuso;

• l'ecosistema: attorno a OpenConnector ci sono il kit di sviluppo, la riga di comando e la piattaforma ospitata di OOMOL, tutte opzioni in più e non obblighi.

Un confronto su prestazioni, affidabilità e qualità dei singoli connettori, però, non fa parte dell'annuncio: chi deve scegliere tra i due farà bene a provarli entrambi sui servizi che gli interessano davvero.

Cosa resta da capire#

Il mio parere#

Tra i progetti open source usciti quest'anno per chi costruisce agenti, OpenConnector è uno dei più pratici. Mi piace soprattutto che non inventi un protocollo nuovo: si appoggia a quello che c'è già (MCP, OpenAPI, TypeScript) e si concentra su un problema noioso ma reale, cioè far entrare un agente nei software aziendali senza spargere password ovunque.

Per chi sviluppa agenti per clienti business, valutarlo come strato di integrazione può voler dire risparmiare settimane di lavoro su OAuth e API. La cautela è quella di ogni progetto con tre settimane di vita: prima di affidargli dati importanti proverei i connettori che servono davvero, controllerei i registri e le regole di blocco, e partirei con permessi stretti.

Se state pensando di collegare un agente ai vostri gestionali e volete capire da dove partire e con quali regole, è il tipo di lavoro che faccio nei progetti di automazione e integrazione.

Domande frequenti#