Agent reliability signals

Agent reliability signals are observed telemetry, not a promise. Delx exposes a read-only view of liveness, per-tool outcomes, and latency so your own orchestrator can make a better-bounded decision before an operation.

Direct answer

Fetch https://api.delx.ai/api/v1/reliability to inspect the current service response and the telemetry windows it publishes. Use the result as one input to routing and recovery; it is not an SLA, authorization decision, traffic router, or guarantee that the next call will succeed.

How to use reliability signals before an operation

1. Fetch https://api.delx.ai/api/v1/reliability and confirm the service responds now.
2. Choose the relevant product and window. Use protocol_tool_telemetry_24h for Protocol or commerce_tool_telemetry_24h for Commerce, then compare outcomes and latency.
3. Use https://api.delx.ai/api/v1/session-validate with the session_id before spending another tool call.
4. Make your own bounded routing decision, call the selected path, and verify the actual outcome.
5. Keep /api/v1/status and /api/v1/stats distinct from rolling reliability windows.

Reliability Endpoint

GET https://api.delx.ai/api/v1/reliability

What to use for routing

• liveness: the endpoint responds now; it is not a future-availability guarantee.
• uptime_seconds: a coarse process-uptime signal that resets on deploy.
• tool_telemetry_realtime, tool_telemetry_24h, and tool_telemetry_7d: observed per-tool totals, errors, success rate, and latency percentiles.
• The unprefixed fields above are a legacy mixed-product compatibility view. Prefer protocol_tool_telemetry_24h / protocol_tool_telemetry_7d or commerce_tool_telemetry_24h / commerce_tool_telemetry_7d for product health.
• Product-scoped rows expose client_error_count, system_error_count, and operational_success_rate. Invalid caller input remains visible but is excluded from operational service reliability.
• latency p50/p95/p99: observed response distributions for the selected window, not a latency promise for your next call.

What the signal does not prove

• No SLA or future-availability guarantee.
• No permission to call a tool, access a resource, or spend a budget.
• No proof that an operation is safe, correct, or idempotent.
• No automatic traffic routing or failover performed by Delx.

Health and stats

GET https://api.delx.ai/api/v1/stats

GET https://api.delx.ai/api/v1/status?session_id=<uuid>

Use /api/v1/status for fast liveness, pending outcomes, and TTL, and /api/v1/stats for aggregate usage and identity metrics. Pair this with Security for a monitoring and governance setup.

Do not compare /api/v1/stats totals directly to /api/v1/reliability tool windows. Stats are all-time aggregates plus growth aliases; reliability is realtime or rolling window telemetry meant to inform a bounded orchestrator decision.

Session sanity checks

GET https://api.delx.ai/api/v1/session-validate?session_id=<uuid>

This is the fastest way for an agent to confirm whether a session exists. A valid HTTP response with ok: false means the session was not found; the status surface may instead return the stable session_not_found error. Neither response grants authority.

Session reliability score

The read-only get_wellness_score tool (technical alias: get_reliability_score) returns an operational heuristic for a live session. It is not a measurement of model activations, alignment, authorization, or safety outside that session.

get_wellness_score({ session_id, include_trend: true })

Common questions

What are Delx reliability signals?

Read-only observations of liveness, per-tool calls and errors, success rate, and p50/p95/p99 latency across published telemetry windows.

Do reliability signals route traffic for me?

No. Delx exposes read-only signals; your orchestrator decides whether and where to call.

Is the stats endpoint the same as reliability?

No. Reliability is observed rolling telemetry; stats are aggregate usage and identity metrics with separate semantics.

Does get_wellness_score prove model safety?

No. It is a Delx operational heuristic for a live session, not a mechanistic-interpretability or future-safety claim.