Reading the run page

Open any run under Agent executions and the page is laid out to be read in one direction — from what the agent was asked to do down to the individual spans. This tutorial walks the page top to bottom and explains what each block is reading from, so you can tell the difference between "the agent did nothing here" and "nothing was recorded here".

1. The outcome header

The first block on the All tab is the agent's own account of the run, in this order:

Row	What it answers	Where it comes from
Task	What was it asked to do?	result.task
Outcome	What did it conclude?	result.summary
Couldn't do	What did it fail to do while still finishing?	result.degraded[]
Proposed actions	What does it want done next?	result.actions[]
findings / artifacts	How much did it produce?	result.findings, result.artifacts[]

All of it comes from the structured result the agent hands back at the end of its run. In the SDK's context-manager mode that is one call:

import waxell_observe as waxell

with waxell.context(name="ops.sre.otlp-debugger") as ctx:
    ...
    ctx.set_result({
        "task": "Check the OTLP pipeline is healthy",
        "summary": "All three legs healthy; p95 ingest latency 412 ms.",
        "degraded": [],                       # strings — one per thing you couldn't do
        "actions": [                          # what you want a human (or another agent) to do
            {"action": "raise-alarm-threshold", "target": "otlp-ingest-p95"},
        ],
        "artifacts": ["OTLP health report"],  # titles of things you produced
        "findings": 3,                        # a count, or a list
    })

Only the keys you set are rendered; a run whose result is free text ({"response": "..."}) keeps its existing result panel and the header stays out of the way. If Couldn't do has any entries the header turns amber and the run's status will read Degraded (see below) — the two always agree because they read the same list.

Lead with the task

Record the task as the first step of the run as well (ctx.record_step("task", {...})). The trace tree then opens with the same line the header does, and the AI narrator uses it to judge whether the outcome actually answers the ask.

2. Run status is three-state

Status	Meaning
Completed	Finished and did everything it set out to do.
Degraded	Finished, but result.degraded is non-empty — part of the job didn't happen (a read that 403'd, a provider that stubbed). Amber, never green.
Failed	Raised, timed out, or was killed.

Degraded is set by the server when the SDK reports success with a non-empty degraded list. Filter for it on the executions list (status=degraded) or with wax runs list --status degraded.

3. The governance verdict

The Governance tab opens with a verdict banner. Its neutral states are deliberately distinct:

Banner	What it means	What to do
No Policies Configured	Nothing applies to this agent yet, so nothing could be evaluated.	Create a policy — the next run will be governed.
Policies Not Evaluated on This Run	Policies exist, but no governed checkpoint fired: the agent never crossed a governed surface, or this is an observe-only run.	Nothing wrong. If you expected a checkpoint, check the agent is actually routing through the governed surface (gateway, tool call, model call).
All Policies Passed	Policies were evaluated at one or more checkpoints and none warned or blocked.	—

The banner's second line always states the counts it is reading (N policies configured, evaluated across N checkpoints), so you can verify the label against the numbers.

4. When an LLM call shows no prompt or response

Click an LLM span and, if there is no content to show, the detail panel says why rather than leaving the section blank. The reason is derived from the workspace's content capture setting (Settings → Data & privacy), which is applied server-side when the span is stored:

Content capture	What is stored	What the panel says
Full	The prompt and response as sent.	If the span is still empty: the SDK didn't send content — WAXELL_CAPTURE_CONTENT=0, an older SDK, or an auto-instrumentation that doesn't capture this provider.
Redacted	A fingerprint only: { _redacted: true, sha256, len }.	"Prompt and response were fingerprinted, not stored."
Off	Nothing.	"Content capture is Off."

Because the fingerprint is stored under Redacted, you can still prove that a call happened with a given payload (matching the digest) without the platform ever holding the text.

5. "Couldn't load …" lines

Panels on the run and agent pages that fetch their own data — behavioural analysis, policy activity, compliance, conversation journeys, the improve strips — now say Couldn't load ‹panel› — ‹reason› in a single muted line when their request fails. Previously they rendered nothing, which was indistinguishable from "no data yet". If you see one of these lines, the panel is broken or unreachable, not empty; the reason is the server's error text.

Where to go next

• The story of a run — how the narrator turns the same run into a paragraph.
• Narrate with the context manager — the full set_result / record_step / record_decision surface.
• Config health: the doctor — when the problem is a key or a provider rather than the run.