Product · Continuously Improving Agent UX
Improving agent UX, one UI feature at a time.
Agent Outcomes surfaces sessions where an agent is thrashing: long tool loops that repeat, retry a variant, and never converge on an answer. When we spot one, we reconstruct what the agent was trying to do and why the loop wouldn't close — a metric it couldn't name, a log rank that pointed at the wrong service, a correlation it had to build from three separate calls.
Then we guess the UX optimization that would have helped, and build it twice: as a feature in the metrics/logs/traces UI, and as an enhancement in the MCP tooling layer. The bet is that human UX and agent UX are correlated. If a change makes human troubleshooting faster, it almost always shortens the agent's loop too. Four workflows that came out of that process are below.
01 · Metrics · discover by tag
Start with a tag. The metrics come to you.
Mid-incident, you rarely know the exact metric name you need. What you know is a label: the action, the deployment, the customer, the region. Discover metrics by tag turns any label already in your query into a search that returns every metric in the system carrying it. In the lakerunner example, container_cpu_usage grouped by action pulls back six sibling lakerunner_processing_* metrics for action="compaction". Selecting them renders one panel per metric, sharing the query's time window and step.
As an agent tool
Agents don't have to hallucinate metric names. Any label from a prior tool call becomes a search that returns the real metrics carrying it, ranked and ready to plot.
- · Pivot works on any label the current query exposes
- · Selected metrics render as sibling panels, not a stacked series
- · Collapsed panels defer their query until expanded
Step 1 · pivot
Step 2 · paint
02 · Logs · service breakdown
The service that just broke is usually the smallest bar on the page.
Ranking log volume by raw count buries small-but-total failures under noisy healthy services. Cardinal's default sort for distribution by service is error+warn as a fraction of the service's own volume, so a service emitting 37 lines that are 100% at ERROR ranks above a service emitting 5.5k lines that are 3% at ERROR. Each row still shows the stacked segments and the absolute counts, so raw volume is one glance away. The ranking is on rate because that is what on-call scans for.
As an agent tool
Ask an agent "what's broken with logs right now" and the top row is the actually-broken service, not the loudest one. The agent doesn't have to compute rates itself or filter noise post-hoc.
- · Row segments: error (red), warn (amber), ok (green)
- · Aggregate strip: total events, services, errors, warnings, error+warn %, top source
- · Sort key is configurable; error-share is the default because it matches on-call scan behavior
03 · Events · log-to-metric correlation
Overlay log errors on metrics.
The manual version of this pivot is four steps: read the timestamp off the log chart, open the metric explorer, filter to the same service, adjust the time window. Correlate to Metrics collapses that into one action. The metric panel opens with the service, log level, and time window already applied, a banner labelling the payload, and a marker on the source minute. Dismissing the banner returns the panel to its previous query.
As an agent tool
One MCP call that would otherwise be four. The agent gets the metric range already filtered to the log's service and minute, without sequencing separate log-scan and metric-query tool calls.
- · Payload: service, level, time window (±30s default, adjustable)
- · Vertical alignment marker on the metric plot at the source minute
- · Banner is dismissable; dismissing restores the prior query
Step 1 · log rollup
Step 2 · metric view
04 · Traces · service graph
Requests, errors, and latency. The same graph, three shapes.
Most service maps draw one shape (request flow) and stuff errors and latency into badges on the nodes. Cardinal draws the graph as a Sankey and binds ribbon widths to a dimension you toggle. Switching from Requests to Errors re-weights every ribbon at once, so a downstream service producing most of the errors is visually bigger than one producing most of the requests. Operations tiles below the graph share its time window and filter chips; clicking an operation restricts the span sample to that operation without leaving the view.
As an agent tool
The dimension is a parameter, not a re-derivation. An agent asks for the graph weighted by errors or latency and gets it in one call, with attribution already done — no client-side aggregation over span dumps.
- · Width metrics: request count, error count, aggregate latency
- · Node labels: service.name; edge labels: incoming operation where resolvable
- · Operations panel filters spans in-place
Defaults, not opt-ins.
The four behaviors above are on from the first ingest. There is no per-workspace enablement and no separate SKU. Point the Cardinal collector at OpenTelemetry data and open the URL.