Show HN agent tooling roundup: runtime, registry, scanner and inbox projects

Most enterprise agent talk in late September focuses on governance dashboards and control planes. The underlying tooling is arriving through quieter channels: Show HN posts.

Four projects appeared there that together sketch out what a self-hosted agent stack looks like when assembled from parts rather than bought as a platform. None is a product launch in the usual sense. They are repositories, single binaries and documentation sites, published with source available and, in most cases, an explicit promise that interesting features are not held back for a paid tier.

A runtime that wants to be the floor, not the ceiling

Soma, posted to Show HN on 2 December, describes itself in its documentation as an open-source, self-hostable AI agent and workflow runtime aimed at everyone from startups to enterprise. The pitch is deliberately unglamorous: define agents and MCP functions in ordinary code, bring whatever framework you already use, and let Soma handle fault tolerance, resumability and the plumbing around them.

The documentation lists a single binary, automatic A2A (Agent2Agent) endpoints with OpenAI Streaming compatibility marked as coming soon, an MCP server pre-integrated with third-party SaaS providers that handles credential encryption and rotation, a UI for debugging agents and MCP functions, fine-grained API key management, an outbound AI gateway that intercepts requests to model providers, and secrets management through local, AWS or planned GCP KMS. Typescript support ships today; Python is listed as coming soon, and Rust as not yet available.

The platform table in the docs marks macOS, Linux GNU builds for x86 and ARM as available for Typescript and Python, with Windows unsupported. The documentation attributes the Windows gap to the project's use of Unix domain sockets in Rust, and links to a related issue rather than promising a date.

The docs frame Soma as "the bottom of the pyramid", providing core building blocks and a developer experience, while leaving agent logic to whatever framework the team already uses.

That positioning matters for enterprise buyers. A runtime that explicitly refuses to own the framework layer is easier to slot under an existing evaluation than a platform that asks for a rewrite. It also means the vendor question shifts from "which agent framework" to "who operates the runtime", which is a smaller commitment.

An artifact registry that treats agents as another package format

Artifact Keeper, posted on 6 February, is not an agent framework at all. It is a self-hosted artifact registry pitched as a drop-in replacement for JFrog Artifactory and Sonatype Nexus, and its README is unusually direct about the commercial model: no open-core, no enterprise edition, no surprise invoices.

The repository table lists a Rust, Axum, SQLx, PostgreSQL and Wasmtime backend with 45+ format handlers, a Next.js 15 web dashboard, SwiftUI iOS and macOS apps, a Jetpack Compose Android app, a planned Rust CLI, Helm and Terraform infrastructure modules, an OpenAPI 3.1 spec with 277 operations, and an example WASM plugin template built for the Unity .unitypackage format. For teams running agent pipelines, the relevant pieces are proxy and virtual repositories, which cache artifacts from npmjs.com, PyPI, Maven Central and Docker Hub on first request and resolve private packages before public ones, plus Trivy vulnerability detection, OWASP Dependency-Track SBOM analysis, OpenSCAP compliance auditing, GPG and PGP signing with key management, and a policy engine with quality gates, severity thresholds and scan-before-download enforcement.

Peer replication uses a mesh model with label-based sync policies, reactive subscriptions and P2P transfers between peers, which the README suggests for putting caches close to build agents. Authentication covers OpenID Connect, LDAP, SAML 2.0, JWT and API tokens, with RBAC per repository. Observability includes Prometheus metrics described as 30+ ak_* gauges, counters and histograms, opt-in OpenTelemetry tracing with OTLP export to Jaeger, Tempo or Datadog, and Kubernetes health probes at /livez, /readyz and /healthz.

The quick start is three commands: clone the repository, change directory, run docker compose up -d, then visit localhost:9080. Production deployment points to a separate infrastructure repository with a Helm chart, Terraform modules for EKS, RDS and S3, ArgoCD GitOps and a monitoring stack. Migration tooling from JFrog Artifactory is built in and described as a one-command operation covering repositories, artifacts, users and permissions.

Whether a registry belongs in an agent stack is a fair question. The README's answer is implicit: agents produce and consume packages, container images and signed artifacts, and the same supply-chain controls that apply to human-written code apply to them.

A scanner for the MCP servers already on your machine

Golf Scanner, posted on 8 March, addresses a problem that most enterprise inventories do not yet cover. It is a free, open-source CLI, written in pure Go with three dependencies, that discovers MCP server configurations across a machine and runs security checks against them. It ships as a single static binary, with zero telemetry and no account required.

The discovery list names seven IDEs: Claude Code, Cursor, VS Code, Windsurf, Gemini CLI, Kiro and Antigravity. The scanner runs 20 security checks, split into nine offline and eleven online, where the online checks query OSV, GitHub, npm, PyPI, OCI registries and the MCP Registry. Each server gets a 0 to 100 risk score using severity-weighted scoring with hard caps.

The checks are concrete. Command safety looks for privilege escalation and shell injection patterns. Credentials checks find plaintext secrets in arguments, URLs and environment variables. Script location flags scripts running from /tmp or home directories, and script permissions detect world-writable files. Container isolation flags --privileged mode, dangerous capabilities and host namespace sharing, while container volumes flag mounts of the root filesystem, /etc or the Docker socket. Registry listing confirms MCP Registry inclusion. Vulnerabilities query OSV.dev for known CVEs and malware in npm and PyPI packages. Typosquatting identifies similarly named packages, distribution evaluates download metrics and package age, and GitHub trust weighs repository activity, licensing and contributor count.

Scoring is documented in detail: each check produces findings, the worst severity sets the per-check score from 0 to 10, and scores combine through a severity-weighted average with critical at 10x, high at 7.5x, medium at 5x and note at 1x. Hard caps apply. Any critical finding caps the total at 30; any high finding caps it at 59.

The CLI takes flags including --offline, --format table or json, --json as shorthand, --fail-on with thresholds from note through critical, --verbose and --quiet. Exit codes are 0 for success, 1 for no arguments, unknown commands, a --fail-on threshold breach or a flag conflict, and 2 for JSON errors or an invalid --fail-on value. A GITHUB_TOKEN environment variable is optional and raises the GitHub API rate limit from 60 to 5,000 requests per hour.

An inbox for work that outlives the conversation

Pizza Bot, posted on 15 September, takes the opposite approach to the same problem. Rather than governing agents, it gives them somewhere to report. The GitHub description calls it a local-first inbox for long-running AI agents, built with DeepAgents and LangGraph, and the README states it was developed at Amazon and released under the Apache 2.0 license.

The README's framing is a queue, not a chat. Start or schedule a task, walk away, and come back to finished work in Unread and decisions waiting in Action. Agents keep working when you navigate away or disconnect, and only the api-server process must stay running. A stateful DeepAgents and LangGraph runtime serves the same React experience in Electron and the browser, and the desktop app, web app and terminal CLI all talk to the api-server over HTTP and SSE.

Checkpointed runs survive client disconnects, and cron or webhook triggers can start work without an open conversation. Skills become tool-scoped subagents whose progress appears in an Activity panel. Model providers include Amazon Bedrock, Anthropic, Google Gemini, OpenAI, OpenRouter and Ollama. Human-in-the-loop approvals, long-term memory, file attachments and desktop notifications are described as built into the workflow.

On access, the README is specific. The api-server binds to 127.0.0.1, and non-loopback binding requires authentication and an explicit setting. Folders must be granted individually as read-only or writable under Settings, and the project states it receives no default home-directory access. Desktop installers are attached to every release with a SHA256SUMS file; macOS builds are signed and notarized, Windows x64 ships a setup executable, and Linux x64 and arm64 builds for .deb and .rpm are unsigned and must be verified against the checksum file.

Taken together, the four projects do not form a stack. They overlap on runtimes, and only Artifact Keeper and Golf Scanner speak directly to the compliance concerns that dominate enterprise agent headlines. But they show where the floor is being set: local-first defaults, explicit file permissions, signed releases, documented scoring and open licences. That is a different sales pitch from a control plane, and for some teams it will be an easier one to approve.