Sage: A Conversational Layer for Petavue's Analytics
Petavue connects data from sources that don't normally talk to each other. I designed Sage as the conversational layer on top: ask a question in plain language from wherever you're working, and it reasons across whatever's connected to find the answer.
One experience across different contexts
Sage keeps the same interaction model across the product while inheriting the context of the surface it is opened from.
A dashboard tells you what changed. Users still need to understand why.
The clearest example is a published dashboard. Once a dashboard is published, users still have questions about what caused a change, whether it matters, and what they should investigate next. Sage brings those questions into the same context as the dashboard.
Before Sage
- Ask an analyst.
- Build another report.
- Wait for someone to explain the change.
With Sage
- Ask the dashboard directly.
- Investigate the existing data.
- Continue from the answer.
Where Sage fits
Sage sits after dashboard creation. The dashboard gives users something concrete to investigate, and Sage gives them a way to ask about it.
When Sage opens from a dashboard, keep that dashboard visible beside it, and lock the conversation's context to it the moment a question starts.
The dashboard is the user's source of context. Keeping it visible meant users could ask about a number without losing the filters, date range, or widgets they were looking at, and locking context kept every answer honest about exactly what it was based on.
Change the dashboard mid-conversation and the user starts a new question, instead of Sage silently reconciling a context that already moved.
Designing answers for decisions, not conversation
- 1Finding
- 2Evidence
- 3Recommendation
- 4Guardrail
Sage responses are structured around what happened, what supports it, and what the user can do next. This gives analytical questions enough context to be useful in one pass.
Structure every response around finding, evidence, recommendation, and guardrail, in that order, every time.
A short chat reply works for small talk. It doesn't give an analytical question enough to act on in one pass.
A structured answer takes longer to read than a one-line reply, in exchange for skipping the back and forth a shorter answer would otherwise need.
Making AI answers verifiable
Sage needs to give users an answer without hiding where that answer came from. Plain-language reasoning stays visible by default, while technical execution can be inspected when someone wants to verify the result.
Hide technical execution by default.
Most GTM users need the finding, not the implementation.
Technical users need one extra click to verify the answer.
Designing for the moments between the answer
AI interfaces have more states than a static chat screen. I designed the experience around what happens while Sage is working, when it needs clarification, and when an answer cannot be completed.
I built the interaction before polishing the UI
I used Claude Code to build a working front-end prototype of Sage on the product's real design system. It let me test how an answer streams in, how a clarification interrupts a flow, and how context carries across messages, things a static comp can't show.
Product and engineering reviewed that prototype before a polished Figma file existed. Once the interaction model held up, I refined the visual design and components in Figma.
Outcome
Sage established a consistent conversational layer for Petavue's dashboard and analysis workflows. The work defined how context, reasoning, technical execution, and structured answers should behave across the experience.
Next steps
Dashboards are the only thing Sage can publish and keep refreshed on a schedule today. Reports, Excel, and CSV exports are still a one-time download, and getting them to that same publish-and-refresh state is next.
