Un agente che migliora da solo: dentro l’autoevoluzione di Orkas

La maggior parte degli assistenti IA funziona secondo il principio "lo usi e dimentica tutto". Correggi un’abitudine oggi e domani ripete lo stesso errore; la settimana scorsa gli hai insegnato il flusso di lavoro specifico del tuo team e questa settimana si comporta come se non ne avesse mai sentito parlare. Ogni conversazione riparte da zero e, per quanto intelligente sia il modello, resta una persona intelligente con l’amnesia.

Orkas punta a qualcosa di diverso: permettere all’agente di imparare dal proprio uso quotidiano, distillando l’esperienza ricorrente per poterla applicare autonomamente la volta successiva. In parole semplici, diventa più utile quanto più lo usi, e questa "utilità" cresce adattandosi a te, alle tue preferenze e al tuo ambito, anziché a qualcosa che il fornitore del modello ha preimpostato per tutti.

Questo articolo spiega come è costruito quel meccanismo. Non è semplice come "far ricordare la conversazione al modello": dietro c’è un ciclo completo: osservarsi → decidere se riflettere → riflettere davvero → scrivere le conclusioni in una forma riutilizzabile → usarle di nuovo la volta successiva. Lo esamineremo un pezzo alla volta.

Prima di tutto, la cosa più importante: tutto ciò che segue, tutte le operazioni di "osservazione", "registrazione" e "riflessione", avviene interamente sul tuo dispositivo. I dati delle esecuzioni, le abilità, la comprensione che l’agente ha di sé: tutto risiede localmente sotto forma di normali file. Nulla viene caricato sui server di Orkas e nulla viene usato per analisi trasversali tra utenti o per addestrare modelli. "Autoevoluzione" significa che un programma legge localmente i propri registri di esecuzione e migliora localmente, non che raccoglie i tuoi dati. Questa esperienza non lascia mai il computer e serve solo a te, su questo singolo computer.

Il ciclo, dall’inizio alla fine

uso reale, ripetuto nel tempo
      │  registrazione locale: strumenti chiamati, presenza di errori o correzioni
      ▼
   i segnali si accumulano
      │  segnali estratti dalla conversazione dove si trova, tutti conservati sul dispositivo
      ▼
  decidere se avviare la riflessione
      │  punteggio ponderato dei segnali; si attiva solo oltre una soglia; i problemi di rete non contano
      ▼
   riflettere in background
      │  non a ogni turno: periodicamente, selezionando gli agenti che soddisfano i criteri
      ▼
  si condensa in due elementi
      │  ① "abilità" riutilizzabili   ② una "comprensione" di sé
      ▼
  viene incluso automaticamente nel turno successivo
      └──────────► tornare all’inizio e proseguire

Ogni passaggio di questo ciclo ha le sue sottigliezze. I punti in cui è più facile sbagliare sono proprio i due passaggi che a prima vista sembrano più semplici: quando riflettere e che cosa registrare una volta fatto. Partiamo dall’inizio.

Passaggio 1: osservarsi a costo quasi zero

Per imparare dall’esperienza, prima serve un’"esperienza" da esaminare. Al termine di ogni esecuzione dell’agente, il programma conteggia, localmente e sul momento, alcuni semplici dati sull’esecuzione: all’incirca quanti strumenti sono stati chiamati in questo turno, se si sono verificati errori, se erano transitori (come un problema di rete) o effettivi e se l’utente ha apportato correzioni sul momento. Solo una manciata di conteggi e indicatori, tutti calcolati sul computer, senza chiamare alcun modello né inviare nulla altrove.

Questo conta perché non comporta alcuna spesa per il modello. I conteggi vengono ricavati direttamente dal registro della conversazione del turno corrente; non serve effettuare una chiamata aggiuntiva al modello solo per "analizzarsi". Se ogni turno richiedesse un’altra chiamata al modello per l’introspezione, costo e latenza sarebbero insostenibili e l’intero meccanismo non arriverebbe mai agli utenti.

L’indicatore "corretto o no" è piuttosto interessante. È un giudizio locale puramente euristico, stimato confrontando alcune formulazioni nel messaggio sul tuo dispositivo: espressioni cinesi come "不对" / "应该是" / "重新", inglesi come wrong, actually, instead. Non punta a essere preciso: è solo un segnale, non un verdetto, e un falso positivo occasionale va bene, perché in seguito viene ponderato insieme ad altri segnali; nulla viene deciso solo sulla sua base.

Passaggio 2: quando vale davvero la pena riflettere

È la parte dell’intero meccanismo che, a mio avviso, mostra più cura progettuale.

L’approccio ingenuo è "riflettere dopo aver accumulato N occorrenze". Ma è grossolano: tre timeout di rete consecutivi e tre correzioni consecutive dell’utente non sono ovviamente la stessa cosa e non dovrebbero essere trattati allo stesso modo. Orkas usa un punteggio ponderato basato su più segnali: ogni fenomeno degno di nota è un segnale con un peso; si sommano i pesi dei segnali attivati in quel turno e si riflette solo se il totale supera una soglia (0.7 per impostazione predefinita).

I segnali principali sono più o meno questi:

Per esempio: un turno con una correzione dell’utente (0.9) e un certo grado di complessità (0.5) totalizza 1.4, ben oltre 0.7, quindi attiva la riflessione; un turno solo un po’ complesso (0.5) resta sotto soglia e viene lasciato passare. La ponderazione riflette anche una scelta di giudizio: una correzione diretta dell’utente riceve il peso più alto, 0.9, perché è il riscontro con il miglior rapporto segnale/rumore disponibile: l’utente ha detto chiaramente che stai sbagliando, quindi è molto probabile che valga la pena registrarlo.

Quell’unica eccezione cruciale

In tutta la logica di assegnazione dei punteggi c’è una regola che considero decisiva per stabilire se questo meccanismo "impara le cose giuste": gli errori transitori non contano mai.

Timeout di rete, connessioni interrotte, limiti di frequenza: sono problemi dell’ambiente, non carenze nelle capacità dell’agente. Se non li escludi, succede qualcosa di spiacevole: uno strumento produce un errore per un occasionale problema di rete e il meccanismo di riflessione lo registra come "questo strumento è inaffidabile, usalo meno", o addirittura altera in modo dannoso o elimina un’abilità perfettamente valida. Da quel momento l’agente ha imparato una lezione sbagliata, e quell’errore continua ad accompagnarlo.

Perciò i segnali "recupero da un errore", "abilità inefficace" e "debolezza nota incontrata" escludono tutti esplicitamente gli errori puramente transitori. Anche il prompt di riflessione ribadisce l’avvertenza: gli errori di rete dipendono dall’ambiente, non registrarli come debolezze, non toccare le abilità correlate. Ciò che un sistema capace di migliorarsi dovrebbe temere di più non è imparare lentamente, ma imparare nella direzione sbagliata. Questa eccezione protegge proprio da questo.

Passaggio 3: la riflessione avviene in background, senza intralciarti

Una trappola comune: nel momento in cui rilevi che "è ora di riflettere", fermarti e riflettere subito. Così l’agente sembra procedere a singhiozzo, allontanandosi ogni tanto per "meditare sulla vita": una brutta esperienza.

Orkas sposta la riflessione in background, con una cadenza fissa. Le regole di pianificazione, a grandi linee:

• Avviare un ciclo di riflessione a intervalli regolari (diciamo, nell’ordine di una dozzina di ore o più).
• Imporre un intervallo minimo tra due riflessioni dello stesso agente (alcune ore), per evitare che avvengano troppo spesso.
• Ma se non riflette da troppo tempo (diciamo, da oltre una settimana), forzare una riflessione, per evitare di rimandarla all’infinito.
• Limitare il numero di agenti selezionati per ciclo, per non disperdere troppo le risorse contemporaneamente.

C’è un piccolo accorgimento progettuale a cui tengo, chiamato controllo delle modifiche: quando parte un ciclo, verificare anzitutto se questo agente ha qualcosa di nuovo dall’ultima riflessione, per esempio nuovi segnali o registri di conversazione aggiornati. Se non c’è stato alcun cambiamento, saltarlo questa volta e non sprecare una riflessione che comporta un costo per il modello. È semplice, ma nella pratica fa risparmiare molto.

Passaggio 4: come funziona davvero la riflessione

Quando è davvero il momento di riflettere, il flusso è questo: prima organizzare l’attività recente in un "pacchetto", poi abbinarlo a un prompt scritto con cura e passarlo al modello perché lo legga e lo riassuma.

Il pacchetto ha un budget: prendere al massimo una manciata di conversazioni recenti, aggiungere alcune categorie di eventi di sistema, intercalarli in ordine cronologico e mantenere il totale sotto un limite di token (diciamo, nell’ordine di diecimila o più). Non si riversa dentro l’intera cronologia: non ci starebbe e il rapporto segnale/rumore sarebbe basso.

La parte che richiede davvero cura è il prompt. Impone al modello di produrre non "descrizioni", ma istruzioni imperative eseguibili. La differenza sembra piccola, ma conta enormemente. Confronta:

✗ "Le risposte dell’agente sono talvolta troppo prolisse; fai attenzione."

✓ "Quando rispondi a domande sui family office, non superare mai 5 punti elenco."

✗ "L’utente sembra preferire risposte concise."

✓ "Quando rispondi in un contesto di family office, presenta sempre prima la conclusione, poi il ragionamento."

Il prompt indirizza esplicitamente il modello verso strutture "mai / sempre / quando-allora" con condizioni di attivazione concrete. Il motivo è pratico: una nota che dice "ricordati di essere conciso" non dà all’agente nulla di concretamente applicabile la prossima volta che la legge, mentre "non superare mai 5 punti elenco" può essere seguito direttamente. Perché l’automiglioramento sia utile, ciò che viene distillato deve essere un’istruzione efficace, non una banalità corretta.

Dopo aver riflettuto, il modello può fare alcune cose: creare o modificare un’abilità, aggiornare la comprensione che ha di sé oppure, se in questo intervallo non c’è davvero nulla che valga la pena registrare, limitarsi a dire "nulla da salvare". Permettergli di non fare nulla è di per sé una scelta progettuale importante: non imporre un risultato di apprendimento, per non accumulare una montagna di rumore inutile.

Distillare in due forme

Il risultato della riflessione confluisce in due destinazioni.

Una sono le abilità. Ogni abilità è un documento Markdown con metadati: un blocco frontmatter che registra nome, descrizione, data e ora di creazione e aggiornamento, quante volte è stato modificato e quando è stato usato l’ultima volta, seguito dai passaggi o dai punti chiave effettivi:

---
name: "Weekly Report Export"
description: "Compile this week's data into the standard weekly-report format"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---

## Steps
1. ...
2. ...

Conservare le abilità come file è una scelta pragmatica: una persona può leggerle e modificarle direttamente, senza che siano rinchiuse in un database opaco.

L’altra è la comprensione di sé. Questa parte somiglia più a un promemoria che l’agente scrive a se stesso, diviso in due parti: una annota "in che cosa sono bravo e dove tendo a inciampare", l’altra "le strategie che ho elaborato per questo utente e questo ambito". Entrambe hanno un limite di lunghezza che le obbliga a restare concise: non conta scrivere di più, ma essere più fedeli alla realtà. All’inizio della conversazione successiva, questo contenuto viene inserito nel prompt di sistema, così l’agente si presenta con "una comprensione di sé".

Le abilità non vengono soltanto scritte

Se ti limiti a creare abilità, con il tempo accumuli un deposito di rottami. Perciò le abilità hanno un ciclo di vita completo.

Oltre alla creazione, l’operazione più comune è in realtà la modifica mirata: cambiare una piccola porzione di un’abilità esistente anziché smantellarla e riscriverla. Ogni modifica incrementa un contatore e aggiorna la data e l’ora dell’ultima modifica. Questo permette a un’abilità di crescere gradualmente con l’esperienza, invece di essere riscritta per intero a ogni turno.

C’è anche un limite al numero. Il totale delle abilità ha un tetto massimo (diciamo, 200); una volta raggiunto, aggiungerne una nuova comporta la rimozione di una vecchia secondo il criterio LRU (usata meno di recente), per fare spazio. La rimozione segue una preferenza: eliminare prima quelle mai usate dalla creazione. Un’abilità che non è mai stata letta probabilmente non è stata distillata correttamente fin dall’inizio, ed è meglio che lasci il posto.

Ogni volta che l’agente legge un’abilità, la sua "data e ora dell’ultimo utilizzo" viene aggiornata. Questa marca temporale alimenta sia la decisione di rimozione LRU sia la capacità del meccanismo locale di distinguere quali abilità siano davvero usate e quali occupino soltanto spazio.

Come capire se un’abilità è davvero utile

È il passaggio che molti sistemi di "autoapprendimento" saltano per pigrizia: ha imparato qualcosa, ma serve a qualcosa? Orkas traduce questa domanda in alcune metriche, localmente. Queste metriche vengono calcolate per l’uso interno del meccanismo di evoluzione sul computer, per decidere quale abilità rivedere o eliminare, e anch’esse non lasciano mai il computer.

Il meccanismo: all’inizio di ogni turno, le abilità disponibili compaiono nell’indice del prompt di sistema: questa è una "visualizzazione"; se l’agente legge effettivamente un’abilità in quel turno, questa è un’"invocazione". Confrontando le due si ottiene la prima metrica:

• Tasso di invocazione = invocazioni / visualizzazioni. Un’abilità che resta lì giorno dopo giorno senza essere scelta ha un tasso di invocazione basso, il che significa che è inutile oppure descritta in modo tale da non far capire quando usarla.
• Tasso di modifica dopo l’utilizzo = la quota di volte in cui un’abilità è stata invocata ma l’utente ha poi modificato manualmente il risultato. Un valore alto significa che ciò che l’abilità ha prodotto non corrisponde del tutto ai gusti dell’utente.
• Tasso di inefficacia = la quota di volte in cui un’abilità è stata invocata ma il turno si è concluso con un errore non transitorio. Un valore alto suggerisce che potrebbe esserci qualcosa che non va nell’abilità stessa.

Qui riemerge quell’eccezione: nel calcolo del tasso di inefficacia, gli errori transitori non contano, e nemmeno i turni che l’utente ha interrotto manualmente prima della fine. Non si può penalizzare un’abilità perfettamente valida per un singolo problema occasionale di rete.

Con questi pochi numeri, le abilità passano dall’"accumularsi in una scatola nera" a essere "qualcosa che si può valutare e ottimizzare". Decidere quale abilità rivedere o eliminare non è più una scelta d’istinto.

Chiudere il ciclo

Collegando quanto descritto sopra, un ciclo completo funziona così:

L’agente svolge attività reali, registrando localmente i dati delle esecuzioni e annotando sul posto i segnali man mano che procede. Quando arriva il momento del ciclo di riflessione in background, il sistema seleziona gli agenti che hanno novità e il cui intervallo minimo di attesa è trascorso, organizza l’attività recente di ciascuno in un pacchetto e fa sì che il modello la esamini alla luce della propria attuale comprensione di sé: unendo ciò che va unito, ritirando ciò che va ritirato e distillando ciò che va distillato in nuove abilità. Il risultato dell’esame diventa abilità e comprensione di sé. Nella conversazione successiva, quelle abilità entrano nell’indice del prompt e la comprensione di sé entra nel prompt di sistema, e l’agente si ripresenta portando con sé ciò che ha imparato nel ciclo precedente. Poi questo ciclo produce nuove metriche e nuovi segnali, che tornano al punto di partenza.

Il ciclo prosegue, una volta dopo l’altra. Non ogni ciclo porta un salto spettacolare, ma la direzione è unica: capirti meglio e ripetere meno gli stessi errori.

Alcuni compromessi da esplicitare

Ripensandoci, alcune decisioni in questo meccanismo sono fondamentali.

L’introspezione deve costare poco. L’osservazione di sé usa metriche senza costi per il modello; la riflessione davvero costosa viene spostata in background, eseguita di rado e subordinata prima al controllo delle modifiche. Limitando con decisione la parte "costosa", l’intero meccanismo può funzionare davvero.

Meglio non imparare che imparare male. L’esclusione degli errori transitori, la possibilità per la riflessione di "non salvare nulla", la scrittura di istruzioni imperative eseguibili invece di descrizioni vaghe: tutto esprime lo stesso giudizio. Per un sistema capace di migliorarsi, imparare nella direzione sbagliata è molto più pericoloso che imparare lentamente.

Ciò che viene imparato deve essere visibile, modificabile e nelle tue mani. Le abilità sono file di testo semplice, la comprensione di sé è un promemoria in testo semplice, l’efficacia delle abilità si può verificare tramite metriche, e tutti questi file risiedono sul tuo computer, non nel cloud. Nessuna scatola nera: una persona può aprirli e modificarli in qualsiasi momento.

Mettere dei freni all’apprendimento. Limiti al numero, rimozione LRU, limiti di lunghezza: senza questi vincoli, l’"apprendimento continuo" prima o poi diventa "crescita incontrollata continua". Dimenticare, scartare e sfoltire contano quanto ricordare.

Conclusione

L’autoevoluzione di Orkas consiste, in sostanza, nell’aggiungere un ciclo lento all’agente: il ciclo veloce è la risposta immediata di ogni conversazione; quello lento è guardarsi periodicamente indietro e distillare l’esperienza in qualcosa di utilizzabile la volta successiva. La parte difficile non è "far ricordare al modello", ma le valutazioni ingegneristiche che è facile trascurare: come distinguere le esperienze che vale la pena registrare, come non farsi sviare da un errore occasionale, come rendere davvero eseguibile ciò che viene imparato e come sfoltirlo prima che cresca troppo.

Nel loro insieme, queste valutazioni trasformano "diventa più utile quanto più lo usi" da slogan di marketing in un meccanismo che funziona davvero. Un assistente che impara da te, e che non imparerà le cose sbagliate, potrebbe essere più vicino a ciò che la maggior parte delle persone desidera davvero rispetto a uno che è soltanto più intelligente.

Per conoscere gli agenti specializzati su cui si basa questo ciclo lento, esplora il team di agenti Orkas.