A trace shouldn’t be a wall of text

Software has gone agentic in the last couple of years. We are all well versed in writing, testing, and maintaining traditional, deterministic code, but now we also have non-deterministic apps to tend to.

At first it sounds straightforward, but slowly you hit the wall of text. You realize that investigating, debugging, planning, and fixing take a lot of reading, and your AI keeps sending more of it your way. This becomes unmanageable really quickly, even if you instruct the AI to be less verbose or to draw more diagrams.

One particular pain point I have seen with my customers is going through logs or agent traces, looking for an issue. That issue is often buried in one span or message, inside a trace with hundreds of spans, in a batch with hundreds of traces. Yes, you could use AI to do the investigation, read the wall of text that it spits out, and choose to trust the diagnosis. Or you could get your hands dirty and dig through the traces yourself.

Rendering the data accurately

Most of the observability tools out there over-index on the structural accuracy of the trace data. They render a trace as a tree with every single span listed, and show each span’s content and metadata as JSON. Some tools go further. They format the JSON, show the messages as plain text, or add a graph of the flow.

Braintrust, for example, shows the conversation next to the span evidence, and Langfuse groups repeated calls in its graph. These help you navigate.

Yes, an accurate representation that follows the underlying data structure is important. But it does not help much when you are trying to figure out what is going on across hundreds or thousands of traces and find what is broken. This gets even worse with multi-agent setups, where the work moves between agents and the trace becomes a graph rather than a simple tree.

A familiar conversation, with less to read

People are used to reading conversations in chat apps like iMessage and WhatsApp, or on social media. Can we not simplify the conversation between a user and an agent, and render it in a similar way? Some tools already do, and Papaya’s Detail view does too. Yes, you lose some of the structure, but you get a familiar interface that your brain already knows, and that helps.

But a chat layout alone is not enough. You still have to search through a long list of messages, and that is not ideal. That’s where we need information compression, to reduce the cognitive load of reading all those messages, however simple they look. Without actually reducing the amount of information, a better layout can only help so much.

Revealing the detail gradually

Papaya takes the approach of summarizing the agent conversation, and thus reducing it to high-level steps, while preserving the control flow. These trace summaries appear as simplified steps, or milestones, in the conversation.

A summary is an interpretation, so every step links back to the spans it came from. The user can always drill down and check the evidence.

Papaya · Summary

So when users open a trace in Papaya, they first see an overall summary of what happened. They can quickly scan the 3 to 10 summary steps and understand the run. Then they can drill down into any step, or into the ones highlighted as errors.

Clicking a step shows a longer description, and from there they can jump to the exact span. The display switches to the detailed trace view and scrolls to that span.

Papaya · Detail

The complexity is not hidden. It is revealed gradually, as the user explores the areas they care about.

Making AI output easier to consume

With AI, we can write code or generate vast amounts of information and insight at will. But inspecting that output demands our attention. That creates cognitive load, and cognitive load creates friction in adopting AI.

AI can definitely do a better job if it has better context and understands you better. It might speak in visuals or math, if that is what you are more comfortable consuming. But until that is the norm, we have to take deliberate steps to reduce information complexity, like we are doing for trace viewing in Papaya.

If your team spends hours reading agent traces to find one bad tool call, I would like to see that trace. Send it to us, and we will show you what it looks like as a Papaya summary.