--- title: Observe Agent Activity canonical: "https://agentbarn.dev/guides/observe-and-govern/activity" pubDate: "2026-08-29T00:00:00.000Z" updatedDate: "2026-09-28T08:06:15.000Z" author: Agent Barn description: "Inspect Connection-scoped Conversation history and filter Runtime Tool Calls in Agent Barn, with channel, thread, status, tool-name, date, and pagination controls." tags: [Observe and govern, How-to, "Agent operators, Agent viewers, Organization administrators, and support teams", Agent activity, conversations, tool calls, Communication Connection, Communications Gateway, Ingest, channels, direct messages, threads, activity.read] categories: [Guides, Observe and govern] --- - Activity - Runtime telemetry - 13 minutes Inspect conversation history and tool executions reported by an Agent runtime. ## What Agent activity contains Agent activity currently consists primarily of persisted Conversation Messages and Tool Calls. Each has its own view and its own fields. ### Conversations Inbound and outbound chat messages. Each message records: - Direction - Channel or direct-message type - Runtime session - Channel - Optional thread - Sender identity where available - Content - Occurrence time Use Conversations to determine what a user asked and what the Agent returned. ### Tool calls One external tool execution reported by the runtime. Each call records: - Tool name - Arguments - Result - Status - Occurred time - Completed time - Duration - Runtime session ID Use Tool Calls to determine what the Agent attempted while handling a task. The Agent detail page currently exposes four activity-related tabs to authorized users: **Conversations**, **Tool calls**, **Logs**, and **Activity**. This guide covers Conversations and Tool calls. These views appear only when you have effective `activity.read` permission for the Agent. They are not automatically available to every Organization Member. Runtime logs, Agent health, and cost records are separate data sources. They are not Conversation Messages or Tool Call records, and they are not derived from them. **Operational evidence** Activity is operational evidence, useful for investigation and support. It is not a guaranteed-complete security audit ledger. ## How activity reaches Agent Barn Conversations and Tool Calls share the Agent detail experience, but they do not share a write pipeline or a persistence identity. ### Conversations come from Communications 1. **Platform provider** Slack, Microsoft Teams, Telegram, or Discord delivers an event to the Communication Connection that owns that provider identity. 2. **Platform Plugin** The shipped plugin authenticates the provider boundary where applicable, normalizes the payload, and evaluates the Connection admission policy. 3. **Communications Gateway** Accepted messages create durable Communication Deliveries, and Communications persists the canonical inbound Conversation Message. 4. **Runtime reply through the Communications protocol** The Runtime claims the Delivery over the Runtime-neutral Communications protocol and submits its reply, which Communications persists as the canonical outbound Conversation Message. The sequence reads top to bottom in four stages: a Platform provider delivers an event, the Platform Plugin normalizes and admits it, the Communications Gateway persists the canonical inbound Conversation Message alongside a durable Delivery, and the Runtime's reply returns through the Communications protocol to be persisted as the outbound message. Ingest does not accept or persist Conversation Messages. For the complete delivery architecture, see [Activity, conversations, and runtime telemetry](/guides/activity-conversations-and-telemetry). ### Tool Calls come from Ingest 1. **Hermes or OpenClaw Agent Runtime** The Runtime reports Tool Call and Tool Result telemetry as it executes tools, authenticating with the Agent ID and the per-Agent Ingest key generated when the Agent starts. 2. **Ingest API** A separately served internal API that accepts Tool Call telemetry only. Duplicate pending-call identities are handled idempotently. 3. **Persisted Tool Call records** Ingest writes Tool Calls to their own repository, separate from Conversation persistence. Tool Calls are not provider messages, Communication Deliveries, or Domain Events. Their statuses are `PENDING`, `SUCCESS`, and `ERROR`. Activity reads do not connect to the live Agent pod or parse its files on demand. Persisted activity therefore remains available while an Agent is stopped, as long as you still have access to the Agent. ## Permissions and visibility Conversation and Tool Call reads require both of the following: 1. Visibility of the Organization-owned, non-deleted Agent in the active Organization. 2. The `activity.read` Permission. The locked Agent Viewer, Editor, and Owner roles all include `activity.read`. Organization Owners and Admins hold implicit authority over every Agent in their Organization. An Organization Member without applicable direct or General Agent Access cannot bypass Agent visibility through an activity endpoint. If you can view the Agent but lack `activity.read`, the Conversations, Tool calls, Logs, and Activity tabs are hidden. Activity reads are subordinate to the Agent Access boundary, and inaccessible, deleted, and cross-Organization Agents are concealed. Knowing an Agent, Connection, channel, or Tool Call identifier does not bypass Agent Access. **Security** These are human-facing Product API reads authenticated by the user session. The per-Agent Runtime Ingest key authorizes Tool Call writes only, and never authorizes an Activity read or a Communication Delivery claim. ### Platform View Platform View may expose bounded aggregate statistics, such as message counts or the number of active Agents. It does not expose: - Message content - Sender identity - Channel identity - Session identity - Tool arguments - Tool results - Tenant runtime logs A Platform Administrator needs a real Organization Membership and applicable Agent access to inspect an individual Agent’s activity content. See [Manage roles and permissions](/guides/observe-and-govern/roles-and-permissions). ## Open the Activity views ### 1\. Select the Organization Confirm that the Organization selector shows the Organization that owns the Agent. ### 2\. Open the Agent Select the Agent from the Organization dashboard. ### 3\. Choose an activity tab The Agent detail page provides **Conversations**, **Tool calls**, **Logs**, and **Activity**. This guide covers Conversations and Tool calls. See [Review Agent health and logs](/guides/agents/health-and-logs) for Runtime logs and health. ## Review conversations **Channels** - #support - #deployments **Direct Messages** - Alice Example - U0123456789 **#support** From: 2026-08-29 08:00 To: 2026-08-29 09:00 Inbound **Alice Example**: 08:30:00 Summarize the latest deployment status. Thread · 1 reply Outbound **\[Agent name\]**: 08:30:08 The latest deployment completed successfully. This illustration shows the layout, not product output. The left column lists the Channels the Agent has messages in, then the Direct Messages, one of which shows an unresolved platform ID. The right column shows the selected #support conversation with its From and To filters above a thread: an inbound message from Alice Example at 08:30:00, and the Agent’s outbound reply at 08:30:08. ### 1\. Open Conversations Select **Conversations** from the Agent detail page. The sidebar separates activity into **Channels** and **Direct Messages**. Channel labels use a `#` prefix. Direct Messages use the resolved person or conversation name where available. When Agent Barn cannot resolve a display name, it shows the provider ID as a fallback. Each location also displays its Communication Connection name underneath. That label matters when an Agent has several Connections exposing similar channel names. ### 2\. Select a channel or direct message Select a conversation from the sidebar. A selected location is identified by both its `connection_id` and its `channel_id`, and the selection key is equivalent to: ``` : ``` Channel ID alone is not unique, because an Agent may have multiple Connections, multiple same-Platform Connections may expose the same provider channel ID, and different Platforms may use overlapping identifier formats. Both identifiers are preserved in the URL, so the view is easy to revisit or send to another authorized operator. ### 3\. Identify message direction Every message has one of two directions. The interface labels each message in text, so direction never depends on color alone. | Direction | Meaning | | --- | --- | | `INBOUND` | A message received from a user or chat platform | | `OUTBOUND` | A response produced by the Agent | Inbound messages are labeled with the resolved sender name or sender ID. Outbound messages use the Agent’s name. ### 4\. Review threads Threaded messages are grouped under their root message. Select the thread header to expand or collapse its replies; the header is a button, so it responds to Enter and Space as well as a pointer. A thread block displays the root message, the reply count, and the replies in chronological order. Unthreaded messages appear as independent roots. ### 5\. Load earlier history The newest conversation page appears first, but messages inside the visible page are shown chronologically. Select **Load earlier conversations** to retrieve older thread groups. When no older page remains, the interface shows: ``` Beginning of conversation ``` ## Filter conversation history Use the **From** and **To** controls above the selected conversation. The interface accepts local date and time values and converts them to ISO 8601 timestamps. ### From is inclusive A message is included when: ``` occurred_at >= from_date ``` ### To is exclusive A message is included when: ``` occurred_at < to_date ``` ### Recommended investigation window When investigating an event reported at 14:15, start with a slightly wider range: ``` From: 14:05 To: 14:25 ``` A wider range helps capture the message that initiated the task, earlier thread context, Agent responses, and nearby retries or follow-up messages. **Current filter boundary** Conversation history can currently be filtered by date and by the selected channel. This view has no global message-content search across every Agent conversation. ## Review tool calls Select **Tool calls** from the Agent detail page. Tool Calls are ordered newest first, and the table shows four columns: | Column | Meaning | | --- | --- | | Time | When the runtime started the tool call | | Tool | The runtime-reported tool name | | Status | Pending, Success, or Error | | Duration | Time between the reported call and its result | ### Expand a call Select a Tool Call row to inspect its **Arguments** and **Result**, rendered as formatted JSON. The row is a native disclosure control, so it opens with Enter or Space as well as a pointer. The result section is omitted when no result has been reported. **08:30:02** `github_issue_get` Success 921 ms **Arguments** ``` { "repository": "example/repository", "issue": 42 } ``` **Result** ``` { "title": "Example issue", "state": "open" } ``` This illustration shows an expanded Tool Call row, not product output. The collapsed row carries the time, the tool name, the status as the word Success, and the duration. Expanding it reveals the Arguments and Result JSON. ### Filter by tool name Use **Filter by tool name** to find calls such as: ``` read bash github jira web ``` Tool-name matching is partial and case-insensitive. ### Filter by status Choose all statuses, **Pending**, **Success**, or **Error**. ### Filter by date Use the From and To date controls. As with Conversations, From is inclusive, To is exclusive, and local date values are converted to ISO 8601 timestamps. ### Move through pages The interface displays 20 Tool Calls per page. Use the pagination controls to reach older results. Automatic refresh applies only to the first page, which refetches approximately every five seconds. ## Interpret tool-call statuses ### Pending `PENDING` The runtime reported that the call started, but Agent Barn has not matched a completion result. That can mean: - The call is still executing - The Agent or runtime stopped before completion - Telemetry delivery failed - The result arrived before the pending call and could not be paired - The result carried no matching Runtime invocation ID - The result was dropped after retry exhaustion ### Success `SUCCESS` The runtime reported a non-error result. It does not independently prove that: - The result was correct - The external system committed the intended change - The Agent interpreted the result correctly - A later operation did not reverse it Review the result, and verify important external changes at their source. ### Error `ERROR` The runtime reported an error result. Expand the row, inspect the result payload, and compare it with nearby logs and the Agent’s outbound response. Common causes include: - Provider authentication failure - Missing permission or scope - Invalid arguments - Rate limiting - Network failure - Missing file or resource - Runtime policy rejection - External service error **A long-lived Pending call is not proof of a running operation** Pending only means no matching result was recorded. The operation may have finished, failed, or never been correlated. Confirm the outcome in runtime logs, Agent health, and the external provider before assuming the call is still in flight. ## Investigate an Agent task Use this sequence when a user reports an unexpected response or action. 1. **Establish the time window** Record the Organization, Agent, chat platform, channel or direct message, approximate local time, reporting user, and expected behavior. Allow for timezone differences between the reporter and the stored timestamps. 2. **Review the conversation** Open the relevant channel or direct message and set a narrow date range. Identify the initiating inbound message, thread context, the Agent response, follow-up messages, and whether the response landed in the correct chat. 3. **Review Tool Calls** Apply the same window and look for expected tools that were never called, unexpected tools, repeated calls, error results, long-lived Pending calls, and unusually long durations. 4. **Inspect arguments and results** Expand the relevant rows and compare the requested resource, the actual resource identifier, the provider profile or repository, read versus write, the returned status, and whether the result matches the outbound response. 5. **Compare runtime health and logs** Check the Logs tab for telemetry delivery errors, provider errors, runtime crashes, correlation warnings, buffer overflow warnings, and retry exhaustion. Review Agent health for a restart or crash during the task. 6. **Verify external state** For consequential actions, confirm the outcome in the external provider: that the comment exists, the issue changed, the email was sent, or the file was written. 7. **Record the finding** Capture timestamps, the conversation channel, tool names, Tool Call IDs, statuses, sanitized errors, the external verification result, and the remediation required. Do not copy secrets or unnecessary message content into tickets. ## Understand freshness and gaps The two Activity surfaces refresh differently, because they are written by different services. ### Expected freshness Conversation Messages are persisted by Communications as each accepted message and reply is processed. The first Tool Call page refetches approximately every five seconds. Conversation queries do not use that automatic polling behavior. Reload the page or reopen the view when you are waiting for newly persisted messages. ### Tool Call delivery retries Tool Call telemetry is delivered to Ingest with a limited number of retries, so a Tool Call can be missing after a sustained outage. Inspect Runtime logs for messages such as: ``` telemetry-push buffer full telemetry-push flush failed telemetry-push dropped events ``` Conversation history is unaffected by that path, because Communications persists it independently of Ingest. ### Idempotency Provider message identity is unique within its Connection, and pending Tool Call identities are handled idempotently. A repeated delivery should not normally create duplicate visible activity. ### Correlation safety A Runtime reply is bound to the source Communication Delivery, so it cannot be recorded against another Connection, channel, or direct message. The Runtime does not choose the outbound destination. Tool results are matched to pending calls using the Runtime’s per-invocation identifier. A result received before its matching pending call currently has no record to update and is dropped, which can leave long-lived Pending calls during failures. ### Name enrichment Platform Plugins record provider IDs and then attempt to resolve readable names, best effort, before canonical persistence. Enrichment is invoked by Communications, not by Ingest. | Platform | Name behavior | | --- | --- | | Slack | Sender, channel, and direct-message names are enriched best effort | | Telegram | Chat names may be resolved through the Telegram API and cached | | Discord | Channel and user names may be resolved through the Discord API and cached | | Microsoft Teams | Team, channel, group-chat, and sender names are enriched where provider data permits | Lookup results may be cached briefly. A raw ID does not mean the message is invalid; it can mean the provider directory was unavailable or the credential lacked directory access. A lookup failure does not delay or reject an otherwise accepted message, stable provider IDs remain authoritative, and a duplicate delivery may fill a missing name but does not erase an existing one. **What Activity does and does not guarantee** Tool Call delivery is retried a limited number of times, so Tool Calls can be missing after an outage. A result that arrives before its pending call is dropped rather than mis-recorded. Name enrichment is best effort and can leave raw provider IDs behind. Duplicate identities are handled idempotently, so retries do not inflate the record. Activity is therefore operational evidence, not a complete security audit ledger. ## Conversations versus Connection diagnostics The Conversations tab displays accepted canonical message content. It is not a delivery diagnostics surface. **Important** A provider event rejected by Connection policy can appear in Connection diagnostics without ever appearing in Conversations. If you are looking for a message that was never admitted, look at the Connection, not at Conversations. Communication diagnostics separately provide: - Connection health - Content-free operational journal entries - Policy rejections - Delivery attempts - Retries - Dead letters - Reconnect and recovery information Journal entries are never merged into the Conversation timeline. See [Communication Connections](/guides/agents/communication-connections) for where those diagnostics live. ## Activity, logs, costs, and audit records These data sources answer different questions. | Source | Primary question | | --- | --- | | Conversations | What did the user and the Agent say? | | Tool Calls | What external tool operation did the runtime attempt? | | Logs | What did the runtime and the deployment report? | | Health | Is the Agent workload currently healthy? | | Costs | What model usage and spend were attributed? | | Security Audit Records | What security-relevant business change was recorded? | Conversation Messages and Tool Calls are not cost records, spend attribution sources, Domain Events, Outbox Messages, Event Deliveries, or Security Audit Records. Costs are not calculated from Conversation Message or Tool Call counts. See [Costs and spend attribution](/guides/costs-and-spend-attribution) for how spend is reported, and [Domain Events, outbox, and delivery](/guides/domain-events-and-delivery) for the separate internal event path. **Important** Do not use Agent activity as the only compliance or security-audit record for sensitive administrative actions. ## API reference ### List conversation channels ``` GET /api/v1/organizations/{organization_id}/agents/{agent_id}/conversations/channels ``` ``` [ { "connection_id": "018f0000-0000-7000-8000-00000000000a", "connection_name": "Slack: Support workspace", "platform_key": "slack", "channel_id": "C0123456789", "channel_name": "support", "conversation_type": "CHANNEL" }, { "connection_id": "018f0000-0000-7000-8000-00000000000a", "connection_name": "Slack: Support workspace", "platform_key": "slack", "channel_id": "D0123456789", "channel_name": "Alice Example", "conversation_type": "DM" } ] ``` The channel list identifies each location using `connection_id`, `connection_name`, `platform_key`, `channel_id`, `channel_name`, and `conversation_type`. ### Read conversation threads Message reads are scoped to one Connection and channel. Conversation pagination is cursor-based, and the API defaults to six thread groups per page. ``` GET /api/v1/organizations/{organization_id}/agents/{agent_id}/conversations/connections/{connection_id}/channels/{channel_id}/messages?page_size=6 ``` There is no current route that reads messages using `agent_id` and `channel_id` without a `connection_id`. Optional parameters: ``` from_date=2026-08-29T08:00:00Z to_date=2026-08-29T09:00:00Z before_occurred_at=2026-08-29T08:30:00Z before_id=018f0000-0000-7000-8000-000000000001 page_size=6 ``` ``` { "threads": [ { "root": { "id": "018f0000-0000-7000-8000-000000000001", "direction": "INBOUND", "thread_id": null, "sender_id": "U0123456789", "sender_name": "Alice Example", "content": "Summarize the latest deployment status.", "occurred_at": "2026-08-29T08:30:00Z" }, "replies": [ { "id": "018f0000-0000-7000-8000-000000000002", "direction": "OUTBOUND", "thread_id": "1756456200.000000", "sender_id": null, "sender_name": null, "content": "The latest deployment completed successfully.", "occurred_at": "2026-08-29T08:30:08Z" } ] } ], "has_more": true, "next_cursor": { "before_occurred_at": "2026-08-29T08:30:00Z", "before_id": "018f0000-0000-7000-8000-000000000001" } } ``` Use the complete `next_cursor` in the next request. The `before_id` value is the deterministic tie-breaker when several thread roots share a timestamp. ### List Tool Calls Tool Call pagination is page-based. ``` GET /api/v1/organizations/{organization_id}/agents/{agent_id}/tool-calls?page=1&page_size=20 ``` Optional filters: ``` tool_name=github status=ERROR from_date=2026-08-29T08:00:00Z to_date=2026-08-29T09:00:00Z ``` ``` { "page": 1, "page_size": 20, "total": 1, "items": [ { "id": "018f0000-0000-7000-8000-000000000003", "agent_id": "018f0000-0000-7000-8000-000000000004", "session_id": "session-redacted", "tool_name": "github_issue_get", "arguments": { "repository": "example/repository", "issue": 42 }, "result": { "title": "Example issue", "state": "open" }, "status": "SUCCESS", "occurred_at": "2026-08-29T08:30:02Z", "completed_at": "2026-08-29T08:30:03Z", "duration_ms": 921 } ] } ``` Tool Calls are ordered by `occurred_at` descending. The example above uses placeholder identifiers and content: no real message, session, or credential data. ## Troubleshooting | Symptom | Likely cause | Resolution | | --- | --- | --- | | The Conversations and Tool calls tabs are missing | You do not hold activity.read for this Agent | Ask an Agent Owner to grant Agent Viewer, Editor, or Owner access. | | No conversations yet appears | The Agent has no enabled Communication Connection, or no provider message has been admitted yet | Confirm a Connection is enabled and healthy, send a permitted test message, then check the Connection diagnostics. | | A provider message never appears in Conversations | Connection admission policy rejected it, so no canonical Conversation Message was written | Review the Connection journal for the policy disposition rather than searching Conversations. | | A stopped Agent still shows activity | Activity reads use persisted records rather than the live pod | This is expected behavior. Historical activity stays readable while the Agent is stopped. | | New messages are not appearing | Conversation queries do not poll on the five-second cycle used by Tool Calls | Reload the page or reopen the Conversations view. | | Tool Calls update but Conversations do not | Only the first Tool Call page refetches automatically | Refresh Conversations manually, and return to Tool Call page one for automatic updates. | | A Tool Call remains Pending | The call is still running, or its result telemetry was never matched or delivered | Compare runtime logs, Agent health, and the external provider state. | | An outbound response is missing | The Runtime produced no reply, or the outbound Delivery failed at the provider | Check Agent health and Runtime logs first, then the Connection delivery diagnostics. | | A sender or channel shows a raw platform ID | Name enrichment failed, or is unsupported for that platform | Check platform credentials and directory access. The raw ID is still valid for correlation. | | A thread appears split or has an unexpected root | Runtime thread metadata was incomplete or fragmented | Compare the timestamps against the platform-native thread history. | | Date filters return no data | Local time was converted to UTC, or the exclusive To boundary is too narrow | Widen the range and confirm the timezone conversion. | | A retried delivery did not create a duplicate row | Ingest identities are idempotent | This is expected behavior. | | Tool Calls are missing after an outage | Tool Call telemetry exhausted its delivery retries to Ingest | Review Runtime logs and Ingest availability for that period. Conversation history is unaffected, because Communications persists it separately. | | The status says Success but the external change is absent | Success reflects the runtime result, not independent provider verification | Verify the external system directly and inspect the result payload. | | Activity returns HTTP 404 | The Agent is inaccessible, deleted, or belongs to another Organization | Confirm the active Organization and the Agent Access that applies to you. | | Activity returns HTTP 403 | The Agent is visible, but activity.read is missing | Grant an Agent Access Role that includes activity.read. | | Filtering by tool name misses a call | The runtime reported a different tool name than the one you searched for | Clear the filter and inspect the recent calls directly. | | Older Tool Calls stop refreshing | Automatic polling applies only to page one | Return to the first page, or refresh manually. | ## Security and privacy **Activity can contain sensitive data** Conversation content and Tool Call arguments and results are stored as the runtime reported them. They may contain personal data, customer information, internal URLs, file contents, provider responses, or accidentally disclosed credentials. Agent Secret APIs never return credential plaintext, but a runtime is free to place a secret into a message or a tool argument. Treat activity as potentially sensitive regardless of how credentials are stored. Follow these practices: - Grant `activity.read` only to people who need operational visibility - Remember that Agent Viewer includes conversation, Tool Call, log, and cost visibility - Treat Direct Messages as potentially sensitive - Avoid passing credentials as Tool Call arguments - Do not ask Agents to repeat secrets in chat - Sanitize activity before copying it into tickets - Do not expose raw Tool Call results in public incident reports - Review access when Members change roles - Use Restricted General Access for sensitive Agents - Verify the active Organization before reviewing activity - Treat external web and message content as untrusted - Do not mistake runtime telemetry for an immutable compliance record - Use provider-native audit logs for consequential external operations - Protect the Ingest service and the per-Agent ingest keys - Never expose the internal Ingest endpoint as an unauthenticated public API - Export required evidence before deleting an Agent or an Organization ## Next steps After reviewing Agent activity: 1. Compare unexpected Tool Calls with runtime logs. 2. Verify consequential changes in the external provider. 3. Correct Agent configuration, Skills, credentials, or access as needed. 4. Repeat the task with a controlled test. 5. Review model usage and spend. 6. Continue to [Review costs](/guides/observe-and-govern/costs). [**Activity, conversations, and runtime telemetry** The full write-path architecture](/guides/activity-conversations-and-telemetry) [**Communication Connections** Connection health and diagnostics](/guides/agents/communication-connections) [**Review costs** Model usage and attributed spend](/guides/observe-and-govern/costs) [**Review Agent health and logs** Runtime conditions and log output](/guides/agents/health-and-logs) [**Domain Events, outbox, and delivery** The separate internal event path](/guides/domain-events-and-delivery) [**Manage roles and permissions** Who holds activity.read](/guides/observe-and-govern/roles-and-permissions) [**Share access to an Agent** Grant or revoke activity visibility](/guides/agents/sharing) ## Agent Activity, wake grouping, and triggers The **Activity** tab answers what an Agent has been doing over time by grouping model calls into distinct **wakes** — bursts of model calls occurring close together. ### Wake grouping and cadence A wake represents a maximal sequence of calls separated by no more than a brief quiet window. Each wake reports total calls, prompt token distributions, and median spacing (cadence). Gaps in activity render as quiet buckets rather than omitted intervals. ### User vs Background triggers Every wake is inferred as either `USER` or `BACKGROUND`: - **USER:** An inbound user chat message occurred within the lead window before or during the wake. - **BACKGROUND:** No human message was recorded around the wake. Scheduled crons, heartbeats, and webhooks are attributed as background activity. The Activity tab also displays live container runtime diagnostics independently of the usage window, surfacing termination codes and previous-container logs even when no billable calls occurred. **Permissions** Viewing usage breakdowns on the Activity tab requires both `activity.read` and `cost.read` permissions. Users with `activity.read` alone see runtime diagnostics without spend figures.