Goal
Add optional durable Runtime resource history for the Core Web Dashboard without changing current-snapshot execution ownership or making a telemetry backend mandatory for Sessions.
This follows the current-snapshot/API/Web work in #30 and Phase 4 of contracts/agents-api/runtime-observability-design.md.
Operator outcome
- Select a durable time range such as 1h, 6h, or 24h in Runtime monitoring.
- See CPU utilization, memory usage/limit, compute uptime boundaries, and observation coverage from an explicitly labeled history source.
- Keep browser-local live samples visually and semantically distinct when no history backend is configured.
- Preserve exact tenant, Session, Environment, and Runtime-incarnation attribution.
Proposed delivery slices
4A. Optional telemetry export
- Add an internal provider-neutral exporter seam after a validated current observation is produced.
- Export cumulative CPU seconds, CPU capacity, memory usage/limit, sample result, and sample duration using the instrument names documented in the design.
- Keep export asynchronous/bounded so backend failure never fails Session execution or the current observation read.
- Avoid high-cardinality global Prometheus labels. If Session or Runtime identity is exported, require an operator backend and tenant-isolated resource attributes suitable for authorized queries.
- No provider-native IDs, labels, paths, errors, or credentials.
4B. History query adapter and public Core extension
- Define a separate
runtimehistory read interface; do not overload runtimeobs.Service or current observation routes.
- Resolve tenant and Session authorization in Core before querying the backend.
- Define range, step/downsampling, maximum points/series, whole-request deadline, and response byte limits.
- Fence series by provider-neutral Runtime incarnation so replacement/restart produces a gap rather than a false continuous line.
- Return explicit
unsupported, unavailable, and partial/coverage metadata; never coerce missing samples to zero.
- Generate the OpenAPI extension and consume it only through
packages/agents-client.
4C. Web durable ranges
- Add advertised durable ranges only when the history capability is configured.
- Keep
Live as the existing browser-local bounded window and reset it on reload/navigation as today.
- Label the selected source and freshness. Never merge durable and ephemeral points without an explicit boundary.
- Preserve the current 2x2 CPU, memory, uptime, and token chart layout; token history remains sourced from canonical Session/Turn usage or a separately authorized history contract, not Runtime telemetry duplication.
- Retain accessible tabular summaries for latest value and missing points.
Boundaries
- No PostgreSQL time-series table or product database dependency.
- No lifecycle action, idle inference, suspension, restart, or allocation mutation.
- No Kubernetes, E2B, or self-hosted source implementation in this issue.
- No billing or cost data in Core Web.
- No browser access to OTLP/Prometheus credentials or direct backend queries.
- Current snapshot API remains available and correct when history is absent or unhealthy.
Acceptance
- Core starts and all execution/current-observation workflows pass with history fully disabled.
- Export/backend outages do not change execution, allocation, observation status, or API latency beyond the configured bounded handoff.
- Cross-tenant history reads are impossible and tested.
- Restart/allocation replacement/counter regression creates a gap; no synthetic interpolation or zero fill.
- Query budgets and retention limits are enforced in service and client tests.
- Core Web clearly distinguishes
Live browser memory from durable backend ranges.
- Architecture, operator configuration, generated contract, coverage ledger, tests, and deployment acceptance are updated.
Open implementation decision
Qualify one operator backend and transport before implementation. Prefer OTLP-compatible export plus a tenant-authorized query adapter, but record the chosen backend's identity model, retention, downsampling, and query API before adding dependencies.
Goal
Add optional durable Runtime resource history for the Core Web Dashboard without changing current-snapshot execution ownership or making a telemetry backend mandatory for Sessions.
This follows the current-snapshot/API/Web work in #30 and Phase 4 of
contracts/agents-api/runtime-observability-design.md.Operator outcome
Proposed delivery slices
4A. Optional telemetry export
4B. History query adapter and public Core extension
runtimehistoryread interface; do not overloadruntimeobs.Serviceor current observation routes.unsupported,unavailable, andpartial/coverage metadata; never coerce missing samples to zero.packages/agents-client.4C. Web durable ranges
Liveas the existing browser-local bounded window and reset it on reload/navigation as today.Boundaries
Acceptance
Livebrowser memory from durable backend ranges.Open implementation decision
Qualify one operator backend and transport before implementation. Prefer OTLP-compatible export plus a tenant-authorized query adapter, but record the chosen backend's identity model, retention, downsampling, and query API before adding dependencies.