Chronos agent registry

What is the Chronos agent registry?

Chronos by Intelligex is an open source, self-hosted control plane for AI agents and MCP tools.

The agent registry is part of Chronos control plane where every agent — regardless of where it actually runs — gets a row, a slug, a uniform invocation endpoint, and a single set of governance hooks.

Once you operate more than one or two agents, you are familiar with the problem the registry solves: each agent has its own URL, its own auth model, its own logs, and (eventually) its own copy of credentials. The Chronos agent registry aims to address these chalanges.

Two runtime types, one invocation surface

Since Chronos v1.6, agents come in two flavours, picked at the registration time:

Both runtime types share the same uniform endpoint:

POST /api/v1/agents/<idOrSlug>/invoke

From a API caller's perspective, the runtime is invisible.

The dispatcher routes BUILT_IN to the in-process agentflow runtime (preserving full SSE streaming) and HTTP to the registered service endpoint (with outbound auth and the callback contract applied). Same metric pipeline, same observability, same governance hooks.

With Chronos you can ship a working canvas agent in five minutes, then later replace it with a code-first agent without impacting API contract or API clients using agents.

Why one registry across runtimes?

We implemented this to achieve the following:

• One operator surface. The Agents page lists every agent, regardless of where it runs. Status, last-seen-healthy, call volume, owner — all in one place.
• One auth boundary. Callers hit one URL pattern with one API-key model. They don't need to know whether the agent is canvas-built or external.
• One tool layer. Every agent reaches tools through the same MCP gateway with the same allowlist semantics — see Chronos MCP registry.
• One audit stream. Every tool invocation emits a structured audit line tagged with the calling agent's ID, slug, and runtime type.
• A2A protocol hedge. The Agent entity is shaped as a A2A Agent Card — name, description, version, capabilities, skills, security schemes are first-class columns. At this time Chronos doesn't implement A2A fully, but a future runtime will introduce /.well-known/agent.json for A2A integrations.

What an HTTP agent contract looks like

When you register an external agent, you hand Chronos three things:

1. Where the agent lives — serviceEndpoint. Chronos performs POST to <endpoint>/v1/chat/completions for invocation and provided agents health URL every 30 seconds for liveness.
2. What auth agents supports — outboundAuth. Bearer or static-header, inline or vaulted. Chronos resolves this on every call so secrets don't sit on the agent process.
3. Which MCP tools the agent allowed to call — allowedTools. Namespaced names like postgres.query. The MCP gateway enforces the intersection of this list and each tool server's own allowlist on every callback.

In return, Chronos issues a callback token — a hex secret your agent presents as Authorization: Bearer … when it calls back into the MCP gateway to invoke a tool.

The token is the auth on the callback path; no separate API key is required, and the underlying MCP-server credentials never reach the agent process. See the Chronos MCP registry for how the tool side of that relationship is brokered.

The hands-on walkthrough lives in register an HTTP agent in Chronos.

What a BUILT_IN agent looks like

BUILT_IN do not have to be registered manually. Every agentflow you build on the Chronos visual canvas auto-creates a row in the registry, with its slug derived from the agentflow name.

Within registry all BUILT_IN agents have links back to their canvas at /canvas/<id>.

The runtime type is locked at the agent registration time and cannot be modified post-registration. Moving an agentflow to a code-first implementation means registering a new HTTP agent.

The hands-on walkthrough for the canvas path lives in build your first canvas agent in Chronos.

Health, status, and observability

Every HTTP agent gets a 30-second health probe. This is configurable via AGENT_HEALTH_POLL_INTERVAL_MS.

Agent statuses fall within HEALTHY, UNHEALTHY, UNKNOWN (newly registered, not yet probed), and DISABLED (disabled in Chronos agent registry).

BUILT_IN agents skip the probe — they run in Chronos process.

Tool invocations from any agent emit a structured audit line:

event=mcp.tool.invoke 
agentSlug=<slug>
server=<server>
tool=<bare-tool>
success=true
latencyMs=<n>

A persistent tool_invocation_audit table with the rest of the Chronos governance work adds strong auditing capabilities.

Executions and per-step metrics write to Execution and ExecutionMetrics, keyed by the agent's ID — dashboard filtering, cost attribution, and replay all work uniformly across runtime types.

Token-count fields on ExecutionMetrics are written as 0 for HTTP agents and will change in future Chronos releases.

Callback token rotation

The callback token is a production secret like any other — leak it and an attacker who can reach the gateway URL can invoke any tool the agent is allowlisted for.

Chronos at this time provides a single-step rotation: click Rotate, get a fresh hex value, and the old value stops working.

The deploy choreography (rotate → push the new token → restart the agent) is documented in rotate the Chronos agent callback token.

Where the registry sits in the bigger picture

The agent registry is one of two main control-plane elements in Chronos. The other is the Chronos MCP registry — the gateway through which agents reach tools.

Together they form a clean separation: agents register what tools they will use, MCP servers register what tools they provide, and the gateway brokers the connection.

The next layer is governance — SSO, RBAC, per-team budgets with stop-switches, persistent audit logs, PII redaction.

Get hands-on

• Register an HTTP agent in Chronos — register your first external agent, copy the callback token, exercise a tool callback round-trip.
• Build your first canvas agent in Chronos — the visual-builder path; ends with a BUILT_IN agent type in the registry.
• Rotate the Chronos agent callback token — the token rotation & re-deployment.
• Chronos MCP registry — the Chronos MCP registry.