Performance brief first. Traces on demand.

Open most agent tooling and the first thing you see is a list of traces. Thousands of them, newest first, each one a faithful record of what an agent did.

Traces are essential. We build a trace viewer and we use it every day. But a list of traces is not an answer. It's the raw material for one. If you run several agents in production, the question you start the week with is not "what happened in run 48,213?" It's "which agent should we work on, and why?"

So Morse opens on a different page. Our operating phrase for it is: performance brief first, traces on demand.

Why not lead with traces

A trace-first workflow puts the prioritization work on you. To decide which agent needs attention, you have to:

• pick a time window and remember what the last one looked like;
• filter by agent, then by status, then by cost;
• read enough individual runs to tell a pattern from a one-off; and
• keep business outcomes, spend, and quality scores in your head at the same time, because they usually live in different places.

That's real work, and it's the same work every week. Teams with one agent can do it by feel. Teams with five or ten can't, so the review quietly stops happening and the spend keeps growing.

The performance brief does that first pass for you. It ranks agents by how much attention they deserve, using labeled production outcomes, spend, production-success trends, and separate sampled quality signals. You start with an ordered list and a reason for each position, not a search box.

"On demand" is a promise about evidence

Leading with a brief only works if you can trust it. A ranking you can't check is just someone else's opinion.

So every claim in a brief is meant to be opened:

• Each ranked item names its sources. Which signals it used, over which time window, with how much coverage.
• Each ranked item links to evidence. The traces behind the outcome numbers, the runs behind a cost change, the sampled runs behind a quality signal.
• Gaps are shown, not filled. If there aren't enough labeled outcomes to judge an agent, the brief says "Not enough labeled outcomes" instead of guessing. If no outcome can be confirmed, cost per successful outcome stays empty instead of reading as zero.

We'll be direct about one thing: "traces on demand" does not mean you'll never need traces. You will. The point is that you open them because the brief gave you a reason, and you know which ones to open.

What you see when you click through

Clicking from a ranked item lands you in the agent's traces. A trace in Morse is built from typed spans — agent, LLM, tool, HTTP, database, and custom — in one waterfall. A few things in that view do a lot of the explaining.

Infra evidence inside the agent trace

When an agent is slow or failing, the cause is often not the model. It's a slow query, a failing API call, or an error in a log line. Morse puts those signals inside the agent trace, not on a separate dashboard you have to line up by timestamp.

Concretely, database and HTTP spans that share the agent's trace ID render in the same waterfall as its model and tool calls, and logs that carry the trace ID are joined to it. Infra spans are also labeled by what they mean to the agent framework. A SELECT against a checkpoints table is labeled as the framework saving state, which is different from the agent doing its own database work.

This is deliberately narrow. Morse correlates infra signals that belong to an agent's trace. It is not a standalone metrics or logs product, and it doesn't do fleet or Kubernetes monitoring. Host metrics, for example, are not joined to traces by trace ID, so we don't present them as if they were.

Deploy markers

The Morse SDK picks up the commit SHA your CI or hosting platform already sets, and Morse records a deploy the first time it sees a new one. Those markers show up on the quality timeline, so "did this change after Tuesday's deploy?" is a glance instead of a git log search.

A marker shows when something shipped. It doesn't prove the deploy caused the change. When a number moves and no deploy lines up with it, the brief describes the change and stops there.

Context and memory

For agents where the context window is the problem, the trace view shows how much of the window each run used and where it went. When the context bloats, Morse can point to the tool result that put the extra tokens there. That turns "this agent got expensive" into "this tool started returning much larger results," which is something you can act on.

How the two halves fit together

The brief and the traces are the same evidence at two zoom levels.

1. Brief. One ranked list for the week. Outcomes, spend, and sampled quality kept separate, each with its source and coverage.
2. Agent. The agent behind a ranked item: its trends, its deploy markers, its open issues.
3. Trace. The individual runs, with model calls, tool calls, database and HTTP spans, and logs in one place.

You can stop at any level. Most weeks the brief is enough to pick what to work on. Some weeks one ranked item needs ten minutes in the traces. Occasionally it needs an afternoon. The brief doesn't remove that afternoon; it makes sure you spend it on the right agent.

Then the loop closes. You make one change, and next week's brief re-measures the same signals over a comparable window. If the numbers moved, the evidence for the movement is one click away, the same as before.

The trade-off we're making

Leading with a brief means making a judgment for you, so we hold that judgment to a few rules. The ranking is an attention order, not a fused cost × quality score. It reports observed movement, not verified root causes. And when the evidence is thin, it withholds rather than bluffs.

If those rules ever conflict with looking confident, the rules win. A brief you can open and check is worth more than one that sounds sure of itself.

That is the shape of Morse: AI-agent observability and evals that start with the decision and keep the evidence underneath it. If you run agents in production and want to see a brief on your own fleet, join the waitlist.