> ## Documentation Index > Fetch the complete documentation index at: https://docs.formation.texturehq.com/llms.txt > Use this file to discover all available pages before exploring further. # Inspect agent activity > Use conversation traces and run records to understand replies, silence, tools, and failures. Formation records conversations, runs, model calls, tool calls and outcomes in PostgreSQL. Use those records to understand what an agent saw and did. Optional telemetry and error tracking provide operational signals; they are not required to preserve a run's audit trail. ## Start with a conversation or a run * Open the agent's **Conversations** view to find the message and its context. * Inspect the message's execution trace to follow its run, model calls, tools, observations, usage and outcome. A message that did not trigger a run is represented separately from a failed run. * Use the agent's run history and summary to find recent failures and aggregate usage without first knowing the triggering message. * Use the dedicated Dreaming, commitments, schedules and model-routing views for those features' state and decisions. Engagement, execution and delivery are different questions. An observed message may require no reply. A failed model call means execution did not succeed; a failed send can mean an answer exists but did not reach the conversation. An uncertain external effect requires reconciliation before it can be safely repeated. See [egress reliability](/runtime/egress-reliability.md). ## Operator read API These routes require access to the selected agent. See [Operator API](/operator-api.md) for cookie and token authentication. | Route | Read | | - | - | | `GET /api/agents/{slug}/conversations` | Conversation list | | `GET /api/agents/{slug}/conversations/{conversationID}` | Conversation and messages | | `GET /api/agents/{slug}/conversations/{conversationID}/messages/{messageID}/trace` | One message's run and call trace; `has_run: false` when no run exists | | `GET /api/agents/{slug}/runs/{runID}/temporal/activities/{operationID}/{workflowRunID}/{activityID}/{attempt}` | Resolve a recorded activity's actual Temporal history event and redirect | | `GET /api/agents/{slug}/prompt-snapshots/{snapshotID}` | Captured prompt body referenced by the trace | | `GET /api/agents/{slug}/runs` | Run history and failures | | `GET /api/agents/{slug}/runs/summary` | Aggregate run usage and outcomes | | `GET /api/agents/{slug}/decision-calls` | Structured runtime decision history | | `GET /api/agents/{slug}/model-routes` | Model-routing history | These are implemented `/api` resources. There is no separately versioned public API or general operator SSE subscription contract. Do not build clients around older design examples that described those as available endpoints. ### Temporal execution links A message trace's `run.execution` identifies its admitted `backend` (`postgres` or `temporal`). An empty backend means ownership was not recorded; it does not imply PostgreSQL execution. Temporal records include the pinned namespace and Workflow IDs, plus recorded activity attempts and their exact step, model-call, tool-call and classifier decision IDs when available. `operation_status` describes the logical receipt, not the outcome of each individual activity attempt. Older runs may have no recorded activity correlations. Activity entries describe acquired execution attempts, not every server-side retry. Ownership, the logical operation and its acquired attempt are recorded in one transaction, so a crash before execution does not lose that attempt. A receipt-only retry can reuse a completed result before acquiring new execution authority; it adds no new activity entry or authority generation. Consult Temporal history for server-side activity details. Correlations use recorded identities, not timestamps or changes to replay authority made for reporting. Step, model and tool correlations belong to each acquired attempt, not the final logical operation. An inference attempt that stops before recording its result may have no step/model correlation; its activity link remains available. A later retry's successful model call is never attributed to that earlier attempt. The trace itself reads PostgreSQL only: it does not contact Temporal or decrypt connection credentials. Known Temporal Cloud endpoints receive Workflow and history links; other endpoints retain their IDs without guessing a console URL. Links use the run's pinned connection, not a replacement active connection. An activity's optional `event_url` is an authenticated, same-origin operator API link. Opening it resolves the exact recorded activity in that Workflow Run's history, then redirects to its actual scheduled event. This explicit read may decrypt the pinned connection's credentials and perform bounded, read-only Temporal requests. Missing or unavailable history returns an error rather than inventing an event ID; the Workflow history link remains available. An activity ID is never treated as a history event ID. Temporal console access requires its own authentication. Remote event lookups are limited to four concurrent requests per runtime replica and one per authenticated operator, shared across that operator's sessions and API tokens. Uncached lookups also share a fixed-window budget of four starts per second per replica, including failed lookups. Excess requests fail immediately with `429` and `Retry-After: 1`; there is no waiting queue. These are per-replica bounds, not a cross-replica cluster limit. A replica caches at most 128 successful event IDs for five minutes, keyed by the pinned connection, Workflow, Workflow Run and activity. Every request rechecks authorization and the exact stored attempt before using the cache. Errors and credentials are never cached. ## What records mean The run ledger connects the trigger, budget, steps, model attempts, tools and final outcome. Model records include provider-reported token counts; an absent provider measurement is not an exact cost estimate. Captured prompts explain what was assembled for a call, subject to the feature's redaction and retention rules. Image bytes and credentials are not intended as inspectable prompt data. A tool observation records the result Formation received. Effect records distinguish successful, failed and uncertain operations. Persisted delivery state, run failures and turn disposals make missing replies investigable without treating every silence as a model failure. Some views summarize records rather than exposing every internal state. A design for graph execution or a future stream does not imply a corresponding dashboard view exists. The registered routes in [`internal/admin/server.go`](https://github.com/TextureHQ/formation/blob/main/internal/admin/server.go) and their handlers define the current read surface. ## Content, retention and external monitoring Prompt, response and tool bodies can contain private conversation content. The authenticated operator API and database permissions are their access boundary. Agent access is checked on read; IDs alone do not grant access. Keep database backups under the same protections as the running database. Run-ledger retention is configurable by an owner; see [run ledger retention](/operator-api.md#run-ledger-retention). Durable memory has its own lifecycle. Expiring a call body does not revoke facts already stored in memory or published to an external service. Use [Telemetry](/telemetry.md) for OTLP traces/logs and [Error tracking](/error-tracking.md) for Sentry reports. Exported operational signals use bounded diagnostics and identifiers rather than full conversation or prompt bodies. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.