Show HN: panoramica degli strumenti per agenti, runtime, registro, scanner e inbox

A fine settembre, i discorsi aziendali sugli agenti si concentrano su dashboard di governance e piani di controllo. Gli strumenti sottostanti arrivano invece attraverso canali più silenziosi: i post su Show HN.

Quattro progetti pubblicati lì delineano insieme come appare uno stack di agenti self-hosted assemblato da componenti separati, anziché acquistato come piattaforma. Nessuno di essi è un lancio di prodotto nel senso usuale. Sono repository, binari singoli e siti di documentazione, pubblicati con sorgente disponibile e, nella maggior parte dei casi, con la promessa esplicita che le funzionalità principali non siano riservate a un livello a pagamento.

Un runtime che vuole essere il pavimento, non il soffitto

Soma, pubblicato su Show HN il 2 dicembre, si descrive nella documentazione come un runtime open source e self-hostable per agenti AI e flussi di lavoro, destinato a tutti, dalle startup alle aziende. La proposta è volutamente poco glamour: definire agenti e funzioni MCP in codice ordinario, portare il framework già in uso e lasciare a Soma la gestione della tolleranza ai guasti, della riprendibilità e dell'infrastruttura circostante.

La documentazione elenca un singolo binario, endpoint A2A (Agent2Agent) automatici con compatibilità OpenAI Streaming indicata come imminente, un server MCP pre-integrato con provider SaaS di terze parti che gestisce crittografia e rotazione delle credenziali, un'interfaccia per il debug di agenti e funzioni MCP, una gestione granulare delle chiavi API, un gateway AI in uscita che intercetta le richieste ai provider di modelli e la gestione dei segreti tramite KMS locale, AWS o GCP pianificato. Il supporto per TypeScript è disponibile oggi; Python è elencato come imminente, mentre Rust non è ancora disponibile.

La tabella delle piattaforme indica macOS e Linux GNU per x86 e ARM come disponibili per TypeScript e Python, con Windows non supportato. La documentazione attribuisce la mancanza di supporto per Windows all'uso di socket di dominio Unix in Rust e linka a un issue correlato, senza promettere una data.

La documentazione presenta Soma come "il fondo della piramide", fornendo blocchi di costruzione fondamentali e un'esperienza di sviluppo, lasciando la logica degli agenti al framework che il team utilizza già.

Questa posizione conta per gli acquirenti aziendali. Un runtime che rifiuta esplicitamente di possedere il livello del framework è più facile da inserire sotto una valutazione esistente rispetto a una piattaforma che chiede una riscrittura. Inoltre, la domanda sul vendor passa da "quale framework per agenti" a "chi opera il runtime", un impegno più piccolo.

Un registro di artefatti che tratta gli agenti come un altro formato di pacchetto

Artifact Keeper, pubblicato il 6 febbraio, non è un framework per agenti. È un registro di artefatti self-hosted presentato come sostituto drop-in per JFrog Artifactory e Sonatype Nexus. Il README è insolitamente diretto sul modello commerciale: nessun open-core, nessuna edizione enterprise, nessuna fattura a sorpresa.

La tabella dei repository elenca un backend Rust, Axum, SQLx, PostgreSQL e Wasmtime con oltre 45 gestori di formato, un dashboard web Next.js 15, app iOS e macOS SwiftUI, un'app Android Jetpack Compose, un CLI Rust pianificato, moduli infrastrutturali Helm e Terraform, una specifica OpenAPI 3.1 con 277 operazioni e un modello di plugin WASM di esempio per il formato .unitypackage di Unity. Per i team che eseguono pipeline di agenti, le parti rilevanti sono i repository proxy e virtuali, che mettono in cache artefatti da npmjs.com, PyPI, Maven Central e Docker Hub alla prima richiesta e risolvono i pacchetti privati prima di quelli pubblici. Sono inclusi la rilevazione delle vulnerabilità Trivy, l'analisi SBOM OWASP Dependency-Track, l'audit di conformità OpenSCAP, la firma GPG e PGP con gestione delle chiavi e un motore di policy con gate di qualità, soglie di gravità e applicazione dello scan prima del download.

La replica tra pari utilizza un modello mesh con policy di sincronizzazione basate su etichette, sottoscrizioni reattive e trasferimenti P2P tra pari, suggeriti dal README per mettere le cache vicino agli agenti di build. L'autenticazione copre OpenID Connect, LDAP, SAML 2.0, JWT e token API, con RBAC per repository. L'osservabilità include metriche Prometheus (oltre 30 gauge ak_*, contatori e istogrammi), tracciamento OpenTelemetry opzionale con esportazione OTLP a Jaeger, Tempo o Datadog, e sonde di salute Kubernetes su /livez, /readyz e /healthz.

La rapida partenza richiede tre comandi: clonare il repository, cambiare directory, eseguire docker compose up -d, quindi visitare localhost:9080. Il deployment di produzione punta a un repository infrastrutturale separato con un chart Helm, moduli Terraform per EKS, RDS e S3, ArgoCD GitOps e uno stack di monitoraggio. Gli strumenti di migrazione da JFrog Artifactory sono integrati e descritti come un'operazione a un comando che copre repository, artefatti, utenti e permessi.

Se un registro appartenga a uno stack di agenti è una domanda legittima. La risposta del README è implicita: gli agenti producono e consumano pacchetti, immagini container e artefatti firmati, e gli stessi controlli della catena di approvvigionamento applicabili al codice scritto dall'uomo si applicano a loro.

Uno scanner per i server MCP già sulla tua macchina

Golf Scanner, pubblicato l'8 marzo, affronta un problema che la maggior parte degli inventari aziendali non copre ancora. È un CLI gratuito e open source, scritto in Go puro con tre dipendenze, che scopre le configurazioni dei server MCP su una macchina ed esegue controlli di sicurezza. Viene fornito come un singolo binario statico, con telemetria zero e nessun account richiesto.

L'elenco di scoperta cita sette IDE: Claude Code, Cursor, VS Code, Windsurf, Gemini CLI, Kiro e Antigravity. Lo scanner esegue 20 controlli di sicurezza, divisi in nove offline e undici online. I controlli online interrogano OSV, GitHub, npm, PyPI, i registri OCI e il MCP Registry. Ogni server riceve un punteggio di rischio da 0 a 100 usando un punteggio ponderato per gravità con limiti rigidi.

I controlli sono concreti. La sicurezza dei comandi cerca modelli di escalata dei privilegi e iniezione di shell. I controlli delle credenziali trovano segreti in testo chiaro negli argomenti, URL e variabili di ambiente. La posizione degli script segnala script che si eseguono da /tmp o directory home, e i permessi degli script rilevano file scrivibili da tutti. L'isolamento del container segnala la modalità --privileged, capacità pericolose e condivisione dello spazio dei nomi host, mentre i volumi del container segnalano il montaggio del filesystem radice, /etc o il socket Docker. L'elenco del registro conferma l'inclusione nel MCP Registry. Le vulnerabilità interrogano OSV.dev per CVE note e malware nei pacchetti npm e PyPI. Il typosquatting identifica pacchetti con nomi simili, la distribuzione valuta le metriche di download e l'età del pacchetto, e la fiducia GitHub pondera l'attività del repository, la licenza e il numero di contributori.

Il punteggio è documentato in dettaglio: ogni controllo produce riscontri, la gravità peggiore imposta il punteggio per controllo da 0 a 10, e i punteggi si combinano attraverso una media ponderata per gravità con critico a 10x, alto a 7.5x, medio a 5x e nota a 1x. Si applicano limiti rigidi. Qualsiasi riscontro critico limita il totale a 30; qualsiasi riscontro alto lo limita a 59.

Il CLI accetta flag inclusi --offline, --format table o json, --json come abbreviazione, --fail-on con soglie da nota a critico, --verbose e --quiet. I codici di uscita sono 0 per successo, 1 per assenza di argomenti, comandi sconosciuti, violazione di una soglia --fail-on o conflitto di flag, e 2 per errori JSON o valore --fail-on non valido. Una variabile d'ambiente GITHUB_TOKEN è opzionale e alza il limite di velocità dell'API GitHub da 60 a 5.000 richieste all'ora.

Una inbox per il lavoro che sopravvive alla conversazione

Pizza Bot, pubblicato il 15 settembre, adotta l'approccio opposto allo stesso problema. Invece di governare gli agenti, dà loro un posto dove riferire. La descrizione su GitHub lo chiama una inbox local-first per agenti AI a lunga esecuzione, costruita con DeepAgents e LangGraph. Il README afferma che è stato sviluppato presso Amazon e rilasciato sotto la licenza Apache 2.0.

La cornice del README è una coda, non una chat. Avviare o pianificare un compito, allontanarsi, e tornare al lavoro finito in Non letti e alle decisioni in attesa in Azione. Gli agenti continuano a lavorare quando ci si allontana o ci si disconnette, e solo il processo api-server deve restare in esecuzione. Un runtime stateful di DeepAgents e LangGraph serve la stessa esperienza React in Electron e nel browser, e l'app desktop, l'app web e il CLI terminale comunicano tutti con l'api-server tramite HTTP e SSE.

Esecuzioni con checkpoint sopravvivono alle disconnessioni del client, e trigger cron o webhook possono avviare il lavoro senza una conversazione aperta. Le abilità diventano sotto-agenti con ambito degli strumenti il cui progresso appare in un pannello Attività. I provider di modelli includono Amazon Bedrock, Anthropic, Google Gemini, OpenAI, OpenRouter e Ollama. Le approvazioni human-in-the-loop, la memoria a lungo termine, gli allegati file e le notifiche desktop sono descritti come integrati nel flusso di lavoro.

Sull'accesso, il README è specifico. L'api-server si lega a 127.0.0.1, e la legatura non-loopback richiede autenticazione e un'impostazione esplicita. Le cartelle devono essere concesse individualmente come solo lettura o scrivibile sotto Impostazioni, e il progetto afferma di non ricevere accesso predefinito alla directory home. I programmatori di installazione desktop sono allegati a ogni release con un file SHA256SUMS; le build macOS sono firmate e notarizzate, Windows x64 fornisce un eseguibile di configurazione, e le build Linux x64 e arm64 per .deb e .rpm sono non firmate e devono essere verificate contro il file di controllo.

Considerati insieme, i quattro progetti non formano uno stack. Si sovrappongono sui runtime, e solo Artifact Keeper e Golf Scanner parlano direttamente delle preoccupazioni di conformità che dominano le notizie sugli agenti aziendali. Ma mostrano dove viene posto il pavimento: predefiniti local-first, permessi file espliciti, release firmate, punteggio documentato e licenze aperte. È una proposta di vendita diversa da un piano di controllo, e per alcuni team sarà una più facile da approvare.