Sawmills.ai
AI-Agent Command Center for Observability Platform
I turned a chatbot into a command center where developers and DevOps can investigate issues and preview changes before acting.
The problem
Teams needed more than a recommendation to change a live system.
Recommendations and supporting data were buried in chat. Teams had to check conversations, dashboards, and telemetry settings to understand a proposed change. DevOps and developers also needed to know who used the data and who could approve a change. Without those answers, they kept the data to avoid breaking something.
The product model
One issue. Its investigation.
The evidence to act.
Users ask questions in chat. Alongside the conversation, they can see the supporting data, decisions, and a record of what the agent has done.
- Issues
- The problem, how serious it is, what it affects, and who owns it.
- Sessions
- An investigation that keeps the conversation and evidence with the issue.
- Evidence
- Data, charts, and previews that help users check a recommendation.
- Tasks
- Scheduled or recurring work the agent carries out.
- Context
- The team’s rules and limits on what the agent can do.
DevOps sets the rules: what the agent can change on its own and when it needs a person’s approval.
Design decisions
Give every investigation a place to start—and a record to return to.
Each issue has its own page. Users can see how serious it is, which services it affects, who owns it, and what has happened so far.
Conversation and evidence
Ask questions in chat.
Check the evidence beside it.
Users can ask follow-up questions while keeping the relevant charts, data, and change previews in view. They can check a recommendation without scrolling back through the conversation.
Preview before applying
Show what a change would do before applying it.
I designed a preview step so users could see the expected effect of a change on their telemetry. The team’s rules would determine whether the agent could apply it or needed approval.
When a metric label creates too many unique values.
A metric label with many distinct values can sharply increase the amount of data a team stores. This is a cardinality spike. The proposed flow helps the owner investigate it and preview a fix.
- DetectFlag the spike and notify the owner.
- InvestigateFind the labels causing the increase.
- PreviewPreview combining data or removing a label.
- ActApply the approved change, record it, and allow it to be undone.
Across the workflow
Help teams act in the tools they already use.
I designed connected workflows in the app, Slack, and email. Teams could connect a telemetry problem to a proposed code change, investigate it in Slack, and receive recommendations by email.
The working prototype
A working prototype
built in the existing app.
The prototype used the app’s real interface components and navigation, with sample data instead of live telemetry. People could investigate an issue, try an action, and see the result without leaving the prototype.
Tested with 5 participants
I tested the prototype with five people from design partner and customer teams. They gave positive feedback on the proposed experience.
A clearer path to self-service
Feedback suggested that developers and DevOps could handle more changes themselves if they could check the evidence, preview the effects, and see who was responsible. That could mean less back-and-forth between teams.
What comes next
Cover more problems. Keep responsibility clear.
Next steps included covering more data-quality problems and helping teams fix them in the services that generate the data. I also wanted to show which systems depend on that data and explore whether AI could generate charts and data views suited to each investigation.
The product foundationExplore Sawmills from 0→1View all work