Iris

Come funziona il mio computer personale per lavorare con gli agenti AI

Vinny · ottobre 2026

Iris è un server che affitto da Hetzner, in un data center a Norimberga, acceso 24 ore su 24. Dal 20 ottobre è il mio computer principale: progetti, codice e documenti vivono lì. Il portatile e il telefono mi servono solo per collegarmi.

Su Iris lavorano con me degli agenti AI. Sono sessioni di Claude Code, l'agente di Anthropic, che hanno accesso completo alla macchina, continuano a lavorare quando mi scollego e condividono una memoria comune su di me e sul mio lavoro.

L'obiettivo è avere un assistente sempre acceso, affidabile, di cui mi posso fidare, che mi conosce e mi aiuta a raggiungere i miei obiettivi. Il computer è costruito attorno a questo: agli agenti serve una macchina che non si spegne mai, la libertà di usarla davvero e una memoria che duri più di una conversazione.

Qui sotto spiego com'è fatto, pezzo per pezzo, e perché ho fatto certe scelte. In fondo c'è un glossario dei termini tecnici.

1. Perché un server

Un portatile si chiude, si spegne, cambia rete. Un agente che deve lavorare per ore ha bisogno di una macchina che resti accesa e collegata. Da qui sono partito.

• Il lavoro non si ferma. Chiudo il portatile in ufficio, lo riapro a casa e ritrovo le stesse finestre, con gli agenti che nel frattempo hanno continuato.
• Il portatile è sostituibile. Non contiene niente di importante che non sia anche su Iris o nel suo backup. Se lo perdo, uno script trasforma un computer nuovo nel solito accesso a Iris.
• Gli agenti hanno un ambiente tutto loro. Su un Linux completo, sempre uguale, possono installare programmi, compilare, avviare server e container senza toccare il mio portatile.
• Una sola memoria. Tutti gli agenti, in tutti i progetti, leggono e scrivono le stesse note. Una sessione di domani sa quello che una sessione ha imparato oggi, anche in un altro progetto.

2. Com'è fatto

Un solo server. Non c'è una macchina di riserva: se Iris si rompe, la ricostruisco dal backup (sezione 7). Il server è piccolo, 4 core e 8 GB, e lo tratto come un dato di fatto: il sistema deve funzionare con quello che c'è.

La rete. Iris non è raggiungibile da internet. Il firewall di Hetzner lascia passare solo Tailscale, una rete privata che collega i miei dispositivi, e il ping. Anche l'accesso SSH pubblico è chiuso. Un servizio che avvio su Iris lo apro dal portatile come http://iris:porta, e nessun altro lo vede.

La configurazione è codice. Tutto quello che definisce la macchina sta in un repository git: i file di sistema gestiti, l'elenco dei pacchetti, i servizi, gli script. Per cambiare qualcosa modifico il repository e lo applico; non tocco niente a mano. Ogni script ha una modalità check che non cambia nulla e segnala le differenze tra la macchina reale e quella descritta (il cosiddetto drift). Lo stesso vale per i servizi esterni: Hetzner, Cloudflare, Tailscale e gli allarmi sono descritti negli script, e una modifica fatta dal pannello web viene segnalata.

3. Lo spazio di lavoro

Lavoro nel terminale, dentro tmux. Ogni progetto è una cartella in ~/projects con una sessione tmux dello stesso nome. Con Ctrl+Space p apro l'elenco dei progetti e passo da uno all'altro; scrivendo un nome nuovo creo un progetto, incollando l'indirizzo di un repository lo clono.

Le sessioni appartengono al server, non alla connessione. Se il portatile va in sospensione o cade la rete, tmux e tutto quello che gira dentro continuano. Quando mi ricollego torno nella sessione che stavo usando.

Gli strumenti sono tutti da terminale: helix come editor, lazygit per git, yazi per i file, btop per i processi. In fondo allo schermo c'è una barra di stato che mostra CPU, memoria e disco, lo stato degli agenti, quanto ho usato del mio piano Claude e l'esito dell'ultimo controllo di salute.

Il software si aggiorna da solo ogni notte. I pacchetti di sistema vengono da Debian o dalle fonti ufficiali dei singoli progetti. I linguaggi e gli strumenti di sviluppo (Node.js, Rust, Python con uv, i language server) li gestisce mise, che installa le versioni più recenti, ma solo quando sono uscite da almeno tre giorni, per evitare le release difettose.

4. Gli agenti

Il motore

Uso Claude Code con l'abbonamento Max. Ogni sessione parte su Opus 5.5 con sforzo di ragionamento alto; per un lavoro pesante lo alzo a mano. Non ho scritto un mio framework per agenti che chiama le API: pagherei ogni token, mentre l'abbonamento copre tutto, e ogni miglioramento che Anthropic fa a Claude Code arriva su Iris da solo. Costruisco sopra il programma claude: la modalità interattiva, claude -p per gli script, le sessioni in background e gli hook.

Cosa c'è in una sessione

Quando parte una sessione, prima del mio primo messaggio il modello ha già nel contesto:

1. le istruzioni di Claude Code stesso, con la descrizione degli strumenti;
2. un file di istruzioni di sistema di Iris (CLAUDE.md), uguale per tutte le sessioni: cos'è la macchina, cosa può fare, come installare software, dove tenere i dati, come usare la memoria;
3. il mio profilo (me.md), inserito da un hook;
4. l'indice della memoria (MEMORY.md), una riga per ogni argomento su cui esiste un file.

Poi lavora a ciclo: legge la richiesta, sceglie uno strumento (eseguire un comando, leggere o modificare un file, cercare, aprire una pagina web, avviare un sotto-agente), guarda il risultato e decide il passo successivo, finché ha finito o ha bisogno di me.

La finestra di contesto è di un milione di token, ma la conversazione viene compattata (riassunta) già a 300.000, per non lavorare con un contesto troppo pieno. Una volta una sessione è durata 21 ore ed è stata riassunta 8 volte, e nell'ultima giornata ha fatto molte scelte sbagliate. Non posso dimostrare che la causa fosse la lunghezza, ma da allora apro una sessione nuova per ogni fase di lavoro, e le decisioni le scrivo nei file del progetto e nella memoria, così la sessione nuova riparte da lì.

Permessi: tutti

Gli agenti girano con il mio utente, con sudo senza password, accesso a Docker e nessuna richiesta di conferma. Un agente che chiede «posso?» prima di ogni comando non lavora mentre non ci sono, ed è proprio quello che mi serve.

C'è una sola eccezione. Un hook rifiuta qualsiasi comando che cancellerebbe la radice del disco, la mia home, una cartella di primo livello o la cartella di lavoro, e spiega all'agente cosa fare invece. La protezione vera non sta nei permessi ma nei backup, che nessuno su Iris può cancellare (sezione 7).

Strumenti

• La macchina intera. Installa quello che gli serve, avvia server e container, compila.
• Language server. Dopo ogni modifica l'agente riceve gli errori che ha appena introdotto (un tipo sbagliato, un import mancante) e cerca i simboli nel codice come farebbe un IDE, invece di cercare testo.
• Un browser senza schermo. Chromium headless, con cui controlla le pagine web che costruisce: le apre, ci clicca, fa gli screenshot.
• Il mio Chrome. Con un'estensione di Anthropic l'agente può usare il browser del mio portatile, con i miei account, quando il portatile è acceso. Questa pagina l'ha messa online così: ha aperto il pannello di Cloudflare nel mio Chrome e ci ha caricato il file.
• I miei servizi. Gmail, Calendar e Drive tramite i connettori del mio account Claude.
• Documenti. LibreOffice senza interfaccia, pandoc, strumenti per PDF e OCR: può leggere e produrre Word, Excel, PowerPoint e PDF.

In primo piano e in background

Con un agente posso parlare in una finestra del terminale, oppure posso descrivergli un compito e lasciarlo lavorare in background. Le sessioni in background le gestisce un supervisore di Claude Code: continuano anche se chiudo tutto e si riprendono dopo un riavvio, appena rispondo. Prima di modificare un file, ogni sessione in background si sposta su una propria copia del repository (un worktree git), così più agenti possono lavorare sullo stesso progetto senza pestarsi i piedi.

Sapere cosa stanno facendo

Degli hook registrano lo stato di ogni sessione e la barra di tmux lo mostra accanto al nome della finestra: al lavoro, in attesa di una mia risposta, finito, oppure fermo per un errore (un limite di utilizzo, un sovraccarico dei server di Anthropic, dopo cui riprende da solo). A destra c'è il conteggio delle sessioni per stato e l'uso del piano nelle ultime 5 ore e nei 7 giorni. Quando un agente finisce o mi fa una domanda, il portatile mostra una notifica con il nome del progetto.

I limiti della macchina

4 core e 8 GB sono pochi. Una volta una revisione ha lanciato 21 sotto-agenti Opus in parallelo: il carico è arrivato a 17 e la RAM era quasi finita. Ora ne lancio una decina alla volta. Se la memoria finisce comunque, systemd-oomd chiude la singola finestra che ne usa di più, prima che la macchina si blocchi.

Agenti per altre persone

Su Iris costruisco anche agenti per altre persone, con lo stesso motore. Il primo mi ha insegnato una cosa: avviato sulla stessa macchina, ereditava le mie impostazioni globali, compresi il mio profilo e l'indice della mia memoria nel prompt. Ora questi agenti partono in modalità isolata, dentro una sandbox che nasconde la configurazione di Iris e passa solo le variabili d'ambiente necessarie.

5. La memoria

Un modello non ricorda niente da una conversazione all'altra: ogni sessione parte da zero. Per un assistente personale è il problema principale.

Il vault

La memoria è una cartella, ~/vault: file Markdown in un repository git. Claude Code ha una funzione di memoria automatica che salva appunti in una cartella; l'ho puntata sul vault, così tutte le sessioni di tutti i progetti usano la stessa memoria invece di averne una per progetto.

• me.md: il mio profilo, cioè quello che ogni sessione deve sapere. Lo inserisce un hook all'avvio, e di nuovo dopo un /clear o una compattazione. Resta sotto gli 8.000 caratteri.
• MEMORY.md: l'indice, una riga per argomento, sempre caricato. Dice all'agente cosa può andare a leggere.
• Un file per argomento: una persona, un cliente, un progetto, un periodo. Non un file per ogni fatto, così l'indice resta corto.
• journal/: una pagina di diario per ogni giorno, scritta di notte.

Le regole

Le regole stanno nel file di istruzioni di sistema, quindi valgono per ogni sessione:

• salvare senza aspettare che glielo chieda: quello che dico di me, decisioni, preferenze, quello che succede;
• solo quello che ho detto o che è successo davvero, mai supposizioni su di me;
• mai segreti (password, chiavi);
• quando un fatto cambia, aggiornare il file e tenere il valore vecchio con la data («Prima: … (fino a ottobre 2026)»);
• scrivere in inglese, ma citare le mie parole nella lingua in cui le ho dette;
• fare un commit git per ogni modifica, solo dei propri file: la storia di git dice quando è stata imparata ogni cosa, e posso annullare qualsiasi modifica.

Un esempio

Un file di argomento, inventato e semplificato, ma con la stessa forma di quelli veri:

---
name: progetto-esempio
description: The example project: what it is, decisions, status
metadata:
  type: project
---

# Example project

## Decided
- Stack: Kotlin and Compose (Vinny, 2026-10-23: "voglio
  qualcosa di semplice").
- Read-only in the first version, no actions.

## Status
- First screen built and tested on 2026-10-24.
- Previously: postponed (until 2026-10-23).

Come cerca

Non ci sono embedding, database vettoriali o RAG. L'agente cerca nel vault come cerca nel codice: con rg (una ricerca testuale veloce) e leggendo i file. Il punto debole è il lessico: se il file dice «Fiat Panda» e io chiedo della «macchina», una ricerca testuale non lo trova da sola. In pratica il modello prova parole diverse, anche in italiano, e parte dall'indice.

L'ho misurato: 12 domande in sessioni nuove, formulate apposta con parole diverse da quelle dei file e in parte in italiano. 12 risposte giuste, e per le due domande a cui il vault non poteva rispondere l'agente ha detto «non lo so» invece di inventare. Un indice semantico lo aggiungerò solo se l'uso reale mostrerà che serve.

La passata notturna

Ogni notte alle 3 un agente legge le conversazioni del giorno, scrive la pagina di diario, salva quello che le sessioni si sono dimenticate di salvare, riordina il vault e fa il commit. Il controllo di salute del mattino verifica anche il vault: che ogni riga dell'indice punti a un file esistente e viceversa, che profilo e indice restino nei limiti, che non ci sia niente senza commit.

Perché così semplice

Un vantaggio in più: il vault posso leggerlo e correggerlo io, con un editor qualsiasi. Non finisce mai su GitHub: sta solo su Iris e nel backup cifrato.

6. Cosa succede di notte

Il riavvio non è mai automatico: se un aggiornamento del kernel lo richiede, la barra di stato me lo dice e decido io quando farlo.

7. Sicurezza e ripristino

Dare pieni poteri agli agenti ha senso solo se un disastro si può sempre annullare.

• Backup non cancellabili. I backup sono notturni e non orari, perché lo spazio su R2 costa. Sono fatti con restic, cifrati, nel bucket R2 di Cloudflare. Il bucket ha regole di blocco: una volta scritto, un backup non si può cancellare né sovrascrivere con le credenziali che ha Iris, né da me né da un agente. Per togliere il blocco serve il pannello di Cloudflare o la chiave di amministrazione. Il prezzo è che non si elimina mai niente e il backup cresce sempre. Per ora deve stare nei 10 GB gratuiti di R2: il controllo del mattino mi avvisa sopra gli 8 GB.
• Ricostruzione in due comandi. Se il server si rompe o viene compromesso, un comando lo cancella e lo reinstalla, un secondo lo ripristina dal backup: stessi indirizzi, stessa identità sulla rete, la mia home e i pacchetti che avevo installato. L'ho provato due volte, l'ultima prima di aggiungere spazio di lavoro, agenti e memoria; una nuova prova è in programma.
• Le chiavi di amministrazione non stanno su Iris. Le credenziali per gestire Hetzner, Cloudflare e Tailscale non sono salvate su Iris, così Iris da sola non ha le chiavi per cancellare il server o i suoi backup.
• Un solo segreto. Per un ripristino completo serve solo la password del backup, che sta nel mio password manager.
• Niente esposto. Nessuna porta aperta verso internet; se un giorno qualcosa su Iris dovrà essere pubblico, passerà da un tunnel di Cloudflare, non da una porta aperta. Questa pagina invece non sta su Iris: è un file statico servito da Cloudflare.

8. Come mi collego

Il portatile

Un ThinkPad con Fedora in installazione minima, il window manager niri, Chrome e il terminale foot: nient'altro. Ci sono passato da pochi giorni, quindi alcune delle comodità qui sotto, nate sul portatile di prima, le sto ancora provando sul nuovo. Super+Invio apre una finestra su Iris, nella sessione dove ero rimasto. Se la connessione cade (sospensione, cambio di rete, riavvio di Iris) la finestra lo nota entro 15 secondi, dice perché e si ricollega da sola. Altre comodità:

• Super+I manda l'immagine negli appunti del portatile (per esempio uno screenshot) all'agente nella finestra davanti a me;
• quello che copio su Iris finisce negli appunti del portatile;
• le notifiche degli agenti arrivano come notifiche del desktop.

Il telefono

Un'app Android nativa, in costruzione: Kotlin, Jetpack Compose e Material 3, con un piccolo servizio in Go su Iris che espone lo stato della macchina, visibile solo nella rete privata. Non sarà un terminale e non servirà a parlare con gli agenti: mostrerà cosa sta girando, cosa aspetta una mia risposta e il diario, e mi manderà una notifica quando un agente ha bisogno di me mentre sono lontano dalla tastiera. Per ora esiste la base: gli agenti la costruiscono e la provano su Iris stesso, facendo girare Android in un container e scattando screenshot dell'app.

9. Come l'ho costruito

Ho costruito Iris dal 16 al 20 ottobre 2026, quasi tutto parlando con Claude Code, in cinque fasi in ordine, ognuna verificata prima di passare alla successiva:

1. Server: la macchina, la rete privata, i backup, il ripristino, gli allarmi.
2. Spazio di lavoro: tmux, la shell, l'editor, gli strumenti.
3. Agenti: Claude Code configurato per ogni sessione, i permessi, gli hook, la barra di stato.
4. Memoria: il vault, le sue regole, la passata notturna.
5. Client: la finestra sul portatile, poi l'app per il telefono.

Il repository ha quattro parti oltre al codice: un README che spiega come funziona tutto, un file DECISIONS.md con ogni decisione e il suo motivo (così nessuno la rimette in discussione per sbaglio, né io né un agente), un file LATER.md con il lavoro rimandato, e la cartella history/ con le conversazioni che hanno costruito Iris, con le credenziali oscurate.

Principi

• Semplice prima di complesso. Un sistema più complicato non è un sistema migliore; la memoria ne è la prova.
• Versioni recenti, fatte bene. Ogni strumento all'ultima versione, aggiornato ogni notte e controllato.
• Cresce con l'uso. Ora che lo uso ogni giorno, aggiungo una funzione quando mi manca davvero.

Cosa ho imparato

• Chiedere «è perfetto al 100%?» trovava ogni volta qualcosa di nuovo. Ora pretendo che l'agente dica cosa ha verificato, cosa non ha provato e cosa è fuori dal suo controllo, invece di una rassicurazione.
• Bisogna provare le cose come le uso io, non solo verificare che un'impostazione sia stata applicata.
• Un ostacolo è un motivo per scavare, non una «limitazione accettata» che non ho mai accettato.

10. Cosa manca

• Agenti che partono da soli. Un timer, un'email o un evento su GitHub che avviano una sessione e mi lasciano il risultato. Con un'attenzione: la passata notturna leggerebbe quelle sessioni come se fossero mie, e prenderebbe il loro prompt per parole mie. Vanno tenute separate.
• L'app per il telefono, da finire.
• Una nuova prova di ricostruzione, per verificare che anche agenti e memoria tornino com'erano.
• Leggere la memoria dai client, cioè dal telefono e dal portatile.

11. Glossario

Agente

Un modello linguistico che lavora a ciclo con degli strumenti: decide un'azione, la esegue, guarda il risultato, decide la successiva.

Claude Code

L'agente di Anthropic per il terminale. Legge e scrive file, esegue comandi, usa il web e altri strumenti.

Opus 5.5

Il modello di Anthropic che uso per tutte le sessioni.

Contesto

Tutto quello che il modello «vede» in un dato momento: istruzioni, conversazione, risultati degli strumenti. Si misura in token.

Compattazione

Quando il contesto si riempie, la conversazione viene riassunta e la sessione continua dal riassunto.

Hook

Un programma che Claude Code esegue in momenti precisi (all'avvio di una sessione, prima di un comando, alla fine di una risposta). Su Iris gli hook inseriscono il profilo, bloccano le cancellazioni pericolose e registrano lo stato degli agenti.

Sotto-agente

Un agente avviato da un altro agente per un compito circoscritto, con un contesto suo; restituisce solo il risultato.

Server

Un computer in un data center, acceso sempre, a cui ci si collega in rete.

SSH

Il protocollo con cui ci si collega a un server e ci si lavora dal terminale.

tmux

Un programma che tiene aperte le sessioni del terminale sul server, con finestre e riquadri, anche quando ci si scollega.

Tailscale

Una rete privata cifrata tra i propri dispositivi, ovunque si trovino.

Git, repository, commit

Git registra la storia delle modifiche ai file. Un repository è una cartella seguita da git; un commit è una modifica salvata nella storia, con data e descrizione.

Worktree

Una seconda copia di lavoro dello stesso repository git, in un'altra cartella, per lavorare in parallelo senza conflitti.

Language server

Un programma che capisce un linguaggio di programmazione e segnala errori, definizioni e riferimenti; è ciò che fa funzionare un IDE.

Container, Docker

Un ambiente isolato in cui far girare un programma con tutto quello che gli serve, senza toccare il resto del sistema.

Drift

La differenza tra come una macchina dovrebbe essere, secondo la sua descrizione, e come è davvero.

restic, R2

restic è il programma di backup, che cifra e deduplica i dati. R2 è lo spazio di archiviazione di Cloudflare dove i backup vengono salvati.

Markdown

Testo semplice con poche convenzioni per titoli, elenchi e grassetto; leggibile anche senza programmi speciali.

Embedding, RAG

Tecniche per cercare testo per significato invece che per parole, trasformandolo in vettori. Iris non le usa.