Olivares AI v26.8.0 è la prima versione pubblica e dotata di tag di un binario Go self-hosted che offre agli agenti IA già in uso — Claude Code, Codex, Grok Build e tutti gli altri — lavoro persistente, accessi circoscritti e prove firmate, sul proprio hardware. Sono io l’autore. Questo articolo è un inventario di ciò che esiste davvero nel tag, con le lacune indicate accanto alle funzionalità, perché per un prodotto di questa categoria le lacune fanno parte della specifica.
1. Il problema, senza aggettivi
Gli agenti operano su macchine e fornitori diversi. Nessun sistema persistente sa chi detiene un’attività, quali risorse può raggiungere ciascun agente, quali ha raggiunto davvero o chi ha passato il lavoro a chi. Le autorizzazioni risiedono in più sistemi IAM; il comportamento è nei log di audit che nessuno legge. Ogni team che usa seriamente gli agenti ha ricostruito a mano una parte della soluzione — un foglio di calcolo qui, una convenzione di denominazione là, una persona che ricorda. È questa parte che il prodotto sostituisce.
2. Il nucleo: un piano di lavoro condiviso dagli agenti
Gli elementi di lavoro persistenti contengono un incarico, dipendenze, criteri di accettazione, decisioni, un responsabile e una cronologia degli eventi — un unico documento di comando condiviso da REST, dalla CLI e dai chiamanti nello stesso processo. Le lease rendono la titolarità un’autorità isolata e a scadenza: acquisire, rinnovare, rilasciare, subentrare, revocare. Un titolare obsoleto non può continuare ad agire e un’acquisizione concorrente ha esattamente un vincitore. L’avvio per un’attività prenota, acquisisce la lease e solo dopo avvia la sessione, così un nuovo tentativo è sicuro. I messaggi tra agenti includono conferme e passaggi di consegne, con replay e rifiuto delle epoche obsolete. La delega tramite A2A raggiunge un peer autorizzato attraverso un gate di enforcement e restituisce ricevute persistenti.
Tutto questo è operativo. Ed ecco il confine, espresso con la stessa chiarezza delle funzionalità: la messaggistica è circoscritta a un workflow di orchestrazione — deliberatamente non esiste un bus di messaggi generico per agenti arbitrari, e un test di avvio fallisce se qualcuno ne collega uno per errore. La modalità shadow e l’autorità finale non sono implementate. Il README riporta entrambi i lati nella stessa tabella.
3. Integrazioni, con la profondità dichiarata
Claude Code è integrato a livello dell’hook PreToolUse/PostToolUse, con
impostazioni gestite, avvio, collegamento e arresto dalla console e accesso ai
modelli per soggetto. Codex e Grok Build sono superfici di comando di prima
classe al suo fianco. gemini-cli, Cursor, opencode, goose, cline, OpenHands,
OpenClaw e Hermes vengono distribuiti come connettori — e ciascuno dichiara cosa
può imporre e cosa può soltanto osservare, perché sono promesse diverse. Ollama
e gli altri endpoint self-hosted vengono inventariati tramite un connettore
locale che, per scelta progettuale, è di sola lettura.
4. Governance nel punto in cui agisce l’agente
Un motore di autorizzazione Cedar — RBAC, uno strato di regole di diniego,
concessioni positive circoscritte — e quattro punti di enforcement
deny-closed: l’hook di Claude Code, un proxy di inferenza inline
/v1/messages, un gate MCP per tools/call e un gate di delega A2A. Un’azione
non consentita viene bloccata, inviata all’approvazione di due persone oppure
riscritta prima dell’esecuzione. «Deny-closed» viene misurato, non dichiarato: un
punto conta solo finché un test percorre il suo flusso non configurato e
verifica il rifiuto. Se un punto non è stato predisposto, la capacità viene
indicata come osservazione, non come enforcement — e ogni connettore specifica
quale delle due offre. Completano il quadro le approvazioni a due persone, il
break-glass e un kill switch per l’intero ambiente, attivabile con un clic;
per riattivare l’ambiente servono due persone distinte.
5. Prove che si possono consegnare
Un registro di audit append-only, concatenato tramite hash, con checkpoint firmati Ed25519. Esportazioni in CEF, LEEF, syslog, OTLP e OCSF; invio at-least-once a Splunk HEC, Microsoft Sentinel, Datadog, New Relic o a un webhook HMAC. Prove di conformità mappate su 26 cataloghi di framework — mappature tecniche dei controlli e pacchetti di prove da sottoporre al proprio consulente legale o auditor, non certificazioni. Lo dichiara anche il catalogo del prodotto.
6. I numeri e lo script che li produce
30 moduli. 158 integrazioni. 26 cataloghi di framework. Quattro punti di
enforcement deny-closed. 68 comandi CLI raggruppati. Nessuno di questi numeri
è aritmetica di marketing: scripts/check-public-counts.sh ricava i primi
quattro dall’albero e fa fallire la build quando il README diverge dal codice;
il totale della CLI è protetto da un test che impedisce l’inserimento di un
comando non raggruppato. Il conteggio delle integrazioni è trasparente sulla
propria unità — directory di connettori contenenti codice Go, dodici delle quali
sono pacchetti di contratti condivisi anziché funzionalità — e il dettaglio è
nel repository. L’ambiente dimostrativo restituisce 20 nodi, 13 archi, 8 accessi
imprevisti e 2 concessioni inutilizzate: numeri sintetici, verificati da uno
smoke test eseguito sul binario reale, presentati come output della demo e mai
come dimensioni di un cliente.
7. Una sola build per ogni scala
Lo stesso binario serve un server domestico (SQLite, in ascolto su loopback, un Compose di riferimento eseguito senza root e in sola lettura con 1 CPU e 1 GiB), un freelance con un tenant per cliente e budget che negano prima che arrivi la fattura, un team di ingegneria con elementi di lavoro condivisi e SSO e un’impresa regolamentata con sicurezza a livello di riga in Postgres, installazioni air-gapped e archiviazione WORM. Diverse di queste funzionalità vanno predisposte e non sono impostazioni predefinite disponibili al primo avvio — la documentazione specifica quali, una per una.
8. Licenza e costi, senza ambiguità
AGPL-3.0 per il nucleo, i moduli e la console web; Apache-2.0 per l’SDK, i connettori e gli SDK client; un piccolo insieme di add-on commerciali aggiuntivi, compilati solo con un tag di build separato e assenti dal binario pubblico. La build aperta è l’intera piattaforma — non è mai limitata nelle funzionalità e consente account utente illimitati. Una licenza commerciale è un’eccezione legale all’AGPL; un abbonamento è la credenziale con cui si scaricano gli artefatti firmati, non una chiave che attiva byte già presenti sul disco. Condizioni commerciali su richiesta: enterprise@olivares.ai. Hosted Cloud non è in vendita oggi; il prodotto è self-hosted.
9. Supply chain
Le release sono firmate con cosign e includono provenienza SLSA, una SBOM e
OpenVEX, il tutto verificabile offline con scripts/verify-release.sh.
Artefatti: binari linux e darwin (amd64/arm64), pacchetti
.deb/.rpm/.apk con un’unità systemd rafforzata, un’immagine container
multiarch e un bundle air-gap. Non viene prodotta una build per Windows — si può
usare il container Linux oppure compilare dal sorgente.
10. Cosa ci siamo rifiutati di affermare
Nessun utente e nessun benchmark — non ne esistono di pubblici, e inventare gli
uni o gli altri sarebbe la cosa peggiore che un prodotto di governance potrebbe
fare. Nessuno SLA, nessun SOC 2, nessuna certificazione. Nessuna promessa che
«nulla lasci mai la rete»: i modelli frontier chiusi non possono essere
self-hosted, quindi l’inferenza che li usa raggiunge comunque l’API del
fornitore. Il piano che li circonda può invece essere self-hosted e isolato
dalla rete, mentre i modelli eseguiti davvero in proprio (vLLM, Ollama)
mantengono internamente l’intero percorso. Non esiste telemetria obbligatoria e,
per impostazione predefinita, non c’è egress dal piano di controllo; l’unica
chiamata al fornitore è olivares upgrade, che chiede dove si trovi la nuova
versione, e --endpoint la reindirizza. Nessun kill switch remoto. Nessun limite
di postazioni nel motore self-hosted.
Provalo
# Demo estate — synthetic data through the real engine, loopback-only:
task build && ./bin/olivares serve --seed-demo --insecure \
--listen 127.0.0.1:8901 --grpc-listen 127.0.0.1:8902 --data-dir "$(mktemp -d)"
# Real install — secure by default (TLS on, loopback, one-time setup token):
./bin/olivares quickstart
# Or the container image (registry tags carry no v prefix):
docker pull ghcr.io/olivaresai/olivares:26.8.0Prima del deployment, leggere start/honesty-and-limits: è il contratto che
stabilisce cosa funziona oggi, cosa è ancora in fase di progettazione e cosa il
prodotto sceglie deliberatamente di non fare.
Release: https://github.com/olivaresai/olivares/releases/tag/v26.8.0 · Repository: https://github.com/olivaresai/olivares · Documentazione: https://docs.olivares.ai