Il mondo degli LLM è in fermento più che mai. La parte che seguo con più interesse, onestamente, è quella Open Weight. Al 1 settembre 2026, sull’Intelligence Index di Artificial Analysis, Kimi K3 e GLM-5.3 stanno a 60 punti contro i 63 di Claude Opus 5 e i 61 di GPT-5.6 Sol. Non hanno preso il primato, e in cima alla classifica è appena arrivato Claude Fable 5.1 a 66 punti, quindi la frontiera nel frattempo si è spostata ancora. Restano però tre punti da Opus 5, un’inezia rispetto al distacco a cui eravamo abituati. Attenzione, non voglio soffermarmi troppo sui benchmark, li ho testati con mano e i miglioramenti sono tangibili.

Purtroppo la mia infrastruttura domestica non regge modelli di questa portata, localmente devo accontentarmi di modelli fino a 30B di parametri. Kimi e GLM, però, si possono testare via API a un costo per token irrisorio rispetto ai modelli di frontiera privati.

Però, devo ammettere che sta diventando sempre più difficile stare al passo con l’innovazione. Ogni volta che ti sposti da un Coding Agent a un altro per testare un nuovo modello, o perché il tuo progetto si blocca per i limiti del provider, la tua produttività ne risente. In queste circostanze entra in gioco Omnigent.

Lavoro quotidianamente su Databricks e sfrutto tutte le funzionalità della piattaforma. Tra le ultime novità c’è Omnigent, che cambia il modo di lavorare con Databricks ma può vivere anche di vita propria. Puoi distribuirlo anche al di fuori di Databricks, quindi non potevo esimermi dal testarlo sul mio server domestico.

Omnigent è un progetto open source e si definisce un meta-harness, rilasciato sotto Apache License 2.0 da Databricks, sviluppato dal team AI insieme a Neon.

Prima però facciamo un passo indietro. Cos’è un harness? Nel mio blog è la prima volta che incontriamo questo termine.

Che cos’è un harness e in cosa si distingue da un coding agent?

Un harness è l’infrastruttura che permette a un LLM di trasformare le proprie risposte in azioni concrete.

Il modello, cioè il “cervello” del sistema (per esempio Claude Opus 5 o GPT-5.6), riceve un contesto, come una domanda e genera una sequenza di token, ovvero il testo della risposta. Preso da solo, però, non può aprire file, eseguire comandi, accedere a un repository o ricordare ciò che ha fatto in una sessione precedente.

L’harness mette il modello nelle condizioni di lavorare, gestendo:

  • loop agentico: il ciclo tra decisione, azione e risultato
  • tools: l’accesso al filesystem, alla shell e ad altri strumenti
  • permessi
  • finestra di contesto: cosa caricare, riassumere o eliminare
  • la memoria della sessione
  • sub-agenti

Un Coding Agent, invece, è il sistema completo specializzato nello sviluppo software. Normalmente comprende LLM, harness, istruzioni, strumenti e regole operative.

Claude Code, Codex e OpenCode sono quindi prodotti o Coding Agent completi, non semplicemente harness. Anche quando Coding Agent diversi utilizzano lo stesso LLM, possono comportarsi in modo molto diverso perché cambiano il contesto fornito, gli strumenti disponibili, i permessi, ecc… In sostanza cambia il modo in cui viene organizzato il lavoro.

In breve:

L’LLM pensa, l’harness gli permette di agire, il coding agent è il sistema completo che svolge il lavoro.

Che cos’è, invece, un meta-harness?

Un meta-harness è il livello di orchestrazione posto sopra diversi agenti e i rispettivi harness. Fornisce un’interfaccia comune che permette di combinarli, sostituirli e farli collaborare senza dover riscrivere ogni volta l’intero sistema.

Può inoltre applicare policy centralizzate per controllare permessi, costi e operazioni rischiose, gestire l’esecuzione in ambienti isolati e coordinare il lavoro tra agenti, persone e modelli differenti.

Possiamo definire un meta-harness come un livello comune sopra diversi agenti e harness: li rende interoperabili, li orchestra e applica policy trasversali.

Cos’è Omnigent e quali sono le caratteristiche principali

Omnigent si definisce esattamente così, un meta-harness open source che dà un layer di orchestrazione comune sopra Claude Code, Codex, Cursor, OpenCode, Hermes, Pi e gli agenti che scrivi tu.

Omnigent come layer di orchestrazione tra i client e gli harness nativi

Utilizzando questo framework mi sono reso conto di quanto sia importante la scelta del Coding Agent e la configurazione del progetto, ne va della qualità dell’output e del costo del progetto.

Con Omnigent puoi avviare un progetto e sfruttare diversi agenti con diversi modelli, rende possibile far sedere allo stesso tavolo diversi Agenti e farli lavorare in team. Puoi così usare modelli Open Weight in locale, anche nei workflow più impegnativi.

Per esempio sto progettando un workflow lavorativo per l’analisi e la configurazione della mia Data Platform, posso delegare l’analisi dei file sorgente ad un modello open weight che gira sulla mia Workstation domestica per l’inferenza locale, mantenendo il pieno controllo dei miei dati personali, estrarre i metadati per poi continuare la configurazione della mia piattaforma utilizzando i modelli di frontiera che indubbiamente riescono a performare meglio nello sviluppo rispetto ad un modello open weight di 30B di parametri.

Un altro punto di forza di Omnigent è la versatilità di utilizzo, oggi sto testando la distribuzione di questo progetto sul mio server locale, grazie alla mia VPN posso collegarmi da remoto anche da mobile alla piattaforma e continuare il mio workflow lavorativo anche da remoto sfruttando comunque un setup desktop senza rinunciare a nulla.

L’architettura del progetto Omnigent chiarisce come funziona questo concetto.

Architettura

Dalla descrizione ufficiale dell’architettura troviamo la distinzione di due componenti chiave, il runner avvolge un agente qualsiasi in una sessione sandboxata con un’API uniforme, un server aggiunge policy e history condivisa ed espone ogni sessione su terminale, web, app nativa, mobile e API REST.

Omnigent Architettura

Ci sono diverse modalità per accedere a Omnigent:

  • Da terminale, Omnigent può avviare la CLI nativa del vendor così com’è e la aggancia alla sessione (omnigent claude, omnigent codex e gli altri); omnigent run agent.yaml lancia un agente definito da te su un harness raggiunto via SDK. Terminale Omnigent
  • Da Web UI su localhost:6767, l’interfaccia comune di tutte le tue sessioni. Le sessioni ti seguono, inizi nel terminale, continui nel browser, la riprendi da mobile. Web UI Omnigent
  • Da mobile scaricando l’app ufficiale App Omnigent

Puoi cambiare continuamente client, la sessione resta la stessa! Omnigent filesystem integrato

Ogni azione passa da policy, credenziali e runner. Quest’ultimo mette l’agente in una sandbox: bwrap su Linux, seatbelt su macOS oppure una sandbox remota usa e getta su Modal, E2B, Kubernetes e altri. Dentro l’harness gira l’agente con i suoi tool, funzioni Python locali, server MCP, sub-agenti.

Un team, non un assistente

Qui sta la parte che cambia il modo di lavorare, citando la frase presente nel README del progetto:

“Ask one agent to review another’s work, or split a task across agents that are each good at different things.”

Invece di scegliere un solo modello o un solo Coding Agent, assegniamo il task a chi è più adatto e facciamo collaborare gli agenti.

Per creare il nostro team di agenti, ci basterà definire il file YAML di configurazione del nostro modello mentale del progetto:

name: my_agent
prompt: You are a helpful data analyst.

executor:
  harness: claude-sdk          # or: claude-native, codex, codex-native, cursor,
                               # cursor-native, hermes, hermes-native, opencode,
                               # pi, pi-native, openai-agents

tools:
  # A local Python function (schema auto-generated from the signature)
  word_count:
    type: function
    callable: mypackage.mymodule.word_count

  # Tools from an MCP server (a local command, or a remote URL)
  docs:
    type: mcp
    url: https://example.com/mcp

  # A sub-agent the supervisor can delegate to
  researcher:
    type: agent
    prompt: Search for relevant information and summarize it.
    tools:
      word_count: inherit

L’harness è un campo come un altro, quindi la riga che cambi per portare l’agente da Claude Code a Codex è una sola. Un sub-agente è dichiarato come un tool, con un suo prompt e i tool ereditati dal supervisore, la delega non è una funzionalità a parte, è la stessa struttura applicata ricorsivamente. E i server MCP sono il modo in cui l’agente raggiunge il mondo esterno.

Nel repository ci sono degli agenti d’esempio che mostrano dove porta questa struttura.

  • Polly: il tuo tech lead, pianifica, delega a sub-agenti in git worktree paralleli, e manda ogni diff a un reviewer di un vendor diverso da quello che l’ha prodotto.
  • Debby: è un partner di brainstorming con due teste, una Claude e una GPT, e risponde a ogni domanda con le due risposte affiancate.

Ecco in azione Debby: Debby Debby - Claude Debby - GPT Debby - Confronto

Con questo nuovo approccio, smetti di ragionare per strumento e inizi a ragionare per compito, a ogni pezzo di lavoro assegni il modello e l’harness che gli servono, e aprire Claude Code invece di Codex diventa un dettaglio di configurazione.

Un Team allargato

Fin qui ho parlato di agenti che collaborano tra loro, ma il team non è composto solo da loro!

Omnigent prende la sessione e la trasforma in un ambiente condiviso.
Esistono diverse modalità di accesso, ad una sessione (chat), e sono ben più differenti tra loro di quanto sembri.

  • Share: condividi la sessione con un link. Chi entra ha la history completa, guarda l’agente lavorare in tempo reale e può chattare con lui.
  • Co-drive: il collega si aggancia e manda comandi che vengono eseguiti sulla tua macchina, dentro la tua sessione.
  • Fork: chi entra clona la conversazione sulla propria macchina e prosegue per conto suo dal punto in cui si è staccato.

L’annuncio ufficiale lo riassume in una riga:

“You can invite other people to view your agent session, comment on files in its workspace, or even send commands, so your sessions and working directories become the main place you collaborate”.

Il salto non è poter mostrare a un collega cosa ha prodotto il tuo agente, è poter condividere il ragionamento in tempo reale, lavorare sugli stessi file del progetto. Cambia il tipo di interazione, se i tuoi colleghi vedono la sessione dall’inizio, non devono ricostruire la storia dal riassunto del progetto o intuire il comportamento dei file, questa è la parte in cui di solito si perde l’informazione che serviva. Le tre modalità coprono le diverse esigenze, il fork è per chi vuole provare una strada alternativa senza disturbarti, il co-drive è per chi ne sa più di te su quel pezzo e fa prima a metterci lui le mani, lo share è per tutti gli altri.

C’è però una cosa da mettere in chiaro proprio sulla modalità co-drive, stai dando a un’altra persona la possibilità di eseguire comandi sulla tua macchina, dentro una sessione che ha già i tuoi permessi e le tue credenziali. È esattamente il motivo per cui le policy di cui parlo qui sotto non sono un accessorio.

Le policy stanno fuori dal prompt

Una nota importante sulle policy è espressamente ripresa nella documentazione del progetto ufficiale: i guardrail sono applicati “at the meta-harness layer, not via prompts”. Chi ha provato a governare un agente scrivendo “non toccare la produzione” nel system prompt sta chiedendo un favore a un modello. Qui la richiesta viene intercettata prima di arrivare al sistema operativo, e il modello non ha voce in capitolo.

Le policy si impilano su tre livelli, server, agente e sessione, con le regole di sessione più strette valutate per prime. Si dichiarano con un nome tuo e puntano a un handler built-in: ask_on_os_tools chiede la tua approvazione prima delle operazioni su shell e file, max_tool_calls_per_session mette un tetto alle chiamate, cost_budget un limite di spesa con soglia di preavviso.

Quello che le rende diverse da una lista di permessi è che tengono conto di cosa è già successo nella sessione. L’esempio dell’annuncio è il migliore che abbia letto sul tema, puoi stabilire che, dopo che un agente ha scaricato un pacchetto nuovo da npm, un git push richieda approvazione umana. La stessa logica si applica sul budget del progetto, l’agente si ferma e ti chiede se vuoi continuare.

Le cose a cui stare attenti

Comincio dalla più semplice. Il repository pubblico è stato aperto l'11 giugno 2026 e il progetto si dichiara alpha. Al 1 settembre conta 9.587 stelle, 1.482 fork e 1.200 issue aperte, interfacce che cambiano, funzionalità che mutano, aspettative da tarare di conseguenza. Se lo metti in mezzo al flusso di lavoro di un team, lo fai sapendo che stai costruendo su terreno mobile.

Utilizzando Omnigent mi chiedo, più agenti che lavorano in parallelo sono davvero un vantaggio? Un agente che lavora da solo lo segui, tre agenti che lavorano in parallelo non li segui, ne vagli le implementazioni.

Questi nuovi strumenti mi portano a riflettere sul mio ruolo che sta cambiando, passo molto meno tempo a scrivere codice e molto più tempo a raccontare le mie idee, mentre qualcun altro, un agente che non si stanca, non si annoia, procede nell’implementazione. È un lavoro diverso, e soprattutto si degrada in modo diverso.

Quando scrivi codice, implementi nuove architetture e sei stanco rallenti … quando revisioni il lavoro dei tuoi agenti e sei stanco approvi.

Questi strumenti sono un’arma formidabile e fondamentale, attenzione però, non dobbiamo pensare di poter fare di più stancandoci meno, perché per ottenere un risultato di alta qualità l’attenzione deve essere massima.

Verso che direzione stiamo andando?

Prima contava il modello, poi il Coding Agent. Se la direzione è questa, il passo successivo è chiedersi: com’è composto il Team di Agenti, e chi può fare cosa? Quali compiti affidi a un modello che gira in casa e quali a un modello di frontiera, chi revisiona il lavoro di chi, chi altro può aggiungersi e con quali permessi, e cosa hai messo per iscritto che nessuno di loro può toccare.

Sono le stesse domande che ci si fa quando si mette in piedi un team di persone, ed è il motivo per cui il titolo di questo articolo parla di estendere il tuo Team di lavoro. Solo che non è una metafora, nel tuo team ci sono gli agenti che hai scelto e i colleghi che inviti nella sessione. La differenza rispetto a un team qualsiasi è che qui sei tu a definire i tuoi colleghi agenti in un file YAML, e le regole dei componenti non le chiedi per cortesia, le scrivi in una policy.

Resta fuori da questo articolo il pezzo che mi vede coinvolto di più, cioè cosa succede quando questo layer incontra la piattaforma dati che ci sta sotto. L’integrazione nativa di Omnigent con Databricks merita un articolo dedicato. Voglio farlo con test ben approfonditi e ci sto lavorando.

Risorse