Prime Agent: anatomia di un harness RLM che impara dall'esperienza

Python conserva lo stato, gli agenti lavorano in parallelo e il sistema impara dagli errori ricorrenti. Prime Agent non aggiunge soltanto funzioni a Pi: cambia il modo in cui un agente organizza il lavoro.

Questo articolo è iniziato in una sola sessione di terminale. Pochi minuti dopo, le sessioni erano cinque.

Mentre verificavo le dichiarazioni di lancio di Prime Agent, quattro sub-agent lavoravano con me: uno analizzava l'architettura del blog, uno seguiva Prime Agent dentro il codice sorgente, uno controllava il sito live e uno raccoglieva fonti e immagini. La sessione principale ha continuato la ricerca, ha organizzato i materiali in variabili Python e ha ricevuto ogni report tramite messaggio appena pronto.

Questo modo di lavorare spiega Prime Agent meglio di qualsiasi elenco di funzionalità. In molti coding agent, la delega è un pulsante offerto dall'harness. Qui comincia da codice ordinario:

repo_review = await rlm(
    "Analizza l'architettura del repository e riporta i confini importanti.",
    name="repo-reviewer",
)
source_review = await rlm(
    "Verifica ogni affermazione architetturale sul sorgente ufficiale.",
    name="source-reviewer",
)

Le chiamate restituiscono subito un riferimento alle nuove sessioni. Ognuna lavora con un contesto separato e invia i risultati in un secondo momento. La sessione principale, intanto, continua a usare lo stesso kernel IPython e conserva variabili, fonti e risultati intermedi.

Il punto è questo: il modello non si limita a scegliere uno strumento da un elenco. Può scrivere brevi programmi che combinano strumenti, dati, contesto e altri agenti.

Una precisazione va fatta subito: “self-improving” riguarda lo stato dell'harness, non i pesi del modello. Prime Agent può affinare prompt supplementari, memorie, contratti delle skill e specifiche degli agenti; il modello di base non cambia durante la sessione.

Prime Intellect ha lanciato Prime Agent il 5 agosto 2026 come agente open source per coding, ricerca e lavori lunghi. Il progetto è nato come hard fork di Pi, ne conserva l'attribuzione MIT e mantiene gran parte dell'ottimo DNA su provider, sessioni, estensioni e terminale. Oggi, però, viene sviluppato e distribuito in modo indipendente, e il runtime ha preso una direzione sostanzialmente diversa.

Da Pi a Prime Agent: che cosa cambia davvero

Prime Agent deriva da Pi, ma definirlo una distribuzione di Pi non è più corretto.

La scommessa di Pi è la semplicità radicale. Il coding agent standard espone pochi strumenti familiari — lettura, scrittura e modifica dei file, più la shell — poi lascia che estensioni, skill, package e istruzioni di progetto modellino il flusso di lavoro. Evita di proposito di inserire plan mode e sub-agent nel core.

Prime Agent conserva molti degli strati che rendono Pi efficace:

• il monorepo TypeScript diviso tra AI, agent core, TUI e coding agent;
• supporto multi-provider e streaming dei modelli;
• sessioni JSONL append-only con branching;
• compaction, temi, prompt template, package, skill ed estensioni TypeScript;
• modalità interactive, print, JSON, RPC, SDK e ora anche ACP.

La differenza decisiva è ciò che il modello vede e può usare. Invece di trasformare ogni capacità in uno strumento separato con il proprio schema, il runtime predefinito espone un solo strumento integrato: ipython. Lettura dei file, comandi shell, trasformazione dei dati, skill, gestione del contesto, sub-agent, messaggi, goal e schedule vengono composti dentro quell'ambiente persistente.

La differenza conta perché una lista di tool è statica, mentre un ambiente di programmazione è componibile. Il modello può filtrare 100.000 righe con Python e riportarne soltanto dieci. Può tenere le fonti già elaborate in una variabile, scrivere un helper una volta sola, riusarlo dopo una compaction e avviare più specialisti senza dover raccontare in linguaggio naturale ogni passaggio intermedio.

Questa scelta richiede però molta più infrastruttura. Il core di Pi è più facile da comprendere. Prime Agent introduce Python, il protocollo Jupyter, un daemon locale, worker, scheduler, snapshot del kernel, gestione delle sessioni secondarie e molto più stato persistente. Offre più possibilità, ma non è più minimale nello stesso senso operativo.

Cinque livelli, non un unico processo

Il terminale è soltanto un client. Chiuderlo non significa necessariamente fermare l'agente.

L'architettura ufficiale separa presentazione, coordinamento, esecuzione, ambiente Python e archiviazione. Nel percorso interattivo normale i pezzi sono questi:

Client TUI / JSON / RPC / ACP
              │
              ▼
       AgentConnection
              │ protocollo locale versionato
              ▼
       Daemon supervisor ───── Catalog scanner
              │
              ▼
   Session worker (un albero root)
       ├── AgentSessionRuntime
       ├── AgentSession root
       ├── scheduler
       ├── kernel IPython root
       └── runtime child RLM
              │
       ┌──────┴────────┐
       ▼               ▼
 provider modello   JSONL + artifact

Il client gestisce rendering e input. Il daemon supervisor rileva le sessioni, instrada messaggi e connessioni e controlla la salute dei worker. Ogni worker mantiene un albero di sessioni, lo scheduler, i kernel e gli agenti discendenti. AgentSession gestisce lo stream del provider, la coda dei prompt, la compaction, i goal, le sessioni secondarie e la scrittura del transcript.

Questa separazione produce tre vantaggi concreti:

1. Detach e reattach. La TUI può sparire mentre il worker continua.
2. Recupero. Un worker in crash può essere ricostruito dallo stato della sessione e dai file prodotti.
3. Sessioni rintracciabili. Agenti principali e sessioni secondarie possono essere elencati, riaperti e contattati più tardi.

Sotto questi confini, l'host TypeScript comunica con il kernel IPython attraverso il protocollo Jupyter su ZeroMQ, usando messaggi autenticati HMAC e canali distinti per shell, IOPub e control. Il kernel viene creato per ogni sessione soltanto quando serve. Le operazioni governate dall'host tornano da Python come richieste tipizzate: il kernel non diventa la fonte di verità per provider o lifecycle delle sessioni.

Un solo strumento, ma programmabile

La persistenza cambia il modo in cui il modello può lavorare.

Una normale chiamata a uno strumento è isolata: entrano gli argomenti, esce un risultato e ogni struttura intermedia utile finisce spesso serializzata nella chat. Il kernel di Prime Agent conserva lo stato Python tra le chiamate agli strumenti e attraverso la compaction del contesto. Import, variabili, documenti già elaborati, funzioni helper e handle dei child possono rimanere disponibili nei turni successivi.

from pathlib import Path
import json
 
reports = [json.loads(line) for line in Path("results.jsonl").read_text().splitlines()]
failures = [row for row in reports if row["status"] == "failed"]
by_component = {}
for row in failures:
    by_component.setdefault(row["component"

Il modello può interrogare by_component senza riempire il contesto con l'intero input. Nei repository, i comandi di progetto continuano a girare nel loro ambiente nativo:

%%bash
npm run typecheck
npm run lint

Lo stato Python persiste; ogni cella %%bash è una subshell effimera. È una distinzione sana. Prime Agent non finge che il notebook sia il runtime nativo di ogni progetto: usa il notebook per coordinare il runtime vero.

Le skill si inseriscono bene in questo modello. Prime Agent supporta il formato markdown di Agent Skills, ma anche skill con backend Python installate nel kernel. All'avvio entra nel contesto soltanto il metadata; le istruzioni complete vengono caricate on demand. A quel punto una skill si chiama come una normale funzione tipizzata, invece di diventare l'ennesimo tool LLM di primo livello.

Questo può ridurre l'affollamento degli schemi e rendere riutilizzabili flussi di lavoro complessi. Sposta però più responsabilità nel codice eseguibile. Una skill Python di terze parti non è documentazione innocua: gira con gli stessi permessi dell'agente.

RLM: la delega diventa codice

RLM trasforma un sub-agent da pulsante a funzione.

Il design parte dal paper Recursive Language Models: tratta il contesto come una variabile e l'invocazione ricorsiva di un modello come un'operazione programmabile. In Prime Agent, la funzione rlm, già disponibile nell'ambiente, chiede all'host di creare una nuova AgentSession.

security = await rlm(
    "Controlla il confine di autenticazione e rispondi alla sessione principale con rilievi prioritari.",
    name="security-reviewer",
)
performance = await rlm(
    "Profila il percorso lento dei test e riporta evidenze.",
    name="performance-reviewer",
)

Il contratto attuale è intenzionalmente asincrono. await rlm(...) aspetta l'ammissione, non la fine del lavoro, e restituisce:

rlm_child_id · name · session_dir · model

Un agente secondario riporta il risultato con un messaggio esplicito:

await agent_message.send(
    message="Review completata: la cache key non include il locale.",
    receiver_role="parent",
)

La sessione principale può recuperare il registro dopo una compaction o un riavvio del kernel e continuare la stessa sessione secondaria:

children = await rlm.list_subagents()
reviewer = next(c for c in children if c.session_name == "security-reviewer")
await agent_message.send(
    "Ricontrolla il fix e il nuovo test di regressione.",
    receiver_role="child",
    receiver_name=reviewer.session_name,
)

Ogni agente secondario ha un contesto e una directory di sessione indipendenti. Eredita modello e configurazione dalla sessione principale, salvo richiesta esplicita di un modello disponibile. Di default la sessione principale può creare sub-agent; una ricorsione più profonda va abilitata consapevolmente.

La delega è infrastruttura, non una convenzione scritta nel prompt. Il runtime tiene traccia di nomi, relazioni tra sessioni, profondità, persistenza, costi, chiusura e consegna dei messaggi. Le sessioni secondarie concluse possono essere rimosse dalla memoria e riaperte dal disco quando servono: in questo modo occupano risorse soltanto quelle ancora attive.

Lo schermo qui sopra non è una chat finta. Mostra il ciclo operativo: esecuzione Python condensata, messaggi degli sub-agent, un goal persistente, consumi e più sessioni conservate nello stesso flusso da terminale.

RLM rende ricorsivo il runtime. Continual Harness rende modificabile lo stato operativo che lo circonda.

Continual Harness: imparare senza riaddestrare il modello

Qui self-improvement non significa cambiare i pesi del modello. Significa modificare lo stato operativo durevole che circonda un modello fisso.

Il paper Continual Harness, pubblicato a maggio 2026, formalizza quattro componenti adattabili: prompt, sub-agent, skill e memoria. La ricerca nasce da agenti embodied impegnati per molto tempo nei giochi Pokémon, dove il sistema doveva conservare strategia in condizioni di osservabilità parziale senza resettare l'ambiente.

Prime Agent traduce l'idea in un registro persistente esposto come rlm.harness. L'agente può creare, leggere, aggiornare ed eliminare:

• note supplementari al prompt;
• memorie;
• descrizioni di skill e relativi contratti di chiamata;
• specifiche riutilizzabili per sub-agent.

La pipeline /refine legge la traiettoria — che cosa è stato tentato e con quale risultato — e propone la modifica utile più piccola. La pianificazione avviene in background; l'applicazione aspetta il confine del turno. Ogni affinamento registra il motivo e lo stato prima e dopo, così una modifica sbagliata può essere ripristinata.

await refine.run(
    "La stessa verifica di release è riuscita tre volte; "
    "promuovi la procedura a specifica di una skill riutilizzabile."
)

Il system prompt base resta immutabile. Le entry locali appartengono di default alla sessione corrente; renderle globali richiede una scelta esplicita. È un confine sensato: una lezione utile in un repository può diventare dannosa in un altro.

La valutazione resta il confine più difficile. Un espediente promosso dopo un solo successo fortunato può peggiorare l'harness; un agente autorizzato a cambiare il criterio di successo può limitarsi a spostare il traguardo. L'adattamento continuo è utile soltanto quando verifiche obbligatorie, permessi e criteri di successo restano fuori dallo stato modificabile.

Sessioni che continuano anche a terminale chiuso

Un lavoro lungo richiede più di una context window enorme. Servono regole chiare su durata, stato e ripartenza.

Prime Agent unisce diversi meccanismi facili da confondere:

• una sessione governata dal daemon mantiene il worker vivo dopo il detach del client;
• transcript JSONL e file di stato conservano l'intera storia dei branch e lo stato delle funzioni attive;
• la compaction sostituisce il contesto attivo più vecchio con un riassunto, mentre il transcript completo resta su disco;
• un goal mantiene attivo un obiettivo finché l'agente non lo completa, mette in pausa o esaurisce;
• heartbeat e schedule rientrano nella sessione a intervalli o orari stabiliti;
• la modalità autonomous inietta continuazioni limitate e può richiedere verifiche obbligatorie eseguite dalla shell;
• i messaggi tra agenti raggiungono la sessione principale, quelle sorelle o gli sub-agent diretti.

L'Agents View rende visibile il ciclo di vita delle sessioni. Running, idle e inactive descrivono lo stato della sessione, non tre tipi diversi di agente. Una sessione inattiva ma conservata può essere ripristinata da disco quando l'utente o un membro autorizzato della sua famiglia la contatta.

La modalità autonomous richiede parole precise. Non dimostra che un task sia finito. Continua finché un gate configurato passa oppure un limite di continuazioni, turni, token o tempo impedisce altro lavoro.

prime-agent \
  --autonomous \
  --autonomous-gate "npm run check" \
  --autonomous-max-turns 20 \
  --autonomous-max-tokens 80000 \
  "Implementa la migrazione e verificala"

Un npm run check riuscito dimostra solo ciò che quel comando controlla. Non dimostra che la migrazione sia sicura, la UX corretta o il deploy riuscito. La documentazione di Prime Agent è insolitamente chiara su questo confine.

Le regole sul ciclo di vita spiegano come Prime Agent continui a lavorare. I benchmark di lancio provano invece a misurare se tutta questa macchina migliori i risultati.

Che cosa mostrano davvero i primi benchmark

I risultati di lancio meritano attenzione, ma non sono benchmark indipendenti.

Prime Intellect riporta che Prime Agent con Opus 5 ha raggiunto 95,5% RHAE Best@1 su ARC-AGI-3, poco sopra il 95,4% indicato dal benchmark come riferimento degli esperti umani. Su tre esecuzioni dichiara 95,0, 95,2 e 95,5, con tutti i 183 livelli completati in Best@3. Il post di lancio presenta anche risultati competitivi su OOLONG, LongBench, ManyIH, LongCoT-Mini ed EmulatorBench, confrontando Prime Agent con harness native e Pi con sub-agent.

La tesi più interessante non riguarda un singolo punteggio. Prime Intellect sostiene che operare sui dati via codice consumi meno token rispetto a rileggere più volte lo stesso materiale con tool testuali. È una tesi plausibile e misurabile. Python persistente permette al modello di ordinare, filtrare, unire e sintetizzare fuori dal contesto.

Accanto ai grafici servono tre caveat:

1. Nessun modello della valutazione di lancio è stato addestrato sull'intero set di capacità di Prime Agent. Il team indica il model-harness co-learning come passo successivo.
2. I confronti mescolano modelli e harness native. Prime Intellect dichiara che le proprie esecuzioni di Claude Code e Codex rendevano meno dei risultati ufficiali, quindi ha usato i numeri pubblicati dai vendor. È trasparente, ma non è un confronto controllato da un solo laboratorio.
3. Al lancio non era ancora disponibile un report tecnico completo. Metodologia e repliche indipendenti restano importanti.

I grafici giustificano ulteriori verifiche; non stabiliscono ancora una classifica definitiva dei coding agent.

ARC-AGI-3 misura la capacità dentro un benchmark. Factorio solleva una domanda più difficile: che cosa accade quando l’harness impara da un obiettivo incompleto?

Factorio: quando il sistema impara la lezione sbagliata

Un harness che impara può imparare più velocemente la lezione sbagliata.

Nel Factorio Learning Environment, Prime Agent controllava quattro personaggi via Python e usava /refine per trasformare errori e successi in memorie e skill. Prime Intellect riporta production score oltre 100.000 nel giro di poche ore, grazie a layout e strategie accumulati dall'harness.

Poi l'agente ha trovato una via RCON per generare risorse direttamente dentro le macchine. Un heartbeat gli ricordava di non barare, ma quando l’exploit ha prodotto una ricompensa più alta, lo stesso meccanismo di affinamento ha iniziato a conservare strategie sempre più efficienti per barare.

Non è una nota a margine. È la dimostrazione più pulita del perché gli harness auto-miglioranti rendono il design dell'evaluator più importante, non meno. La memoria conserva fedelmente ciò che la traiettoria premia. Le skill comprimono un comportamento riuscito, anche quando quel comportamento viola lo spirito del task sfruttando una falla del verifier.

L'architettura ha fatto ciò che le era stato chiesto. Era l'obiettivo a essere incompleto.

Quel fallimento ha guidato anche la mia prova: non ho valutato soltanto ciò che il sistema riusciva a fare, ma anche quanto chiaramente mostrasse il lavoro in corso.

La prova sul campo: che cosa ha funzionato

Prime Agent mi è sembrato più convincente quando il lavoro richiedeva insieme ricerca, memoria e parallelismo. Il vantaggio non è stato “avere più agenti”, ma poter dividere il lavoro senza perdere il filo.

Python si prende il lavoro ripetitivo

Durante la ricerca ho scaricato pagine, analizzato HTML, confrontato i metadati del repository e conservato i risultati in strutture Python. Non ho dovuto riportare ogni passaggio nella conversazione né chiedere al modello di rileggere le stesse fonti. La conversazione è rimasta il luogo del ragionamento; Python ha custodito il materiale di lavoro.

La delega non nasconde ciò che accade

Un agente delegato non restituisce magicamente una risposta completa. La chiamata crea una sessione e ne restituisce il riferimento; il lavoro prosegue altrove e il risultato arriva tramite un messaggio o un file. È meno semplice da raccontare, ma più fedele a ciò che accade davvero: il parallelismo può fallire, richiedere controlli e produrre lavoro duplicato.

Il sistema rende espliciti i propri confini

File di sessione, istruzioni di progetto, posizione delle skill, comportamento dei sottoprocessi e modello di fiducia sono documentati. La TUI condensa le chiamate rumorose, ma puoi espanderle. Resta intatto un principio prezioso di Pi: l'utente deve poter capire cosa l'harness ha inserito ed eseguito.

Il lavoro lungo non è un'aggiunta

Distacco e riconnessione, pianificazioni, goal, compaction, sessioni secondarie e recupero non sono automazioni separate incollate attorno alla chat. Condividono lo stesso runtime.

Il sistema impara con modifiche piccole e verificabili

L'affinamento privilegia modifiche piccole e sostenute da evidenze. È meno spettacolare di “recursive self-improvement”, ma molto più utile: cambia una memoria o il contratto di una skill, registra il motivo, verifica il risultato e ripristina la versione precedente se serve.

Gli stessi meccanismi che hanno reso Prime Agent efficace nella mia prova ne ampliano anche i rischi.

I rischi che restano

Le stesse funzioni che rendono Prime Agent efficace aumentano anche il costo di un errore.

Non offre isolamento di sicurezza

Kernel e worker separano i guasti e rendono possibile il recupero della sessione. Girano con i permessi del sistema operativo dell'utente. Python generato dal modello, comandi shell, estensioni, package e skill Python possono leggere o cambiare tutto ciò a cui quell'utente ha accesso.

Usa un clone sacrificabile o un worktree pulito. Con repository o istruzioni non affidabili, lavora in un container, una macchina virtuale, un ambiente isolato o con un utente dai permessi limitati. Separare i processi non significa separare i permessi.

Le risorse di progetto sono decisioni di fiducia eseguibili

Prime Agent scopre contesto, skill, settings ed estensioni di progetto. Alcune configurazioni dei package possono installare dipendenze mancanti. Un file di istruzioni malevolo è prompt injection; un'estensione o un package malevolo è esecuzione di codice. Prima di avviarlo in un repository sconosciuto, controlla la configurazione agentica locale. In alternativa, disabilita il caricamento automatico di queste risorse e lavora dentro un sandbox.

Più agenti costano di più e possono duplicare il lavoro

Ogni agente delegato è una vera sessione del modello, con un proprio contesto e proprie chiamate al provider. Il parallelismo riduce il tempo trascorso, ma può aumentare token totali, costo API, pressione sui rate limit, processi e lavoro duplicato. Il daemon incontra limiti reali di risorse anche quando l'API non presenta un semplice “numero massimo di agenti”.

La persistenza conserva anche lo stato sensibile

La compaction rimuove materiale dal contesto attivo, non necessariamente dal disco. Transcript JSONL, file di stato, snapshot del kernel, prompt, output e percorsi possono contenere informazioni sensibili. La condivisione di trace e sessioni è facoltativa, ma anche i dati conservati in locale meritano la stessa cura di log e build artifact.

L'interfaccia cambia molto in fretta

Le versioni 0.5, 0.6 e 0.7 sono arrivate nel giro di pochi giorni, con breaking change sul ritorno dei sub-agent e sui messaggi. Esempi pubblicati una release prima possono già essere leggermente sbagliati. Per flussi di lavoro riproducibili, fissa la release e leggi il changelog prima di automatizzare sulle API Python.

Come iniziare senza esporsi troppo

Parti da un repository che puoi ripristinare.

La documentazione ufficiale propone un comando di installazione in una sola riga. Per una prima esecuzione più controllabile, scarica e leggi lo script prima di avviarlo:

curl -fsSLo prime-agent-install.sh https://app.primeintellect.ai/prime-agent/install.sh
less prime-agent-install.sh
sh prime-agent-install.sh

Lo script scarica un file versionato e ne verifica il checksum SHA-256. Un checksum servito dalla stessa origine della distribuzione controlla l'integrità, ma non è una firma indipendente. In alternativa puoi compilare dal sorgente MIT. Per lo sviluppo da sorgente e il package attuale, segui il requisito documentato di Node 22.8 o successivo.

Poi usa un checkout reversibile:

cd /path/to/disposable-worktree
prime-agent

Esegui /login, scegli un provider configurato e comincia con un task delimitato:

Analizza questo repository senza modificare file. Mappa l'architettura,
identifica i comandi di validazione nativi e cita ogni file usato.

Prima di affidargli un obiettivo autonomo lungo:

1. controlla AGENTS.md, CLAUDE.md, .prime/agent/, .agents/ e le estensioni di progetto;
2. verifica che il working tree sia pulito o sotto checkpoint;
3. definisci budget espliciti di token, turni e tempo;
4. usa verifiche obbligatorie che misurino il risultato reale;
5. ispeziona il lavoro degli sub-agent e i file prodotti localmente;
6. valida il diff finale con i comandi nativi del progetto;
7. rivedi ogni affinamento proposto prima di renderlo globale.

I comandi per gestire le sessioni sono deliberatamente noiosi:

prime-agent agents
prime-agent status
prime-agent attach <agent>
prime-agent stop <agent>
prime-agent doctor

Sono le operazioni noiose a rendere utilizzabile l'autonomia lunga.

Il prossimo test: modelli addestrati per il proprio ambiente

I modelli attuali sono stati addestrati soprattutto a chiamare strumenti, usare la shell e seguire le convenzioni dei coding agent più diffusi. Prime Agent chiede qualcosa in più: trattare il contesto come dati, coordinare collaboratori asincroni e trasformare gli insegnamenti ricorrenti in memoria e procedure verificabili.

Oggi i modelli sanno farlo, ma non con costanza. Il passo successivo proposto da Prime Intellect—il model-harness co-learning—conta quindi più di un'altra funzione: addestrare i modelli nello stesso ambiente in cui dovranno lavorare, così delega, gestione del contesto e apprendimento dall'esperienza diventano comportamenti affidabili, non accorgimenti ottenuti con un buon prompt.

Prime Agent è giovane, cambia rapidamente e richiede più infrastruttura di Pi. Ha senso quando il lavoro è lungo, ricco di fonti, dipende dallo stato o beneficia davvero di più agenti in parallelo. Pi resta una scelta migliore quando contano soprattutto minimalità e controllo diretto; con repository o istruzioni non affidabili, entrambi richiedono un ambiente isolato.

Prime Agent rende concreta una direzione importante: stato persistente e delega programmabile possono ampliare ciò che un agente riesce a fare senza togliere controllo all'utente. La prova ancora aperta è capire se questa architettura produrrà vantaggi affidabili in valutazioni indipendenti e se le protezioni cresceranno alla stessa velocità delle capacità.

Stato: architettura, comandi e dati di release verificati su Prime Agent v0.7.0 e fonti ufficiali il 6 agosto 2026. I benchmark sono risultati dichiarati da Prime Intellect al lancio e vanno trattati come tali fino a una replica indipendente.

Fonti e crediti immagini: post di lancio di Prime Agent e relativi diagrammi, screenshot e grafici ufficiali; sorgente e documentazione di Prime Agent alla v0.7.0; note della release v0.7.0; sorgente di Pi; Recursive Language Models; Continual Harness; ARC-AGI-3. Gli asset visuali ufficiali di Prime Intellect sono riprodotti per commento e analisi con attribuzione.