Roadmap

Conduit’s goal is to be the observability layer a security-conscious team can run next to its AI agents. It should be self-hosted, small enough to audit, and focused on what matters for agents: steps, tools, models, errors and cost.

This roadmap is ordered by priority, not by date. Items move as we learn. To suggest a change, open an issue or a PR against docs/_data/roadmap.json.

  1. Shipped21 items
  2. NowHardening for first production users
  3. NextScale and integration
  4. LaterInsight
Now

Hardening for first production users

UI

Prompt and completion access control

Payloads are stored but never shown. Showing them needs a decision on who may see them (see open decisions).

Next

Scale and integration

SDKs

Batched, asynchronous SDK delivery

One blocking RPC per span is simple but slow for chatty agents. Add a buffered exporter with backpressure.

Storage

Read the trace list from trace_summary

Avoid aggregating raw spans for every list query at high volume. Needs root names and agents in the view.

Pipeline

OpenTelemetry interoperability

Accept OTLP from existing OpenTelemetry agents, and use OTel semantic conventions for LLM attributes.

UI

Search

Search attributes, error messages and span names across traces.

SDKs

Published SDKs

A PyPI package and a tagged Go module with stable import paths (see open decisions).

Operations

Helm chart

Package the Kubernetes manifests with sensible defaults.

Later

Insight

UI

Cost and token dashboards

Spend by agent, model and time, built on the existing rollups.

Operations

Alerts

Error-rate and latency thresholds per agent, with webhook delivery.

UI

Trace comparison

Compare two runs of the same task side by side.

Security

Multi-tenancy

Separate projects or teams with scoped UI access.

Shipped

What's already in Conduit

Foundation

  • mTLS agent identity, with the certificate CommonName as agent_name
  • Span validation at ingestion
  • Per-agent rate limiting, charged per telemetry item
  • NATS JetStream work queue with at-least-once delivery into ClickHouse
  • Best-effort export to VictoriaMetrics and Tempo
  • Span status (ok, error, unset) from end to end, and nanosecond timestamps
  • Logs (ClickHouse) and metrics (VictoriaMetrics) ingestion, each with its own NATS stream, plus SDK Log, Gauge and Counter APIs

SDKs

  • Go and Python SDKs: mTLS that trusts only your CA, W3C-sized IDs, status and error recording
  • Python context that is safe across threads and asyncio tasks

UI

  • Sign-in: a login form with signed session cookies, or Google Cloud IAP
  • Strict CSP and browser hardening
  • Trace list: one row per trace, filters by time, agent and errors, keyset paging, agent suggestions
  • Trace detail: span tree, waterfall timeline, error and LLM details, deep links
  • Logs page: filters by time, severity, agent, text and trace, with deep links to spans

Data governance

  • STORE_LLM_PAYLOADS=false drops prompts and completions at the gateway
  • SPAN_RETENTION_DAYS, with the TTL reconciled on existing tables
  • Versioned, checksummed ClickHouse schema migrations (collector migrate)

Operations

  • /livez and /readyz on every service, and a healthcheck subcommand for scratch images
  • Compose restart policies and Kubernetes probes, plus GKE IAP manifests

Quality

  • CI: race tests, a generated-code drift check, govulncheck, Docker builds, and a full-stack smoke test with both SDKs
  • Brand identity, documentation set, and this docs site
Open decisions

Waiting on a maintainer's call

Who can see prompts and completions

  • Every signed-in user
  • A separate role or permission
  • Reveal-on-click with an audit log

Raised in PR #3

nats-server as a test dependency

  • Add an in-process NATS for integration tests
  • Rely on the compose smoke test, which already covers the path

Leaning toward the smoke test.

Raised in PR #2