Ho avuto la stessa idea, quindi ho iniziato a giocarci in nanochat. Ad esempio, ecco 8 agenti (4 claude, 4 codex), con 1 GPU ciascuno che eseguono esperimenti nanochat (cercando di eliminare il softcap logit senza regressione). Il TLDR è che non funziona ed è un pasticcio... ma è comunque molto bello da vedere :) Ho provato alcune configurazioni: 8 ricercatori indipendenti, 1 scienziato capo che assegna lavoro a 8 ricercatori junior, ecc. Ogni programma di ricerca è un ramo git, ogni scienziato lo fork in un ramo di funzionalità, worktree git per isolamento, file semplici per comunicazioni, salto di Docker/VM per semplicità al momento (trovo che le istruzioni siano sufficienti per prevenire interferenze). L'organizzazione di ricerca funziona in griglie di finestre tmux di sessioni interattive (come Teams) in modo che sia bello da vedere, vedere il loro lavoro individuale e "prendere il controllo" se necessario, cioè niente -p. Ma ok, il motivo per cui finora non funziona è che le idee degli agenti sono semplicemente piuttosto scarse di default, anche alla massima intelligenza. Non pensano attentamente alla progettazione degli esperimenti, eseguono variazioni un po' insensate, non creano baseline solide e non ablatano le cose correttamente, non controllano attentamente il runtime o i flops. (giusto per fare un esempio, un agente ieri ha "scoperto" che aumentare la dimensione nascosta della rete migliora la perdita di validazione, che è un risultato totalmente spurio dato che una rete più grande avrà una perdita di validazione più bassa nel regime di dati infiniti, ma poi si allena anche per molto più tempo, non è chiaro perché io debba intervenire per farlo notare). Sono molto bravi a implementare qualsiasi idea ben definita e descritta, ma non generano creativamente idee. Ma l'obiettivo è che ora stai programmando un'organizzazione (ad esempio, una "organizzazione di ricerca") e i suoi agenti individuali, quindi il "codice sorgente" è la raccolta di prompt, abilità, strumenti, ecc. e processi che la compongono. Ad esempio, un incontro quotidiano al mattino è ora parte del "codice dell'organizzazione". E ottimizzare il pre-addestramento di nanochat è solo uno dei tanti compiti (quasi come una valutazione). Poi - data una qualsiasi attività, quanto velocemente la tua organizzazione di ricerca genera progressi su di essa?

Con l'imminente tsunami di domanda per i token, ci sono opportunità significative per orchestrare la memoria+calcolo sottostante *proprio nel modo giusto* per i LLM. Il vincolo fondamentale e non ovvio è che, a causa del processo di fabbricazione dei chip, si ottengono due pool di memoria completamente distinti (anche di diverse implementazioni fisiche): 1) SRAM on-chip che è immediatamente accanto alle unità di calcolo, incredibilmente veloce ma di capacità molto bassa, e 2) DRAM off-chip che ha una capacità estremamente alta, ma il cui contenuto può essere estratto solo attraverso una lunga cannuccia. Inoltre, ci sono molti dettagli dell'architettura (ad es. array sistolici), numeri, ecc. La progettazione del substrato fisico ottimale e poi l'orchestrazione della memoria+calcolo attraverso i flussi di lavoro volumetrici superiori dei LLM (inference prefill/decode, training/finetuning, ecc.) con il miglior throughput/latency/$ è probabilmente il puzzle intellettuale più interessante di oggi con le ricompense più elevate (\cite 4.6T di NVDA). Tutto ciò per ottenere molti token, velocemente e a basso costo. Si potrebbe sostenere che il flusso di lavoro che potrebbe contare di più (inference decode *e* su lunghi contesti di token in loop agentici stretti) è quello più difficile da realizzare simultaneamente dai ~due campi di ciò che esiste oggi (HBM-first adiacente a NVIDIA e SRAM-first adiacente a Cerebras). Comunque, il team di MatX è di grado A++, quindi è un piacere avere un piccolo coinvolgimento e congratulazioni per il finanziamento!

I CLI sono super entusiasmanti proprio perché sono una tecnologia "legacy", il che significa che gli agenti AI possono usarli nativamente e facilmente, combinarli, interagire con essi tramite l'intero toolkit del terminale. Ad esempio, chiedi al tuo agente Claude/Codex di installare questo nuovo CLI di Polymarket e chiedi qualsiasi dashboard, interfaccia o logica arbitraria. Gli agenti lo costruiranno per te. Installa anche il CLI di Github e puoi chiedere loro di navigare nel repository, vedere problemi, PR, discussioni, persino il codice stesso. Esempio: Claude ha costruito questa dashboard del terminale in ~3 minuti, dei polymarkets con il volume più alto e il cambiamento nelle ultime 24 ore. Oppure puoi trasformarlo in un'app web o in qualsiasi cosa tu voglia. Ancora più potente quando lo usi come modulo di pipeline più grandi. Se hai qualche tipo di prodotto o servizio, pensa: gli agenti possono accedervi e usarli? - i tuoi documenti legacy (per umani) sono almeno esportabili in markdown? - hai scritto Skills per il tuo prodotto? - il tuo prodotto/servizio può essere utilizzato tramite CLI? O MCP? - ... È il 2026. Costruisci. Per. Agenti.