Skip to main content
Every turn your agent runs is recorded at several levels: a billing row you can scan, a health snapshot you can watch, a step-by-step record you can open, and a capture of anything that failed. This page describes each and how to use them to debug a conversation.

​
The four layers

​
Activity log

Every turn — and every billable operation, like a file ingest — writes one row: time, surface, user, duration, step count, model, tokens, cost, and credits. When the judge is enabled, the row shows its score out of 10, amber when below your threshold. Opening a row adds three things a summary line can’t:
  • Knowledge Used — what was searched and exactly which passages went to the model.
  • Charges breakdown — an itemized list of every credit line that made up the total.
  • The conversation — the exact message and reply.

​
Monitoring: the health snapshot

The Monitoring page shows a rolling-window snapshot (1 hour up to 7 days): query volume, error count and rate, latency (p50 / p95 / max), total spend and tokens, the live-eval pass rate, the most recent errors, and per-hour bars so you can see when a spike started. Alongside it are a judge summary with a trend, a log of failed outbound provider calls, your eval criteria and alert rules, and the scenario runner covered in Evaluation and quality. Health analytics is a Business-tier feature; the page stays visible on every plan, with the gated section shown muted rather than hidden.

​
The full conversation record

Everything about one conversation is kept together and viewable on the Conversations page. Records are separated per user, per channel, and per endpoint — two Telegram bots keep two separate records — so nothing about a conversation is ever scattered, and a conversation can be inspected and deleted as a unit. For each turn you can open the harness view, which shows every step: each model request and response, every tool call with its arguments, result, and timing, connector calls, sandbox code runs, memory writes, hook fires, safety-guard decisions, and charges. That’s where you see which call misbehaved and how long it took.

​
When a turn fails

A turn that never reaches its normal end — setup fails, the provider errors, the stream drops — is always captured, with the error and the point it failed, and surfaced everywhere: the turn summary, the conversation view, the activity row, and the Monitoring error rate. The viewer never shows a turn that just… stops.

​
Debugging a conversation

From symptom to cause:
  1. Start at Activity. Find the row — an amber judge pill, an error badge, or the user and time. Open it for the exact message and reply, the Knowledge Used trace, and the itemized charges.
  2. Open the harness view. On the Conversations page, select the session and flip the chat/harness toggle to see the full step stream with per-step timing.
  3. If retrieval was the problem, re-run it. The Retrieval Test page replays a query against your live knowledge so you can check whether the right passages surface today.

​
Cost and reproducibility

Each turn’s cost is itemized — input, output, and cache — and the line items sum exactly to what was billed. Credits convert from cost at a fixed rate. Latency is recorded per tool call and visible per step in the harness view; Monitoring aggregates latency at the turn level (p50 / p95 / max). The platform records enough about each turn to review it after the fact, but it can’t reproduce an LLM answer token-for-token — model outputs are inherently non-deterministic. Pinning a low temperature in Model Controls makes outputs more repeatable, not identical. For repeatable regression testing, use the scenario re-runs in Evaluation and quality.