Agentreg: DNS for AI agents, self-hosted in one Go binary

Core Brim Tech has launched agentreg, a self-hosted registry designed to solve the operational friction that emerges when running multiple AI agents alongside each other. The problem it addresses is simple but acute: once you have more than a couple of MCP servers, you end up hardcoding endpoints in configuration files, discovering that an agent is down only when something breaks, and trusting every endpoint blindly. agentreg changes this by providing a centralized place where agents register themselves, advertise their capabilities, and are continuously health-checked.

The tool works in three steps. First, you run the agentreg daemon locally (`agentctl serve`). Second, you register each agent with its capabilities and endpoint—for example, `agentctl register search-agent -c search -e http://localhost:3000`. Third, when an agent needs to find a peer, it queries by capability: `agentctl find search` returns all agents that offer search functionality, regardless of where they live. The daemon runs health-check probes on a configurable interval (default 15 seconds), so unhealthy agents show up in the list with an "unhealthy" status before they cause downstream failures. The HTTP API supports registration via POST to `/agents`, discovery via GET to `/agents/find?capability=X`, and agent self-reporting via heartbeat.

The implementation is minimal by design. agentreg ships as a single static Go binary with no cloud dependency, no account required, and no cluster to manage. Configuration includes listening port (default 8080), persistence file location, heartbeat interval, and per-agent probe timeout. It scales from 3 agents running on a laptop to 30+ in production, and the in-memory store plus atomic JSON persistence ensures data survives restarts without requiring external databases. The architecture includes two extensibility seams: a `Source` field on every record (today set to "local"; future versions will support federation sources like `peer:<id>` or `from:ans`) and a pluggable Verifier interface (v1 ships with a health probe; future versions will add ANS identity verification, tools/list validation, and prompt-injection checking).

The roadmap is staged: v0.1, available now, covers the core loop of register, list, find, and heartbeat. The next phase introduces trust via pluggable verifiers for ANS identity, tools validation, and security checks. After that comes federation, allowing `agentctl federate` to coordinate across multiple registries. The long-term vision is a unified client that discovers and verifies agents across org boundaries—local registries, MCP Registry, and ANS together—so agents can transact safely across organizations. Additional features under consideration include a live list terminal UI, a diagnostic tool (`agentctl doctor`), a graph visualization, and zero-config auto-registration from an MCP manifest. Installation is available via Homebrew for macOS and Linux, direct binary download from the GitHub releases page, or `go install` for those with Go 1.26+.

The release of agentreg addresses a structural gap in the AI agent ecosystem. As organizations move beyond single-agent deployments to running multiple agents and MCP (Model Context Protocol) servers, the infrastructure for agent-to-agent discovery and health monitoring has lagged. Currently, teams hardcode endpoints in configuration files and discover outages only when services fail downstream—a pattern that doesn't scale. agentreg fills this gap by providing a lightweight, capability-first registry that treats agents as discoverable entities rather than static network endpoints.

The tool's design reflects a deliberate philosophy: start small and self-hosted, then grow toward trust and federation without rewriting the foundation. By shipping as a single Go binary with no cloud dependency or cluster overhead, it lowers the adoption barrier for teams with just a few agents. The pluggable verifier interface and the `Source` field baked into every record are architectural choices that enable future trust mechanisms and cross-registry federation without requiring migration. This positions agentreg not as a replacement for standards bodies like IETF (which defines ANS) or standards like MCP, but as the operational tool developers actually run in production.

No comments yet. Be the first to share your thoughts!