La funzionalità di punta di Hermes Agent v0.2.0 non era un'integrazione con un modello o un sistema di skill. Era il Gateway di Messaggistica Multi-Piattaforma — un singolo processo Hermes in ascolto su sette piattaforme di chat contemporaneamente: Telegram, Discord, Slack, WhatsApp, Signal, email (IMAP/SMTP) e Home Assistant. Con la release dell'8 aprile la lista era cresciuta a tredici, con l'aggiunta lungo la strada di Matrix, Feishu, WeCom, Mattermost, DingTalk e SMS (via Twilio).
La cosa facile da non cogliere qui è che costruire un bot Telegram non è poi così difficile. Costruire sette integrazioni chat simultanee che condividono un singolo agente, una singola memoria e un singolo registro di tool — è lì che va il lavoro architetturale. Questo post spiega come Hermes lo fa davvero.
L'approccio ingenuo, e perché non funziona
Se dovessi costruire "un bot IA che risponde su Telegram e Discord," il primo istinto sarebbe mettere in piedi due bot separati. Ognuno con il proprio processo, il proprio database, il proprio stato. Entrambi chiamano la stessa API del modello linguistico. L'utente su Telegram e quello su Discord ottengono concettualmente lo stesso agente ma in pratica ne ottengono due che non sanno nulla l'uno dell'altro.
Questo è ciò che fanno la maggior parte dei progetti bot esistenti, ed è terribile in modi che ci mettono un po' a diventare ovvi:
- •La memoria diverge. Un utente che menziona su Telegram di essere allergico alle arachidi non avrà quel dato quando farà una domanda sulla cucina su Discord. L'agente deve imparare la stessa cosa due volte.
- •Lo stato dei tool va fuori sincrono. Un cron job impostato via Slack non compare quando l'utente controlla i cron via Telegram. La cronologia delle sessioni è frammentata. I token di autorizzazione per risorse condivise (un'integrazione Notion, per dire) devono essere installati in ogni bot separatamente.
- •L'overhead operativo si moltiplica. N bot significano N processi, N servizi, N flussi di log, N file di configurazione, N posti dove qualcosa può rompersi. La complessità cresce linearmente con le piattaforme.
- •Le regole di sicurezza si frammentano. Se stringi una policy di approvazione per comandi pericolosi in un bot, devi ricordarti di aggiornarla negli altri. La deriva della sicurezza è lo stato di default.
Hermes fa una scelta diversa: esiste esattamente un processo agente, esattamente un database di sessioni, esattamente un archivio di memoria, esattamente un registro di tool. Le piattaforme sono adattatori — porte d'ingresso sottili che incanalano i messaggi dentro e fuori dall'agente condiviso.
La forma del gateway
Internamente, il gateway di Hermes ha tre livelli.
In fondo c'è l'agente stesso — lo stesso core Hermes che gira in modalità CLI. Non sa nulla delle piattaforme di chat. Riceve messaggi, esegue il suo loop agente (chiamate LLM, chiamate tool, lookup di memoria, checkpoint) e produce risposte. La sua unica interfaccia verso il mondo esterno è un'API basata su code.
Al centro c'è il core del gateway ��� gestione delle sessioni, routing utente/piattaforma, dispatch delle approvazioni, scheduling cron, streaming, gestione dei media. È la parte che trasforma "è arrivato un messaggio sulla piattaforma X dall'utente Y nel canale Z" in "un'esecuzione dell'agente nella sessione S con questi permessi." Gestisce anche le preoccupazioni condivise: rate limit, controllo del flooding, rilevamento di messaggi duplicati, timeout basati sull'inattività, routing dei bottoni di approvazione, stato cross-piattaforma.
In cima ci sono gli adattatori di piattaforma. Ce n'è uno per piattaforma: un adattatore Telegram, uno Discord, uno Slack, e così via. Il lavoro di un adattatore è stretto — connettersi alla piattaforma (via polling, long-poll, WebSocket, webhook, o qualsiasi cosa preferisca l'SDK della piattaforma), tradurre gli eventi nativi in arrivo nel formato interno dei messaggi del gateway, e tradurre le risposte in uscita del gateway in quello che la piattaforma si aspetta (Markdown, MarkdownV2, mrkdwn, rich embed Discord, HTML Matrix, blocchi Slack, MIME email).
Gli adattatori sono intenzionalmente piccoli. Aggiungere una nuova piattaforma (un contributore della community ha aggiunto Mattermost in meno di 300 righe di Python nella v0.4.0) è per lo più questione di mappare gli eventi dell'SDK nella forma interna dei messaggi del gateway e viceversa.
Come funzionano le sessioni tra piattaforme
Una sessione Hermes è un thread di conversazione con la propria finestra di memoria, stato dei tool e cronologia in corso. Su una singola piattaforma, le sessioni si mappano naturalmente — una sessione per chat Telegram, una per canale Discord, una per thread Slack. Tra piattaforme, le cose diventano più interessanti.
Di default, Hermes tratta ogni combinazione piattaforma/chat come una sessione distinta. Il tuo DM Telegram col bot, il tuo thread Slack col bot e il tuo canale Discord col bot sono tre conversazioni separate con tre contesti separati, ma condividono tutti la stessa memoria a lungo termine attraverso il provider di memoria pluggabile (Honcho di default dalla v0.7.0 in poi). Quindi le informazioni cross-sessione che ti aspetti viaggino — "l'utente è allergico alle arachidi," "l'utente si chiama Alice," "il progetto dell'utente si chiama Atlas" — viaggiano sul layer di memoria, mentre il contesto a breve termine di ogni conversazione resta circoscritto alla piattaforma che stai usando.
Questo è il design che permette allo stesso assistente di sembrare lo stesso assistente su ogni piattaforma, senza trasformare ogni messaggio in un broadcast globale aggrovigliato.
Perché le sessioni condivise nei thread contano
Nella v0.4.0, Hermes ha aggiunto una funzionalità chiamata sessioni thread condivise di default — nelle chat di gruppo, ogni utente ottiene la propria sessione dentro lo stesso thread. Sembra una cosa da poco ed è enorme per chiunque abbia mai provato a far girare un bot multi-utente in un gruppo.
Senza sessioni per utente in una chat di gruppo, ogni messaggio è parte di un'unica conversazione condivisa. Se Alice fa una domanda al bot e Bob ne fa una diversa trenta secondi dopo, il contesto del bot è un groviglio di entrambe. Le risposte si incrociano. La memoria per Alice si inquina con i dati di Bob. La modalità gateway peggiora man mano che si uniscono più utenti.
Con le sessioni thread condivise, Alice e Bob hanno ciascuno la propria sessione privata dentro il thread. Vedono i messaggi dell'altro nella chat visibile, ma l'agente mantiene contesti separati e scritture di memoria separate per utente. Nella v0.8.0 questo è diventato il comportamento di default su tutte le piattaforme del gateway. È il tipo di fix che è invisibile finché non sei stato scottato dall'alternativa, dopodiché non vuoi più tornare indietro.
A cosa serve davvero il gateway
Una volta che guardi l'architettura abbastanza a lungo, il gateway smette di sembrare "un modo per far girare bot su piattaforme chat" e inizia a sembrare quello che è realmente: un layer di coordinamento tra umani (su qualsiasi app stiano usando) e un assistente IA singolo con memoria e tool condivisi.
Le piattaforme di chat non sono il prodotto. Sono i punti di ingresso. Il prodotto è l'assistente che esiste dietro di loro, e il fatto che non devi mai pensare a quale punto di ingresso stai usando.
Questa è la funzionalità che Hermes ha consegnato il primo giorno. Tutto il resto è la storia di cosa quel layer di coordinamento ha imparato a fare nelle quattro settimane successive.