Skip to main content
The Critiqor dashboard is divided into purpose-built sections, each answering a specific question about your agent’s run. Use this page as a reference for what each section shows, why it matters, and how to read it.
What it showsThe Executive Summary is the top-level verdict on your run. It presents a concise, plain-language assessment of the session’s overall health — categorized as healthy, needs attention, or has significant issues.Why it’s usefulYou can tell at a glance whether a run warrants deeper investigation. If the summary is healthy, you may not need to look further. If it flags attention or significant issues, it directs you to the right place to start.How to interpret it
  • Healthy — The run completed without notable reliability concerns. Review the Trust Score to confirm, but you likely don’t need to dig into the diagnosis.
  • Needs attention — One or more signals were flagged during the session. Read the Primary Diagnosis to understand what was observed.
  • Significant issues — The run exhibited clear reliability problems. Move immediately to Primary Diagnosis and Runtime Evidence for a full breakdown.
What it showsThe Trust Score is a reliability signal expressed as a level — High, Moderate, or Low — accompanied by the confidence signals that informed it. It gives you a single, scannable indicator of how trustworthy the run’s behavior was.Why it’s usefulIt translates the session’s observed behavior into a quick health indicator you can act on without reading the full report. Use it as your first filter: if the score is High, the run looks clean. If it’s Moderate or Low, read the diagnosis.How to interpret it
  • High — The agent’s behavior during the session was consistent and reliable. No significant concerns were detected.
  • Moderate — Some signals warrant review. The run may have completed successfully, but there are patterns worth understanding before relying on this run’s output.
  • Low — The session exhibited behavior that meaningfully reduces reliability confidence. Review the Primary Diagnosis and Runtime Evidence before trusting the run’s results.
What it showsThe Primary Diagnosis names the main finding for the run. When something went wrong — or when a pattern was observed that could lead to problems — this section describes it in plain language. Each diagnosis is grounded in observed runtime evidence from the session.Why it’s usefulInstead of reading through raw logs, you get a direct answer to the question: what happened in this run? The diagnosis gives you an actionable starting point rather than requiring you to piece together the story yourself.How to interpret itEach diagnosis includes a short description of the finding and a reference to the evidence that supports it. Use the diagnosis label to orient yourself, then navigate to Runtime Evidence if you need to verify or explore the underlying behavior in detail. If no issues were detected, this section confirms that the run completed without notable findings.
What it showsRuntime Evidence is the detailed record of everything your agent did during the session: tool calls made, retries attempted, failures encountered, timing data, and behavioral patterns observed across the run.Why it’s usefulThis is the raw evidence behind the diagnosis. It lets you verify why a finding was raised and trace the exact sequence of events that contributed to it. When the Executive Summary or Trust Score flags a problem, Runtime Evidence is where you go to understand the specifics.How to interpret itLook for patterns rather than isolated events. A single failed tool call may be unremarkable; repeated failures on the same tool, or a cascade of retries, indicates a systemic issue. Pay attention to timing data alongside failure counts — delays often point to external dependencies or resource constraints. Cross-reference what you see here with the Primary Diagnosis to confirm the connection between evidence and finding.
What it showsThe Runtime Timeline is a chronological view of your agent’s activity during the session. It plots events — tool calls, retries, failures, completions — relative to each other in sequence, so you can see not just what happened but when and in what order.Why it’s usefulSome reliability problems are only visible in sequence. A retry cascade, for example, may look like separate events in a flat evidence list but becomes obvious as a pattern in the timeline. The timeline is especially useful for spotting bottlenecks, gaps in execution, or chains of dependent failures.How to interpret itScan for clusters and gaps. A dense cluster of events in a short window may indicate a retry storm or rapid failure loop. A long gap with no activity may suggest a blocking call, a timeout, or a hung dependency. Use the timeline in combination with Runtime Evidence: the timeline shows you when to look, and the evidence tells you what was happening at that moment.
What it showsRecommendations are actionable next steps generated from the run’s diagnosis. Each recommendation is tied to a specific finding and describes a concrete action you can take to address it.Why it’s usefulRather than leaving you to translate a diagnosis into action yourself, the Recommendations section does that work for you. It turns findings into a prioritized checklist you can work through after reviewing the run.How to interpret itTreat each recommendation as directly linked to the finding it references. If you disagree with a diagnosis or believe a finding was a false positive, you can deprioritize the associated recommendation. Work through the list in order — higher-priority recommendations appear first and typically address the most impactful issues. Once you’ve made changes based on a recommendation, run another observation session to verify the behavior has improved.
What it showsRuns History is a list of your previous observation sessions, each displayed with its run ID, trust level, and a short diagnosis summary. It gives you a longitudinal view of your agent’s reliability across multiple runs.Why it’s usefulA single run tells you about one session. Runs History tells you whether reliability is improving, degrading, or stable over time. It also lets you compare runs side by side — useful when you’ve made a change and want to confirm it had the intended effect.How to interpret itLook for trends in the trust level column. Consistent High scores across recent runs suggest stable, reliable behavior. A drift toward Moderate or Low — even without a single catastrophic run — may indicate a gradual degradation worth investigating. Click into any historical run to open its full report and review its diagnosis in detail.
What it showsSettings surfaces configuration options for the current dashboard session, including visibility settings that control how this run is stored and accessed.Why it’s usefulIt gives you control over how individual runs are retained and whether they appear in Runs History. Use it to manage the lifecycle of your reports, especially in environments where you’re running frequent sessions and need to keep history manageable.How to interpret itChanges made in Settings apply to the current run’s storage and display behavior. They do not affect previously saved runs. If you want to exclude a run from history — for example, a test session you don’t need to track — configure that here before closing the dashboard.
A common workflow is Executive Summary → Trust Score → Primary Diagnosis → Recommendations. Use Runtime Evidence and Runtime Timeline when you need to understand the details behind a specific finding.