Gli agenti sempre attivi devono sorvegliare e gestire gli eventi in modo continuo, da molte più fonti di quante ne possano tenere sott’occhio nella loro finestra di contesto. Salix, l’harness distribuito di Comma, dà agli agenti la possibilità di caricare nel cluster piccoli programmi eBPF e di farli girare in modo persistente, 24/7, per monitorare gli eventi, chiamare Jev per decisioni intelligenti e rapide, e svegliare il loop principale dell’agente quando succede qualcosa di interessante.
Il loop interno non basta
Il loop dell’agente che tutti conosciamo è semplice: invia il contesto a un modello, esegui le chiamate agli strumenti che restituisce, aggiungi i risultati, ripeti. Quel loop è bravo a lavorare. È pessimo ad aspettare il lavoro.
Chiedi a un agente «avvisami quando il contratto torna firmato» o «sorveglia questo repo e segnala tutto ciò che tocca la fatturazione», e il loop interno ha due cattive opzioni. Può fare polling: svegliarsi ogni pochi minuti, rileggere la casella di posta e spendere un’intera chiamata al modello per concludere che non è successo nulla. Oppure può affidare il compito a un heartbeat o a una pianificazione cron, che è lo stesso polling con un intervallo più lungo e una latenza peggiore. In entrambi i casi, la parte costosa del sistema, un modello grande che legge un contesto grande, gira a ogni tick, e quasi ogni tick è tranquillo.
Ciò di cui un agente sempre attivo ha davvero bisogno è un loop esterno: qualcosa che stia sul flusso di eventi, faccia il filtraggio economico e passi la palla al modello solo quando c’è qualcosa su cui valga la pena ragionare. E poiché ogni agente sorveglia cose diverse in modi diversi, quel loop esterno non può essere una funzionalità fissa del prodotto. Deve scriverlo l’agente.
In Salix, quel loop esterno si chiama Loop.
Un Loop è un piccolo programma in C
Un Loop è un singolo file C, scritto dall’agente, compilato in eBPF ed eseguito sul cluster accanto all’agente che lo possiede. Ogni Loop ha la stessa forma:
Aspetta un timer o un evento, controlla qualcosa e, di rado, sveglia l’agente. L’agente riceve l’header esatto dell’SDK e una guida alla programmazione da uno strumento loop.sdk, scrive il programma, lo compila con loop.build e lo avvia con loop.create. Non ci sono template né DSL. Se l’agente sa descrivere la sorveglianza in C, può eseguirla.
Perché C ed eBPF, e non, per esempio, uno script Python in un container? Per via dei numeri attorno a cui abbiamo progettato Salix. Salix esegue milioni di agenti, a più di 100 agenti per core di CPU. Un agente non può avere una sandbox sempre accesa, e quindi nemmeno le sue sorveglianze. Un Loop deve costare abbastanza poco da poter girare per sempre, per ogni agente, su un nodo condiviso e multi-tenant, eseguendo codice che nessun essere umano ha revisionato.
eBPF risponde a questi requisiti insolitamente bene:
È piccolo. Un Loop in attesa occupa decine di kilobyte di memoria residente. Non c’è processo, né interprete, né heap.
Si può eseguire in sicurezza anche se non è affidabile. Il target non ha syscall, puntatori a funzione né stack illimitato. Un programma può solo fare calcoli sulla propria memoria e chiamare le funzioni host che gli forniamo.
Aspettare costa poco. Un Loop bloccato in
sf_event_nextosf_sleep_msnon costa nulla oltre alla sua memoria.
Il prezzo è un dialetto ristretto, e la guida dell’SDK lo dice senza giri di parole: solo C intero (niente virgola mobile, niente divisione con segno), stack frame da 4 KiB, al massimo 8 frame di profondità, niente ricorsione, niente sprintf e al massimo 128 handle attivi. Ai modelli questo va benissimo. Conoscono già il C, e i vincoli sono del tipo che un errore del compilatore spiega bene.
Spinfoam: il runtime sotto ogni Loop
I Loop girano su spinfoam, il nostro runtime eBPF per i loop. Spinfoam è costruito su async-ebpf, un runtime eBPF in userspace pensato per l’asincronia, completamente preemptive e con una sicurezza della memoria verificata formalmente nel suo nucleo.
eBPF in userspace, reso asincrono
Spinfoam non è eBPF del kernel. È un normale processo Rust, uno per nodo Salix, che non richiede supporto eBPF nel kernel né privilegi, e funziona allo stesso modo su Linux e macOS. Salix comunica con il processo via JSON-RPC su stdin e stdout. La divisione delle responsabilità è rigida: spinfoam gestisce l’esecuzione locale, l’isolamento tra i programmi, la cancellazione e la consegna limitata dei messaggi. Salix gestisce tutto ciò che deve sopravvivere a un crash: posizionamento, stato durevole, policy di riavvio, credenziali e rete.
È l’«async» di async-ebpf che fa sembrare un Loop normale C sequenziale. Ogni programma caricato riceve un’unica invocazione di lunga durata, che gira sulla propria coroutine. Quando il programma chiama sf_sleep_ms, sf_event_next o sf_host_call, l’helper sospende la coroutine e passa l’attesa a Tokio. Lo stack C e le variabili globali del programma restano esattamente dov’erano. Quando scatta il timer, arriva l’evento o Salix risponde alla chiamata host, la coroutine riprende dalla riga successiva. L’agente scrive for (;;) { wait; check; wake; } e non vede mai una callback.
«Completamente preemptive» è ciò che rende sicura la condivisione. Tutto il codice guest gira su un unico thread Tokio, e un thread di sorveglianza interrompe qualsiasi programma che giri troppo a lungo senza cedere il controllo. Un Loop che gira a vuoto in un for (;;) {} stretto perde il suo slot di tempo come qualsiasi altro, e per fermarlo non serve la sua collaborazione. Un Loop difettoso non può bloccare i suoi vicini.
La maggior parte dei Loop passa quasi tutto il tempo ad aspettare, quindi questo design permette una densità elevata. Nel nostro test di qualifica, 10.000 piccoli Loop di monitoraggio, tutti compilati dal compilatore integrato, sono girati su un solo thread di esecuzione con circa 64 KB di memoria residente ciascuno. Caricare e avviare tutti i 10.000 Loop ha richiesto 3,07 secondi. Consegnare un evento a ogni Loop, e rispondere alla chiamata host che ognuno ha fatto in risposta, ha richiesto 1,56 secondi. Le richieste di controllo sono rimaste sotto un quarto di millisecondo al p99. L’intero processo ha usato quattro thread del sistema operativo durante il caricamento e due a riposo.
Una sicurezza della memoria che puoi verificare
Eseguire migliaia di programmi scritti da agenti in un solo processo è ragionevole solo se nessuno di loro può toccare memoria che non gli appartiene. In async-ebpf, questa garanzia parte dal layout della memoria e finisce con dimostrazioni verificate da una macchina.
Prima il layout. I dati di ogni programma stanno dentro una gabbia di puntatori: una regione riservata circondata da pagine di guardia casuali. Lo stack del guest è organizzato in isole di un frame ciascuna, separate da spazi inaccessibili più ampi di quanto possa raggiungere qualsiasi istruzione di memoria eBPF, così una funzione che esce dal proprio frame va in errore invece di leggere quello del chiamante. Le pagine di codice JIT non sono mai scrivibili ed eseguibili allo stesso tempo.
Poi le dimostrazioni. async-ebpf compila ogni funzione eBPF in codice nativo la prima volta che viene eseguita. Il suo backend x86_64 è strutturato in modo che la parte che prende le decisioni si possa dimostrare:
Il validatore è corretto. In ogni esecuzione di un programma che accetta, il programma non raggiunge mai un’istruzione non definita, non salta mai a metà di un’istruzione o fuori dal programma, e il frame pointer è sempre la base del frame per la profondità di chiamata corrente.
Le funzioni sono chiuse. Il controllo non esce mai da una funzione se non tramite una chiamata locale o un return, ed è questo che permette al JIT di compilare una funzione alla volta.
Il codice generato è sicuro per la memoria. Se il checker accetta una funzione, ogni esecuzione del suo codice nativo tocca solo un insieme consentito di indirizzi (il suo frame, le sue regioni guest, il suo stack e il suo literal pool) e ritorna con lo stato del chiamante intatto. Le funzioni chiamate compilate in modo lazy si compongono con lo stesso teorema.
I byte dicono ciò che dice il modello. Ogni istruzione emessa dall’assembler si decodifica nell’istruzione su cui il modello ha ragionato.
Le dimostrazioni si collegano all’hardware in due punti. Si dimostra che un simulatore eseguibile è un’esecuzione del modello di macchina in Lean, e un test differenziale fa passare ventimila sequenze casuali di istruzioni sia nel simulatore sia nel processore reale. Prima di ogni invocazione, il runtime confronta il layout concreto della memoria con l’ipotesi del teorema, e si rifiuta di eseguire se non è soddisfatta.
Diciamo chiaramente cosa non è dimostrato. La base fidata include la semantica delle istruzioni x86 (testata sull’hardware, non dimostrata), i trampolini di ingresso, il gestore degli errori, le mappature di memoria, il lato host di ogni chiamata helper, e Charon e Aeneas stessi. Il teorema riguarda la sicurezza della memoria, non la correttezza funzionale né le fughe di informazioni. E copre solo il backend x86_64; il backend arm64 è testato ma non dimostrato.
Le dimostrazioni tengono il guest nella propria memoria. Tutto ciò che un Loop fa nel mondo esterno passa per una chiamata host, e quel confine appartiene a Salix: l’allowlist delle capacità e le regole di autorità descritte più avanti.
Anche il compilatore gira nella sandbox
Gli agenti compilano i propri Loop, quindi anche il compilatore riceve input non affidabile. Spinfoam integra TinyCC, compilato in eBPF, e lo esegue su async-ebpf come qualsiasi altro guest. Ogni build riceve una nuova istanza del compilatore con un’arena da 8 MiB, un file system solo in memoria che contiene esclusivamente i sorgenti inviati e l’header dell’SDK, una scadenza di 15 secondi e nessun accesso a rete, processi o file dell’host. Anche l’output è trattato come non affidabile. Ogni oggetto passa per la stessa validazione al caricamento, che venga dal compilatore o no.
Per questo loop.build non richiede toolchain, container né privilegi sul nodo. Il sorgente C dell’agente non tocca mai un compilatore nativo.
Svegliare l’agente è la parte costosa
Un Loop gira da solo, ma è inutile se non può dire nulla all’agente. L’unico modo per farlo è agent.notify:
La notifica viene consegnata alla Session di destinazione del Loop come un normale messaggio. Solo allora gira il loop principale dell’agente, e solo allora spende token di modello. Un’ora tranquilla non costa alcun token.
La dedup_key conta più di quanto sembri. I Loop vengono riavviati, gli eventi vengono riconsegnati, e un guest può ripetere una chiamata di cui non è sicuro che sia riuscita. Salix consegna il risveglio come loop:<id>:<dedup_key>, così la stessa email, issue o alert sveglia l’agente una sola volta.
Poiché il risveglio è la parte costosa, ha anche un budget. Un Loop può svegliare il suo agente sei volte ogni dieci minuti. Un Loop che resta a quel limite per un’ora viene messo in pausa con motivo budget, e l’agente viene avvisato. Un Loop difettoso o troppo zelante si riduce a un Loop in pausa e visibile, non a una bolletta.
Decisioni rapide senza un modello grande
La parte difficile di una sorveglianza di solito non è «è cambiato qualcosa», ma «questo cambiamento conta?». Questa email richiede un intervento del proprietario oggi? Questa PR tocca le parti del sistema che ci interessano? Un Loop scritto in C intero non può rispondere da solo, e chiamare un modello di frontiera a ogni evento ci riporterebbe esattamente al punto di partenza.
Così i Loop ricevono un’altra capacità: decide. Invia una piccola domanda tipizzata a un modello decisionale veloce (Jev) e riceve una risposta strutturata. Ecco la domanda del nostro prototipo di sorveglianza delle email:
decide supporta choice per scegliere un candidato, domande sì/no separate per più corrispondenze e score per una pertinenza ordinata. Restituisce sempre e solo una decisione. Non legge fonti, non esegue strumenti e non concede autorità. Il Loop fornisce i dati, pone la domanda e applica la soglia nel proprio codice.
Due scelte di design l’hanno fatto funzionare bene:
L’incertezza è una risposta valida. Una scelta esplicita
noneodefersignifica «non so dirlo», ed è un risultato riuscito, non un errore di trasporto. Il Loop conserva l’evento invece di inventarsi una decisione tranquilla.Costa abbastanza poco da girare su ogni evento. Il nostro listino prezzi indica
typesafe/jev-1.13.0a $0.042 per milione di token di input, con token di output gratuiti. Abbastanza poco da filtrare ogni email, non solo quelle che passano un filtro per parole chiave.
Il risultato è un sistema a due livelli: un modello piccolo filtra ogni evento, e il modello grande vede solo quelli che superano il filtro.
Eventi in ingresso, in modo durevole
I timer bastano per il polling, ma molte fonti possono inviare eventi da sole. Un Loop ha una mailbox, e i sistemi esterni la alimentano in tre modi:
l’API di Salix:
POST /v1/agent-groups/:group_id/loops/:loop_id/eventscon una chiave API del gruppo;un URL webhook segreto, che l’agente attiva, ruota o revoca con
loop.webhook;i trigger Composio dalle app collegate dell’utente, che arrivano con l’ID evento del provider e lo slug del trigger.
Un 202 da una qualsiasi di queste fonti significa che PostgreSQL ha conservato l’evento sul suo Loop. Non significa che il Loop l’abbia elaborato. Il guest chiama loop.ack quando ha raggiunto un punto sicuro: una decisione tranquilla, o un passaggio di consegne durevole come un agent.notify riuscito. Fino ad allora l’evento resta in sospeso, e il Reconciler riproduce gli eventi in sospeso dopo che il Loop si sposta o si riavvia, e comunque una volta al minuto. Un evento non confermato entro 15 minuti fa fallire il Loop in modo visibile, e gli eventi in sospeso restano disponibili perché l’agente li riprovi o li scarti.
Una lezione imparata costruendolo: la mailbox di spinfoam deduplica gli ID degli eventi all’ammissione, non al completamento del lavoro. In un primo prototipo ci aspettavamo che una chiamata al modello fallita venisse ripetuta grazie alla riconsegna dell’evento da parte del provider. Non è successo; la riconsegna è stata correttamente scartata come duplicato. Quindi i tentativi spettano al guest, che conserva l’evento e riprova un numero limitato di volte, e il ripristino dopo un crash spetta all’inbox durevole. Ora scriviamo questa regola nella guida dell’SDK.
La conferma, l’ammissione durevole nella Session, un messaggio visibile e un effetto esterno sono quattro fatti distinti. Diamo a ciascuno il proprio responsabile, richiediamo chiavi di deduplica stabili a valle e non promettiamo effetti esterni exactly-once.
Girare per sempre su un cluster in movimento
«24/7» è facile da dire e difficile da fare su un cluster in cui i nodi vanno e vengono. Un Loop gira sul nodo che detiene il lease del suo agente, e segue quel lease.
Posizionamento. Quando il processo server di un agente acquisisce il suo lease, adotta i suoi Loop attivi. Quando l’agente viene passivato o isolato, li rilascia. Un Loop attivo tiene residente il suo agente, quindi un agente inattivo con un Loop rinnova il suo lease invece di parcheggiarsi.
Incarnazioni. Ogni caricamento di un Loop incrementa la sua incarnazione, un valore di fencing sulla riga del Loop. Una chiamata host da un oggetto che non è l’incarnazione corrente viene rifiutata, e lo stesso vale per un
ack. Una copia obsoleta di un Loop su un nodo in uscita non può agire.Checkpoint.
loop.state.putsalva fino a 16 KiB, e il caricamento successivo lo riceve comeconfig.state. Gli agenti salvano nel checkpoint cursori e ultimi ID visti, non tutto.Errori. Un errore ricarica il Loop dal suo checkpoint, al massimo tre volte all’ora. Dopodiché passa allo stato
failed, e l’agente viene avvisato una volta.Loop orfani. Una scansione periodica trova i Loop attivi senza alcun oggetto collegato, o collegati su un nodo che ha lasciato il cluster, e ne riavvia il proprietario.
I Loop hanno anche una fonte di verità fuori dal runtime. loop.build scrive l’ELF compilato nel file system dell’agente, e loop.create ne registra il percorso e lo SHA-256. Ogni caricamento rilegge il file e verifica l’hash, così un Loop esegue esattamente il programma con cui è stato creato, oppure niente.
Cosa può fare un Loop
Un Loop è codice scritto da un modello, che gira senza supervisione, giorno e notte. La sua autorità deve essere inferiore a quella dell’agente, non uguale.
I Loop chiamano un’allowlist chiusa di capacità host: agent.notify, le chiamate loop.state.*, loop.ack e loop.log, gli strumenti Salix classificati come di sola lettura, gli strumenti per ambiente e dispositivi, gli strumenti SSH, la lettura di una conversazione, web.http_request, composio.execute per le app collegate e decide. Spinfoam rifiuta qualsiasi altro nome con SF_DENIED. Non c’è alcun passaggio di concessione da sbagliare.
Ogni chiamata passa per lo stesso dispatch degli strumenti e gli stessi controlli sul flusso di informazioni di un normale turno dell’agente. Un Loop agisce come il suo creatore, tramite un principal delegato schedule|loop:<id>|<creator>, con le regole di divulgazione del creatore e l’origine sigillata del Loop. I payload degli eventi sono dati. Non portano autorità e non possono ampliare ciò che il Loop può fare, ed è per questo che il prompt di decisione qui sopra tratta esplicitamente l’email come input non affidabile.
Infine, le quote mantengono il sistema entro limiti precisi: 20 Loop attivi per agente, 100 per gruppo, 32 eventi in sospeso da 16 KiB ciascuno per Loop e limiti di frequenza sull’ingresso dei webhook.
Script: lo stesso runtime, per un solo turno
Una volta ottenuto un runtime sicuro ed economico per il C scritto dagli agenti, è emerso un secondo uso. script.run compila ed esegue una volta un programma in C intero, dentro una singola chiamata a uno strumento, con accesso agli strumenti del turno chiamante tramite salix.call. Uno script non ha riga, incarnazione, checkpoint né agent.notify. È un modo per un agente di raggruppare molte chiamate agli strumenti in un unico programma deterministico, invece di tanti round trip con il modello. Due delle skill che distribuiamo sono programmi C eseguiti in questo modo.
Agenti che programmano il proprio sistema di eventi
Mettendo tutto insieme, un agente Comma a cui si chiede di restare di guardia fa tre cose che gli agenti tradizionali non sanno fare: scrive la sorveglianza come programma, il cluster esegue quel programma per tutto il tempo necessario al costo di pochi kilobyte, e un modello piccolo decide, evento per evento, se il modello grande debba svegliarsi.
Il loop interno resta il luogo in cui l’agente pensa. Il loop esterno è quello in cui presta attenzione. Salix permette all’agente di costruirli entrambi.