Grafana Assistant — Product Proposals

Outline

Grafana Assistant as an Intelligence API

Problem

Grafana Assistant today is primarily accessed inside the Grafana UI, intended for human driven investigations.

However, there is room for improvement in workflows where an agent is intended to steer the debugging and operations that follow. Not only to improve external agents' ability to correspond with Grafana Assistant but also allow developers who strictly stick to their terminal to code and use agent harnesses (Claude Code, Codex, etc) to have their agents lead those investigations.

Grafana Assistant is currently designed primarily for human facing interactions. However, developers who predominantly spend their time on their terminal would benefit strongly from a CLI interface that integrates right into their workflows.

Proposal

Introduce a Grafana Assistant Intelligence API, with an official CLI as the reference client.

This would allow external tools to query Grafana Assistant directly and receive structured investigation results.

Example: Terminal investigation

grafana-assistant ask "why did API latency spike in last 30m?"

Returns structured output:

{
  "summary": "...",
  "likely_causes": [...],
  "affected_services": [...],
  "related_dashboards": [...],
  "recommended_queries": [...]
}

Why this matters now

The developer tooling ecosystem is undergoing a major workflow shift. Grafana Assistant already supports turning investigations into code changes using GitHub's MCP, however, opening support for developer first environments, i.e. devs prompting their agent to use Grafana Assistant from the terminal opens pathways to newer users.

Inspiration

The growth of CLI native agent harnesses is not new (OpenCode getting 100k GitHub stars in the span of a few months) and it is evident what follows that are tools that support these workflows:

Tweet by @steipete

Tweet by @elliotarledge

Problem

Linting is a standard component of modern developer workflows. As prompt driven interactions become increasingly common, introducing prompt linting is a natural next step to help users get the most from Grafana Assistant, whose effectiveness depends heavily on prompt quality.

In practice, many users do not refine their prompts and are often:

• Vague
• Missing scope or @ context
• Missing time ranges
• Missing environment context

Weaker prompts lead to:

1. Slower investigations
2. More work for the agent
3. Inconsistent Assistant results

These cases reduce trust in Assistant generated results and create frustration with AI assisted observability, even when the root issue is prompt structure rather than model capability.

Proposal

Unlike traditional observability queries (PromQL, LogQL), prompt driven observability has no structured guidance for instruction quality. This feature would introduce an LSP backed prompt linting workflow to bridge the gap between bad and good prompts.

For a Grafana Assistant specific solution, use a hybrid approach: run static checks first, then use LLM analysis only when meaning inference is required.

Example: if prompt is "why is the registration gateway slow", run intent classification and slot extraction, then apply rule checks:

if intent = investigation and time.range = null -> warn

Suggestions could include:

• Time window
• Environment
• Data source context
• Latency percentiles

Inspiration

This concept was actually inspired by a great PM at VS Code, Pierce Boggan, on prompt linting support for prompt files: microsoft/vscode#294986. I read his PR a couple of days ago and a lot of the thoughts/design resonated with me.

That implementation combines static analysis (for things like oversized prompts and vague wording) with LLM based analysis. A Grafana adaptation would follow the same pattern with observability specific checks.