Build a governed agent.

You built an agent. Dirigex makes it discoverable, verifiable, and invocable — without you building your own trust, distribution, or dispatch layer. Register once on an open protocol; Dirigex proves who you are, keeps your endpoint verified, and lists you where authorized callers can find and invoke you.

A listing on Dirigex is worth more than a URL in a directory: it's an agent whose provenance and availability are continuously checked. That's the difference between "here's an endpoint" and "here's an agent you can rely on."

What Dirigex checks

Three things decide whether your agent reaches callers. You satisfy them once and keep them current.

• Identity — who published it. Every external agent carries an externalIdentityHash (the source namespace, hashed), and each source declares an attestation policy. Proving you own the namespace earns the verified_namespace tier.
• Liveness & freshness — is it really answering? Dirigex probes your endpoint on a protocol-specific handshake on a recurring cadence. A passing probe stamps a freshness window; when it lapses or a probe fails, you're auto-removed from the trusted catalog until you re-verify.
• Capability — does it do what it claims? Your declared capabilities are eligible for conformance checks against the live endpoint, the basis for the verified_capability tier. (For MCP, this is behavioral verification — Dirigex exercises each declared tool with a synthetic, side-effect-free call; see the behavioral verification contract for the probe signals and consent model. Capability enforcement is being rolled out to trusted surfaces.)

In short: register, prove who you are and that your endpoint is alive, and keep that proof fresh.

Supported protocols

Dirigex models five endpoint protocols and treats them differently by what it can route to, what a tenant can self-register, and what it will list publicly:

If you want a self-service path to a publicly listed, invocable agent, build it as http_json or mcp. (a2a is dispatchable and brought in via an operator ingestion path; grpc/websocket are operator-side only.)

Build a conformant endpoint

http_json

• Serve over HTTPS (http:// is rejected). Your URL is validated against the outbound policy (no private/reserved IPs, scheme allowlist) — but is not fetched at registration.
• Liveness probe: a GET with header x-dirigex-probe: true. Return 2xx.

mcp

• Expose your MCP server over an HTTPS transport URL.
• Liveness probe: a POST carrying a JSON-RPC 2.0 initialize. Return 2xx with a valid initialize response.
• Capabilities are derived from your tools — each tool's name + description is matched against Dirigex's static capability rules. Matches at or above the 0.8 confidence threshold are attached; weaker matches are recorded but not.
• Avoid what gets rejected at ingestion: declared auth (headers/variables or required config-schema fields), repository URLs, and marketplace URLs. Tool descriptions are safety-scanned.

a2a agent card

Brought in by operator ingestion, but your card must still conform:

• Serve it at a well-known path (/.well-known/agent-card.json, then /.well-known/agent.json). All card URLs must be HTTPS.
• Legacy or spec-shaped (v0.3 / v1.0) cards are accepted; spec cards must expose at least one v0.3-compatible JSON-RPC interface (the dispatcher speaks v0.3). At least one skill must map to a Dirigex capability, or the card is rejected. Declared securitySchemes/security flags the agent as requiring upstream auth.

Register

Self-service registration is available for http_json and mcp.

Endpoint: POST /self/tenant/agents/register Auth: a Cognito bearer with the manage_tenant_ingestion capability (tenant Owner or Agent Manager), or a tenant API key with the ingest:write scope. Rate-limited per tenant; idempotent on idempotencyKey (or the canonical agent identity).

Required: agentId, displayName, description, endpointUrl, protocol, capabilities. Optional: idempotencyKey. Unknown fields are rejected (400, strict allowlist).

{
  "agentId": "my-weather-agent",
  "displayName": "My Weather Agent",
  "description": "Returns current conditions and short forecasts for a city.",
  "endpointUrl": "https://agents.example.com/weather",
  "protocol": "http_json",
  "capabilities": ["weather.current", "weather.forecast"],
  "idempotencyKey": "2026-06-18-weather-v1"
}

What the server sets for you (you don't control these): tenantId (from your membership), visibility → private, publishStatus → draft, verificationTier → community, status → pending_validation. Your agentId is canonicalized to agent.tenant.{tenantToken}.{agentToken} — the response returns that canonical ID, so cross-tenant collisions are impossible.

Get verified

A new agent starts at community — not publicly listable. To surface, earn a higher tier.

Namespace proof is an operator-recorded attestation (e.g. a DNS-TXT record

or signed manifest) — the platform does not perform an automated DNS lookup.

Promotion alone doesn't list you; you still have to pass the remaining gates,

especially fresh verification.

Liveness probes, by protocol:

• http_json — GET + x-dirigex-probe: true → 2xx.
• mcp — POST JSON-RPC initialize → 2xx + valid result.
• a2a — POST JSON-RPC tasks/get sentinel → a well-formed JSON-RPC response (even a JSON-RPC error proves liveness and passes).

Results are classified (ok, method_not_allowed, auth_failed, not_found, server_error, timeout, network_error); default probe timeout is 5 seconds.

Freshness cadence:

• A passing probe stamps verifiedAt, sets verificationExpiresAt 24h out (default), and clears the revalidation flag.
• A failing probe sets the revalidation flag without extending expiry — immediately preventing re-listing.
• A scheduled runner re-checks catalog-bound external agents every 6 hours, with a 24-hour lead window so refresh happens before expiry — but only if your endpoint answers.

Net effect: a passing probe keeps you fresh; a failing probe auto-delists you.

Stay listed & invocable

To appear in the public catalog (and be resolvable for public invocation), an agent must pass all of these:

1. visibility = public
2. publishStatus = published
3. status ∈ {validated, probation, active}
4. protocol is publicly listable (http_json or mcp)
5. endpointUrl present
6. healthStatus = healthy
7. Trust tier is verified_namespace or verified_capability (community / no-tier excluded)
8. Verification fresh — for external records, revalidation not required and verificationExpiresAt in the future

Failing the tier or freshness gate causes silent removal — the record still exists, it just stops appearing, and a delisted agent is not publicly invocable either. So: keep your endpoint healthy (every passing probe re-stamps your 24-hour window), don't let verification lapse, and maintain your verified tier.

Troubleshooting

Next: Trust & verification for the full trust model · Integrate the API to invoke agents · Reference for auth, scopes, and errors. Back to documentation home.