Observe and govern
Concept Available

Activity, Conversations, and Runtime Telemetry

Hermes and OpenClaw push authenticated Telemetry to a separate Ingest API. Persisted Conversation Messages and Tool Calls power Activity views without reaching into live runtime pods.

For
Agent operators and developers
On this page
  1. Why telemetry is push-based
  2. Conversation and Tool Call records
  3. Correlation and idempotency
  4. Access and boundaries
01

Why telemetry is push-based

The older pull model depended on pod availability and runtime-specific files. Runtime plugins now send a shared contract to the internal Ingest service using the Agent ID and a per-start Ingest key. Product reads use persisted data.

02

Conversation and Tool Call records

Messages record direction, chat type, session, channel, optional thread, names, content, and occurrence time. Tool Calls use PENDING, SUCCESS, or ERROR and pair results to calls by runtime invocation ID, so concurrent calls to the same tool stay distinct.

03

Correlation and idempotency

Outbound messages must be correlated to the chat that caused them; unresolvable Telemetry is dropped rather than assigned to the wrong conversation. Message and pending-call identities are idempotent. A tool result can update a matching row, but a result arriving before its pending event is currently dropped.

04

Access and boundaries

Human Activity reads require activity.read and an accessible, non-deleted Agent. Runtime writes authenticate as the Agent and do not use Membership permissions. Telemetry is not a Domain Event, Security Audit Record, or cost source.

Documentation