Detail

One agent, over time: what success means for it, its KPIs and trends, its changes, every run it produced, and whether its setup is complete. Open this from the Agents list when you want to zoom into a single agent instead of scanning the fleet.

What you see

A header with the agent’s name, a status badge, and a node-type badge (orchestrator / specialist / standalone), plus a date-range selector, and the tab row. Ask Morse in the page header starts with Ask about this agent (see Ask Morse).

Under the header, the reason behind the status is written out, with its window. When a change made a measure worse, the agent reads Worth watching and the reason names it, for example Error rate worse after cancel-v6 (+4 pts). See Agent health.

Agent tabs

Five tabs, in this order: Summary · Changes · Runs · Context · Setup health. The page opens on Summary. Summary, Changes, Runs and Setup health are views of /agents/{id} (?tab=changes, ?tab=runs, ?tab=setup-health); Context keeps its own route, /agents/{id}/context, so older links still land. Every tab carries the same ?window=, so switching tabs keeps your date range.

The date-range control offers 1h / 6h / 24h / 7d / 30d / 90d; the Context tab only supports 7d / 30d / 90d, so a finer selection collapses to 7d there.

Summary

What success means for this agent

The top of the Summary tab says what counts as a success for this agent. A person — usually the founder or whoever owns the agent — picks it, without code; Morse does not decide it for you. Until someone does, Morse can’t say whether the agent is working: the panel reads “Say what a good result looks like for {agent}.”

Four steps run along the top: 1 Define success, 2 Connect outcomes, 3 First result, 4 Decide. To define success:

1. Pick what a good result looks like. Two definitions are offered today: A support ticket is resolved and stays resolved and A pull request is merged and kept (for 7 days by default).
2. Under Only judge results when, choose how much of the evidence must be in: outcomes reported on at least 25%, 50% (the default) or 75% of runs.
3. Select Confirm: this is what success means. Confirming records you and today’s date; it doesn’t change your agent or spend anything.

Each confirmation is a new version, and the old one is kept: the panel shows “Agreed by {name} on {date} · version {n}” and a coverage line such as “Outcomes reported on 62% of runs (744 of 1,200, last 30 days)”. Members and admins can confirm; viewers can read it. Changing which definition is used needs an owner or admin. An agent that uses a custom success rule reads Success is defined by a custom rule and is managed in Settings → Outcomes. The demo workspace is read-only.

After it’s defined, the panel tells you where things stand:

• Awaiting outcomes — “Morse hasn’t received any outcomes for this agent yet, so there is no success rate to show. An engineer needs to send them once.”
• Not enough outcomes — “Success rate: not enough outcomes to judge.” with how many runs have an outcome against the share you asked for.
• Measuring — “Judged because outcomes cover at least 50% of runs.”
• Rule changed — when the definition’s rule gets a new version: Review and confirm so results keep their meaning.

Two setup tracks

Defining success and sending outcomes are separate jobs, so the founder and an engineer can each do their part:

• The founder defines success on this panel — no code.
• An engineer instruments the agent. Select Send setup link to an engineer, enter their email (for example dev@example.com) and select Send link. Morse emails them a link to the agent’s engineer setup page. If they aren’t in your organization yet, an admin’s invitation adds them as a member, who can see all of the organization’s data; the invitation works once, for that address, for 72 hours. Up to 10 links per agent per day. I’ll connect it myself opens the same page for you.

The engineer setup page (/agents/{id}/setup, titled Connect {agent}) shows What was agreed and four Steps, each ticking off as data arrives: Send traces, Tag each run with its record, Send what happened to the record (POST /api/v1/outcomes/by-key) and Check it worked — “the same figure the founder sees: runs that have an outcome”. See Record keys and versions and Record outcomes.

The measurement contract

The agreed definition is Morse’s measurement contract for the agent. It decides when a claim about outcomes counts. Outside the success-rate figure itself, an outcome claim — for example in an investigation — stands only when this agent has an agreed definition in its environment, the definition counts the success rate, and outcomes cover at least the share of runs you chose over the last 30 days. Otherwise the claim is withheld with the reason.

KPI cards

Five cards: Runs, Success rate (with a trend delta against the prior window and its basis, for example “312 of 420 judged runs succeeded · last 7 days”), Total cost, Avg cost / run, and Last run.

Orchestration and Operating Summary

An orchestration breakdown panel, followed by the same 4-card Cost / Quality / Reliability / Context & Memory Operating Summary strip used elsewhere in the product, scoped to this agent via agent_id. A card whose measure a recent change made worse reads Worth watching with that reason, and a pending budget sign-off turns the Cost card amber.

Trend charts

Success Rate Over Time and Cost Per Day (or Per Hour, on an hourly range), both scoped to the selected date range.

Changes

History lists this agent’s findings: what your team decided to do about it, when to look again and what the numbers showed since, with each linked change’s verdict lane by lane. When a confirmed change made a measure worse, that lane offers Investigate this change — see Investigations.

Below it, Unexplained changes lists detected changes nobody has explained yet, each with its verdict and Track it, Dismiss and Add why. Add change records a change nothing in your traces marks, and Auto-track detected changes turns on tracking for every detected change. If the agent sends no agent_version, the panel says so. See Follow-ups and decisions and Change verdicts.

Last, What Morse is assuming lists the assumptions behind this agent’s results, which you can override.

Runs

The Runs tab starts with this agent’s failure groups, its inferred-outcome checks and end-user feedback, then the runs table.

Inferred outcome checks

When inferred outcomes are enabled, counting them requires your explicit action for this agent’s success question. Only random spot-checks that Morse selected count toward evaluation: at least 30 runs checked, Agreement (at least) of 70%, and at least eight agreed “no” answers (with at least two from the borderline-”no” group). If more than 15% of checks in a borderline group were skipped, evaluation is blocked. Do the checks in Verify — blind, in the order Morse drew them. Existing reported outcomes and checks you chose yourself cannot qualify the agent. Their diagnostic agreement is shown separately as additional evidence and does not contribute to the check.

How we know. Agreement (at least) is the Wilson 95% lower bound — your checks agree with Morse at least this often — and skipped checks are nonresponse. See the glossary.

Checks apply to the question, judge models, prompt protocol and calibration that produced them. Changing that configuration returns the agent to shadow when its promotion is evaluated; previous checks remain evidence for the old configuration. Older decisions without complete version metadata cannot qualify the current check. Collect new sampled checks before confirming again. Editing the question or rubric asks for confirmation when checks would stop counting. A reset removes only inferred labels from that promotion epoch and preserves reported outcomes.

Promoted outcomes remain inferred, separate from confirmed business outcomes. Promotion does not apply judge-error correction to the reported success rate.

Runs

A paginated table of this agent’s runs — Outcome, Recorded as, Tokens, Cost, Duration, Time — 50 at a time, loaded incrementally. The panel’s meta shows the run count.

Context

The Context tab is this agent’s Context & Memory view.

Setup health

Capture health

Shows whether record keys and versions are captured across all of this agent’s runs in the selected window, not just one: the share of runs with a record key (and per key type), the share of keyed runs that received a record outcome, the share with a git revision and with a configuration fingerprint, and record-outcome events by status (applied, pending, expired, no effect). Every percentage carries its counts, for example “412 of 1,030 runs”.

Gateway signals follow, then a link to the engineer setup page (“Connecting outcomes or tracing? Open the engineer setup page”). Owners and admins see the delete agent section last.

How to use it

• Agree What success means for this agent first; send the setup link to whoever instruments it.
• Pick a date range to re-scope the KPIs, charts, and orchestration panel.
• Switch tabs — the date window comes with you. Context opens this agent’s Context & Memory view.
• Click any trace row to open its full trace; the run shows Back to Agent, which returns you here instead of the generic traces list.
• On the Runs tab, click Load more to page through more runs.
• Owners and admins can delete the agent from the section at the bottom of the Setup health tab. It removes the agent with every trace recorded under it, its alerts and its service targets, after you type the agent’s name to confirm. See Delete agents and traces.

Before you have data

Until this agent has runs in the selected window, the Runs table shows “No runs recorded yet” instead of an empty grid. Until someone defines success, the Summary tab leads with “Say what a good result looks like for {agent}.” and no success verdict is shown.

Related

• Agents — the fleet view this page drills down from.
• Context — this agent’s context makeup and memory effectiveness.
• Trace detail — dissect any one of this agent’s runs.
• Follow-ups and decisions — the History section and how decisions are recorded.
• Set up outcomes — the engineer’s side of connecting outcomes.