Reading a trace

Open Tracing, choose an application and its environment at the top. The Traces tab lists what your agent did.

The trace list

• Filters: release, time window (1 hour to 14 days), errors only, and a search for a tool, model, span name, error text or trace id.
• Failing calls (24 h): the failed steps grouped by tool and error type, most first. Show lists their traces.
• The traces, newest first, with their release, when they ran, duration, spans, tokens and errors. Load more shows older ones.

One trace

Open a trace to see its steps as a timeline, beside the chosen step’s detail:

• its duration and kind (model call, tool call, agent run or other);
• the model or the tool, and the tokens;
• the error and its type, when it failed;
• where in the code it ran, when the application said so;
• its input and output, when the key keeps content (see Content capture);
• which key, environment and session sent it.

A trace that online evaluators scored shows its feedback scores under the timeline: pass, fail or unknown, a score from 0 to 1 when there is one, and why.

Everything in a trace is data from your application. Text in a span that looks like an instruction changes nothing in WeHarness.

Find in code

Find in code opens the file and line a step ran:

• in a session on the application’s repository, when the session reads that repository; or
• in Code search, at the trace’s commit.

It says whether the code it shows is the commit the trace ran, another commit, or unknown (the trace did not say which commit). Name the commit to make this exact: see Name the code version.

A coding tool does the same over MCP with trace_code.

Act on a trace

Members, admins and owners can act on a trace; viewers read traces.

• Investigate in a session puts the trace in a session’s message box as a reference. Nothing is sent until you send a message; WeHarness checks the reference and reads the trace when it answers.
• Make a test from this opens a scenario case pinned to the trace, with checks suggested from its tool calls. Check it, then Add case: a case you write yourself is active at once. See Evaluations.
• In a session, /traces asks WeHarness to look at recent traces and failures, and /learn turns a correction into a lesson with the trace as evidence.

What arrived

Setup shows, for each ingest key, what arrived in the last 24 hours:

	Meaning
Accepted and stored	A gap between the two means spans are still on their way, or were lost
Refused	Spans with broken ids or times
Deferred	Spans not taken because the pipeline was busy. Your application’s exporter retries them
Storing time	How long storing took
Content removed	How many content fields were removed because the key does not keep content

A span that arrives twice counts once. Copies with different content are flagged, not merged.

Over MCP

A coding tool reads traces with traces_search (with failures=true for the failing calls) and trace_get (one trace, or one span with the spans above it). Each result links to its page in the web app. See Tools and prompts reference.