---
title: "Activity, Conversations, and Runtime Telemetry | Agent Barn"
canonical: "https://agentbarn.dev/guides/activity-conversations-and-telemetry"
pubDate: "2026-08-25T00:00:00.000Z"
updatedDate: "2026-08-29T16:41:32.000Z"
author: Agent Barn
description: Understand how runtime messages and tool calls reach the Activity UI and remain scoped to accessible Agents.
tags: [Product guide, Agent operators and developers, Agent Barn]
categories: [Guides]
---

# 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.

## Guide details

- Reference: GD-07
- Type: Product guide
- Audience: Agent operators and developers

## 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.

## 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.

## 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.

## 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.