C'è una simmetria troppo perfetta per non funzionare come titolo: un amministratore delegato licenzia gli sviluppatori per fare posto all'AI, gli sviluppatori rispondono scrivendo un amministratore delegato open source. È così che Open Executive è arrivato in cima a Hacker News a fine agosto, ed è così che l'hanno raccontato TechRadar, Gigazine e una decina di altre testate.
La storia, per come circola, non è verificata: l'azienda che avrebbe licenziato non è mai stata nominata, e i materiali pubblici di Sente Labs — il laboratorio che firma il progetto — non presentano Open Executive come una ritorsione. Il post su Hacker News, peraltro, l'ha inviato il fondatore del laboratorio a proposito del proprio repository. Vale la pena mettere da parte la cornice narrativa e guardare cosa c'è nel codice, perché il codice è la parte interessante.
Cosa promette
Il repository è SenteLabsAI/OpenExecutive,
licenza Apache 2.0, Python più TypeScript. La prima release pubblica — la 0.1.0 nel
changelog — è del 30 giugno 2026; oggi il progetto viaggia intorno alle 3.950 stelle e
400 fork, con commit quotidiani.
L'idea è dichiarata in una riga: un sistema che si comporta come il team dirigenziale della vostra azienda, «un consulente senior con conoscenze di livello MBA di Harvard». Chi scrive non parla con otto chatbot, ma con una sola voce esecutiva, dietro la quale lavorano otto agenti specialisti che l'utente non vede mai:
- Chief Strategy Officer — analisi competitiva, M&A, posizionamento, OKR
- Chief Financial Officer — modelli finanziari, raccolta capitali, unit economics, cassa
- Chief HR/People Officer — assunzioni, retribuzioni, performance, cultura
- General Counsel — contratti, proprietà intellettuale, diritto del lavoro, compliance
- Chief Operating Officer — processi, fornitori, scalabilità operativa
- Chief Marketing Officer — go-to-market, marca, comunicazione, PR
- Chief Product Officer — roadmap, prioritizzazione, strategia di prodotto
- Board Communications Director — materiali per il consiglio, investor relations
L'espressione «livello MBA di Harvard» è un claim di marketing del progetto, non una misura: serve a dire che la base di conoscenza è composta da framework manageriali scritti a mano in Markdown, non che qualcuno abbia certificato l'equivalenza.
Come funziona davvero
Qui il progetto è più solido di quanto la copertura giornalistica lasci intendere. Niente LangGraph, niente CrewAI: chiamate diritte all'SDK di Anthropic, orchestrazione scritta a mano.
Il routing è una decisione del modello, non un if. L'orchestratore espone un tool
consult_specialist; quando la risposta torna con stop_reason == "tool_use", il sistema
estrae i blocchi, esegue le chiamate agli specialisti in parallelo con asyncio.gather()
e reinietta i risultati nel giro di conversazione. È il modello a scegliere chi consultare,
e questo è insieme il pregio e il punto fragile dell'architettura.
La conoscenza sta su due livelli. Il primo è la base MBA integrata, Markdown versionato nel repo e caricato in ChromaDB all'avvio. Il secondo sono i vostri documenti — pitch deck, modelli finanziari, note strategiche — spezzati in chunk da 512 parole con 50 di sovrapposizione e tenuti in una collezione separata. Ogni chiamata a uno specialista fa una ricerca semantica filtrata per dominio e recupera 5 chunk dalla base interna più 3 dai documenti aziendali. Dettaglio non banale: il contesto recuperato viene iniettato nel turno utente, mai nel system prompt.
La cache è progettata, non subita. Il prompt è ordinato in strati: persona esecutiva,
profilo aziendale e indice della conoscenza vanno in blocchi con TTL di un'ora; la cronologia
in un blocco a 5 minuti; decisioni passate, documenti recuperati e messaggio corrente non
vengono mai messi in cache. Le regole di igiene sono esplicite — nessun datetime.now() nei
blocchi cacheati, tool ordinati alfabeticamente, JSON serializzato con sort_keys=True — e
il risultato dichiarato è fino all'85% di cache hit dopo i primi turni. Chi ha provato a
tenere sotto controllo il conto di un sistema multi-agente sa che questa è la differenza fra
un prototipo e qualcosa che si può lasciare acceso.
La memoria è la parte che rende il progetto un prodotto e non una demo. Dopo ogni
risposta parte in background un passaggio con claude-haiku-4-5 e un tool store_memories
che estrae decisioni, iniziative, consigli e azioni programmate su SQLite. La sessione
successiva si apre con un blocco <past_decisions> con gli otto elementi più recenti: il
sistema si ricorda cosa aveva consigliato il mese prima. C'è poi uno scheduler che rivendica
i lavori dovuti con UPDATE … RETURNING per non farli partire due volte, un sistema di
alert con triage per severità (60 eventi al minuto di rate limit) e un audit log
append-only con redazione di email, telefoni e carte di credito.
Le interfacce sono sei più la CLI: web, Slack, email via poller Gmail, Telegram, Google
Chat, Discord. I modelli di default sono claude-sonnet-5 per l'esecutivo e la maggior parte
degli specialisti, claude-opus-5 con extended thinking per i quattro ruoli ad alto rischio
(CSO, CFO, General Counsel, Board), claude-haiku-4-5 per il routing. Ma il sistema si può
far girare interamente su modelli locali — Ollama, LM Studio, vLLM, llama.cpp — o via
OpenRouter, scegliendo il modello agente per agente da una "Council UI". Con una avvertenza
scritta nel README che vale per chiunque colleghi un gateway esterno: tutto quello che
l'esecutivo elabora, profilo aziendale e documenti compresi, finisce all'endpoint che avete
configurato.
Cosa non torna
Chi è andato a guardare il repository con occhio meno entusiasta ha trovato tre cose, e reggono ancora.
La prima: il commit iniziale — 888 file — è firmato Claude <noreply@anthropic.com>.
Un sistema che promette di sostituire il lavoro dirigenziale è stato in larga parte scritto
da un modello. Non è una colpa, è un dato che andrebbe messo accanto al claim.
La seconda: il README ha derivato dal codice. Dice che evals/ contiene 29 scenari; oggi
evals/ contiene un runner e i giudici, e gli scenari sono 47 file YAML sotto
packages/core/openexecutive/evals/_scenarios/. Anche docs/architecture.md è rimasto
indietro, e parla ancora di Opus 4.7 e Sonnet 4.6 dove README e .env.example dicono Opus 5
e Sonnet 5. Sono discrepanze innocue in sé, meno innocue in un progetto la cui tesi è che la
documentazione strategica possa essere generata e mantenuta da una macchina.
La terza: non scala. Poiché lo scheduler rivendica le righe con UPDATE … RETURNING,
due macchine API farebbero partire due volte ogni azione programmata. Nella configurazione
Fly.io c'è max_machines_running = 1 e il README raccomanda di non toccarlo. Il "team
dirigenziale" gira su una macchina sola.
C'è poi la valutazione. Il sistema di eval è serio per gli standard del settore — scenari con contesto aziendale simulato, routing atteso, rubrica per dominio, giudizio LLM su cinque dimensioni da 1 a 5, soglia di CI a 3,5 e regressione oltre il 10% che blocca la PR — ma misura una cosa precisa: se le risposte sono coerenti, pertinenti e azionabili. Non se il consiglio produce valore. È la distanza fra un sistema di supporto alle decisioni e un sostituto della responsabilità dirigenziale, ed è tutta lì.
Due issue che valgono un editoriale
Nel tracker del progetto convivono i due modi in cui il mondo ha reagito a Open Executive.
La #41, aperta il 28 agosto: «[Bug] I miei dirigenti si stanno pagando bonus enormi!!». Passi per riprodurre: «alzare sicofantia e psicopatia». Comportamento atteso: «trickle down economics». Riferimento: «cfr. ultimi 50 anni di corporate America». È satira, ed è la sintesi più efficace del motivo per cui il progetto ha fatto rumore: quando i vertici stabiliscono che ogni mestiere si scompone in compiti misurabili contro una macchina, il loro diventa materiale legittimo per lo stesso esperimento.
La #95, aperta il 7 settembre dal fondatore stesso: un leak fra aziende diverse. I task di rigenerazione della cache girano in background dopo che la risposta è stata inviata, senza controllo d'identità e senza lock, e possono riscrivere testo dell'azienda uscente dopo la cancellazione della cache — una finestra di circa 25 secondi. Non è un problema solo di interfaccia: gli insight passano da Discord, server MCP, digest, e una nota sbagliata può arrivare in un messaggio diretto. È aperta, ed è etichettata come qualcosa che richiede una modifica di design.
Le due issue insieme dicono più di qualunque comunicato: l'idea è buona come provocazione, il software è a uno stadio in cui i dati di due aziende possono ancora sfiorarsi.
Cosa resta
Open Executive non sostituisce un amministratore delegato, e chi lo ha scritto non lo sostiene: Sente Labs ripete che «le decisioni di giudizio restano umane» e che i dipartimenti propongono azioni entro un perimetro definito dall'utente. Quello che il progetto fa davvero è più modesto e più utile — mettere in un unico posto, con memoria, i documenti aziendali e otto punti di vista funzionali su cui una persona sola non ha né tempo né competenza — ed è anche il motivo per cui vale la pena leggerlo se state costruendo sistemi multi-agente: la stratificazione della cache, il routing come tool e la memoria episodica su SQLite sono tre scelte di ingegneria copiabili domani mattina, indipendenti dalla metafora della C-suite.
Il valore di Open Executive non è che automatizza il lavoro dirigenziale. È che costringe a scriverlo per esteso — e a scoprire quanta parte era già procedura.
La cornice della vendetta, intanto, ha fatto il suo lavoro: ha portato 3.900 stelle a un repository che ne aveva poche centinaia. Ma la domanda che ha tenuto in piedi 200 commenti su Hacker News non riguardava il codice. Riguardava chi decide quali mestieri sono automatizzabili, e cosa succede quando quella logica viene applicata a chi la enuncia.
Fonti: il repository e la sua documentazione di architettura; Sente Labs; la copertura di TechRadar, Gigazine e IBTimes; l'analisi critica di Artificially Intimidating e ikangai; il thread su Hacker News.