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.

Role
Sole product designer
Scope
Product modeling, interaction design, coded prototyping
The Command Center shows which issues need attention and what the agent is investigating.

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.

When nobody knows who needs the data, the question passes between teams—and they keep collecting it.

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.

Overview: prioritize the issues that need attention and see what the agent is already investigating.
Issue detail: keep the affected services, supporting evidence, and available actions together.

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.

The conversation stays on the left; charts and supporting data stay on the right.

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.

  1. DetectFlag the spike and notify the owner.
  2. InvestigateFind the labels causing the increase.
  3. PreviewPreview combining data or removing a label.
  4. 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.

In the app: connect telemetry problems to individual pull requests.
In Slack: review the problem, ask follow-up questions, and make changes when permitted.
In email: send findings and recommended actions to the person responsible.

Make it clear who can approve a change.

Changes to telemetry processing take effect immediately, so the design makes permissions explicit. Admins can make changes; other users need permission from their organization. If a user lacks permission, the interface explains why and lets them tag an admin or forward the request.

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.

Prototype walkthrough · built with the app’s existing components · sample data.

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