La scorsa settimana ho scritto su NeMoCo, un sistema auto-supervisionato che impara a categorizzare le strutture neurali nel modo in cui i cervelli categorizzano il mondo — dall'esperienza grezza e non etichettata, senza essere informato quali siano le categorie. Sono tornato ripetutamente sulla stessa frase: le etichette sono una scorciatoia, la struttura è ciò che conta.

Questa settimana ho costruito l'altra metà di quell'idea, nel dominio in cui effettivamente lavoro. Gestisco un assistente AI personale — Aura — che gestisce la memoria, instrada le attività e cerca di essere genuinamente utile tra le sessioni. Esegue su una flotta di modelli: Claude per la codifica in produzione, una manciata di modelli cloud per ricerca e design, e un modello locale che non consuma nulla. Il problema è lo stesso che risolve NeMoCo, solo invertito. NeMoCo apprende la struttura dai dati grezzi. Io avevo la struttura — un elenco di agenti, ciascuno con un compito — e avevo bisogno che il sistema decidesse quale modello dovesse svolgere quale attività, in tempo reale, sotto un budget che si esaurisce.

Quel motore decisionale è ciò che ho costruito questa settimana. È composto da tre parti: un classificatore che legge un'attività e decide di che tipo di lavoro si tratta, un router che lo associa alla migliore catena di modelli date le quote live, e un dashboard che rappresenta l'intero sistema come un cervello vivente e pulsante. Questo è il writeup tecnico — cosa fa ciascun pezzo, perché ha quella forma e i fallimenti che hanno imposto il design.

Il Problema: Un elenco non è un router

La configurazione ingenua è una tabella statica: questo agente esegue questo modello, quell'agente esegue quel modello. È semplice, ed è sbagliato, per tre ragioni.

Prima di tutto, il budget si esaurisce. Claude opera con una quota settimanale e una quota di sessione rolling, e si muovono indipendentemente. In un giorno la quota settimanale era al 15% mentre quella di sessione era al 71% — e poiché il vecchio router osservava solo il numero settimanale, ha segnalato "Claude disponibile, modalità NORMAL" e ha instradato il lavoro di codifica direttamente contro un muro. La CLI ha rifiutato ogni chiamata per tre ore con "Hai raggiunto il limite di sessione" mentre il dashboard continuava a dire che tutto andava bene. Un router che non legge il limite effettivamente vincolante non è un router, è una congettura.

Secondo, la qualità non è un unico numero. Un modello che scrive buon codice non è necessariamente bravo nel recupero di contesto lungo o nella generazione di UI. Assegnare a ogni modello un singolo punteggio di "qualità" è inutile — non può indicarti quale modello dovrebbe guidare il programmatore rispetto al ricercatore. Ogni agente deve essere valutato sul suo proprio asse.

Terzo, il revisore non deve ereditare i punti ciechi dello scrittore. Abbino deliberatamente uno scrittore e un revisore — il programmatore scrive, il diagnostico recensisce — e devono eseguire diversi famiglie di modelli, altrimenti il revisore semplicemente ripete gli stessi errori. La prima versione del router ha continuamente piazzato entrambe le teste sullo stesso modello perché risolveva i pareggi in base alla latenza. Questo ha vanificato l'intero design.

Così la tabella statica doveva andare via. Cosa l'ha sostituita è un motore di decisione che legge lo stato live e calcola, per attività, la migliore catena di modelli.

Il Classificatore: Lettura dell'attività

Il primo elemento è un classificatore che legge un'attività e decide di che tipo di lavoro si tratta. L'input è una frase — "il punto di accesso del pagamento sta restituendo 500 in produzione dalla distribuzione" — e l'output è un verdetto: tipo, livello e priorità.

La prima versione era solo regex. Ha funzionato, ed era fragile esattamente nei modi in cui regex lo è sempre. "analizzatore di log" è stato instradato male verso le operazioni (è un componente di codice, non un task operativo). "Il checkout sta addebitando il doppio ai clienti" non aveva alcun vocabolario di errore, quindi è stato classificato come unknown ed è passato attraverso l'agente principale — durante un incidente in produzione. "Lancio di 500s" non ha corrisponduto al pattern dei codici di stato perché la 's' finale ha interrotto il confine della parola. Ognuno di questi è stato un instradamento errato reale che ho corretto uno alla volta, e ogni correzione è stata una nuova regola regex. Questo è il segno che stai combattendo lo strumento sbagliato.

Ora il classificatore prova prima un modello economico — `deepseek-v4-flash:cloud` legge l'attività e restituisce un verdetto JSON. Se il modello non è disponibile, torna al classificatore regex. Il modello è il percorso principale; il regex è la rete di sicurezza. Questa è la stessa lezione di NeMoCo: non etichettare manualmente ogni caso, apprendi la struttura e lascia che si trasferisca.

Il classificatore riceve anche la quota live dal suo chiamante, quindi non può mai deviare dal router. Il chiamante legge lo stato della quota e lo passa; il classificatore non legge direttamente il file della quota. La regola chiave: il lavoro di produzione non viene mai declassato su un modello debole, per quanto stretto sia il budget. Un incidente di produzione viene classificato come `prod` anche quando Claude è esausto — non viene silenziosamente reindirizzato a un agente leggero e segnalato come completato. Si blocca, e il protocollo di handoff si attiva. Il rischio di qualità è peggiore del rischio di quota, e il design non dimentica mai quale sia quale.

Il Router: Il Motore di Decisione

Il router è dove avviene il vero pensiero. Prende il verdetto del classificatore e lo stato live del provider, e calcola una catena di modelli per livello di attività.

Il nucleo è punteggio basato su assi. Ogni agente viene valutato sul proprio asse di competenza — il coder sulla generazione di codice, il diagnostico sul ragionamento di debug, il ricercatore sul recupero di fatti, il creativo sulla generazione di UI, l'ops sulla chiamata di strumenti, il main sull'orchestrazione. La qualità effettiva di un modello è il suo punteggio di benchmark sintetico times la sua affidabilità osservata nelle sessioni reali. Un modello che ottiene buoni risultati nei benchmark ma presenta errori in produzione viene declassato. Questo è lo strato "impara dalle prestazioni reali": il benchmark rappresenta la capacità sintetica, i dati di affidabilità sono ciò che ha effettivamente retto.

La formula di punteggio è la matrice di pesi di Bander: `score = quality·Wq − cost·Wc − latency·Wl + claudeBonus`. Il costo è un livello relativo su scala 0..1, non dollari reali — poiché ollama cloud non ha prezzo per chiamata e Claude è un abbonamento, non è possibile scalare onestamente i due valori in modo min-max l'uno contro l'altro. inoltre esiste un limite minimo di qualità rigido: un candidato che ottiene un punteggio inferiore a questo limite sul proprio asse viene scartato prima del ranking, quindi un modello economico ma poco intelligente non può mai vincere solo grazie al prezzo.

Il router gestisce anche il problema di decorrelazione — forzando le teste del coder e del diagnostico su famiglie di modelli diverse in modo che il revisore non erediti i punti ciechi dello scrittore. E gestisce anche l'economia dei sottagenti: un sottagente esegue una porzione del lavoro del suo genitore, e una singola delega può espandersi fino a 20×, quindi le catene di sottagenti attribuiscono un peso al costo di gran lunga superiore a qualsiasi livello standard. È questo che tiene Claude fuori dalle catene di sottagenti senza un'esclusione rigida — con un peso di costo di 0,45 semplicemente non può vincere.

La Dashboard: Il Cervello Robotico

La dashboard è la parte più difficile da catturare in testo. Essa rende l'intero sistema come un cervello vivente.

C'è una vista 3D del cervello — una struttura neurale renderizzata con WebGL dove ogni agente è una regione, e puoi orbitare, zoomare e fare clic su una regione per approfondire la sua catena di modelli, le statistiche e il selettore di override. E nella vista a griglia c'è il "pezzo centrale del cervello elettronico": una scheda circuito SVG dove gli agenti sono nodi di flusso di lavoro collegati da tracce di segnale animate, con l'intero sistema che pulsa più velocemente o più lentamente in base all'attività in tempo reale.

Il cervello non è solo decorazione. È la telemetria resa visibile. La dashboard deriva l'attività per agente dalla crescita dei file di sessione tra i polling — il segnale più forte che indica che un agente sta effettivamente lavorando — e la rappresenta come impulsi di segnale che viaggiano lungo le tracce del circuito. Quando il sistema è inattivo, il cervello rallenta fino a quasi fermarsi. Quando è impegnato, le tracce corrono veloci. Puoi vedere il cervello pensare.

C'è anche un selettore di livello — sei pulsanti (Livello 1–4, uno scudo "Locale" e un ripristino "Baseline") che ti consentono di forzare l'intera flotta su un determinato livello di qualità. E le sovrascritture di modello per agente, persistite in un file, così puoi fissare un modello specifico a un agente specifico quando la scelta del router in tempo reale non è quella desiderata. La dashboard è la superficie di controllo del cervello.

I fallimenti che lo hanno plasmato

Ogni decisione di progettazione qui è una cicatrice derivante da un vero fallimento, e vale la pena elencarle perché sono il contenuto effettivo della settimana:

• Il punto cieco del limite di sessione. Il router applicava il gate solo sulla quota settimanale e ignorava la quota di sessione che era effettivamente vincolante. La correzione: leggere entrambi e lasciare che quello più stretto prevalga.
• Il bug dell'involucro del benchmark. Il benchmark rev1 ha scritto il suo file in un involucro `{value:[...]}` invece di un semplice array, quindi ogni riga mancava del campo `.model` e il router ha ricevuto silenziosamente una mappa vuota. I dati del benchmark non hanno mai raggiunto il router e nessuno si è lamentato. La correzione: estrarre la forma legacy così i file vecchi possono ancora essere caricati.
• L'inversione dell'asse-rubrica. La rubrica dell'asse ha assegnato a opus un punteggio di 0.50 nel ragionamento di debug — al di sotto di un modello che non dovrebbe mai revisionare il codice di produzione. Consentirgli di riordinare i livelli di produzione avrebbe fatto del revisore lo scrittore. La correzione: i livelli prod non sono ri-ordinati dalla rubrica. Una rubrica basata su parole chiave non è una prova sufficientemente forte per rovesciare una decisione di progettazione dichiarata.
• La spirale della morte della finestra di contesto. Inserire un modello 131k-context alla testa del livello di orchestrazione ha fatto traboccare la finestra e ha attivato la spirale della morte della compattazione. La correzione: ogni candidato di orchestrazione deve avere una finestra comodamente al di sopra del budget di contesto più la riserva.
• L'operazione nulla di affidabilità. I log delle sessioni memorizzano il nome del modello senza prefisso mentre i candidati includono un prefisso del provider, quindi il livello di affidabilità non ha trovato alcuna corrispondenza. La correzione: rimuovere il prefisso prima della corrispondenza.

Cosa porto via

Il post di NeMoCo si è concluso con: le etichette sono una scorciatoia, la struttura è ciò che conta, e si può imparare la struttura dall'esperienza grezza. Questa settimana è stata la versione ingegneristica di quello. Non ho scritto a mano una regola per ogni attività — ho costruito un classificatore che legge l'attività e un router che legge lo stato live, e ho lasciato che la struttura del lavoro decidesse lo strumento. Il classificatore delle espressioni regolari è stato l'approccio delle "etichette", e si è rotto esattamente dove le etichette si rompono sempre: ai margini, nei casi che non avevi previsto. Il classificatore assistito dal modello è l'approccio della "struttura": impara il pattern, trasferiscilo, fai fallback con eleganza.

E il cruscotto del cervello è la parte che lo fa sembrare reale. Quando puoi osservare gli impulsi di segnale correre lungo le tracce del circuito mentre gli agenti lavorano effettivamente, e vedere l'intero sistema rallentare fino a strisciare quando è inattivo, non stai più guardando un file di configurazione. Stai osservando un sistema che ha un battito.

Il router è open-source nello spirito — è un insieme di script nella mia area di lavoro, `classify-job.mjs`, `model-router-core.ps1`, `quota-dashboard.mjs` — e funziona su un mix di Claude, modelli ollama cloud e un modello locale che non consuma nulla. Non è un sistema aziendale bloccato. È un motore decisionale che potresti costruire tu stesso, e i fallimenti che lo hanno plasmato sono la parte utile.

Questa è la lezione. Un elenco è una lista. Un instradatore è una decisione. E un cervello è ciò che ottieni quando la decisione viene presa dal vivo, con un bilancio che si esaurisce, da un sistema che impara dai propri errori.