6 improvements that make Grafana Assistant better at helping your workflows

When you ask Grafana Assistant to build a dashboard or investigate an alert, you're doing so because there's work to be done. To do that work effectively, you need the right data, changes you can inspect, and conclusions supported by evidence. You also want Assistant to avoid mistakes and act quickly. Over the past…

Maurice Rochau ۷ دقیقه مطالعهمتن اصلی

%3Aquality(90)%2F&w=3840&q=75) 6 improvements that make Grafana Assistant better at helping your workflows

6 improvements that make Grafana Assistant better at helping your workflows

Maurice Rochau

%3Aquality(90)%2F&w=3840&q=75)

When you ask Grafana Assistant to build a dashboard or investigate an alert, you're doing so because there's work to be done. To do that work effectively, you need the right data, changes you can inspect, and conclusions supported by evidence. You also want Assistant to avoid mistakes and act quickly.

Over the past six months, our team has worked hard to improve what makes those outcomes possible. We’ve changed how agents find context, discover capabilities, edit dashboards, and recover from errors. At the same time, we’ve built better ways to determine whether an improvement actually helps.

These projects are closely connected. Better evaluations reveal where an agent struggles. Those findings guide changes to its tools and context. Production telemetry tells us whether those changes worked and where to look next.

We've been documenting this work on our engineering blog, Unprompted, taking deep dives into the decisions and implementations that went into those efforts. Today, I want to share how those changes have translated to better outcomes for our users.

Dashboarding: faster, prettier, less errors

By mid-2026, dashboarding mode accounted for 27% of Assistant conversations. Users were also telling us exactly where it needed to work better: some operations were slow, consumed too many tokens, or changed things they should have left alone.

The team started by establishing a baseline with Agent Observability and building reproducible tests. Over roughly 10 weeks, the reported dashboarding error rate fell from 2.47% to 0.65%. The 95th-percentile latency for individual operations dropped from 63 seconds to 28.8 seconds, while cost per request fell by 18%.

As Dominik Broj describes in his dashboarding write-up, those results came from repeated, specific improvements. Engineers found failures in production, reproduced them as evaluation scenarios, fixed the underlying problems, and checked the results after rollout. The dashboarding test catalog grew from 78 scenarios to nearly 200.

Learn more: Read Dominik's blog post, "Our journey to improve Grafana Assistant dashboarding mode"

Others build agent loops, we build evaluation loops to get you the best outcomes

That process matters beyond dashboarding. It gives us a way to turn individual reports into improvements that can be tested again whenever the system changes.

An AI agent can produce a convincing response even when its underlying work is wrong. A panel might render successfully while showing the wrong aggregation. An investigation might identify a plausible cause without enough evidence. Evaluating the final answer alone misses much of what determines whether the task succeeded.

In his blog post about building an evaluation loop for Assistant, Yasir Ekinci explains how we separate the behavior we want from the prompts and code that implement it. Scenarios define realistic tasks and success criteria. Graders examine queries, tool calls, saved state, and conclusions. Repeated runs expose inconsistent behavior, and comparisons track quality alongside cost and latency.

That separation gives us room to experiment. We can change a prompt, tool, or model while checking against the same expectations. Coding agents also help inspect failures and propose changes, which go back through the evaluation loop for verification and human review.

Learn more: Read Yasir's blog post, "Building an evaluation loop for Grafana Assistant"

gcx: teaching your local agent how to designing a CLI built for agents

This same principle appears in Ward Bekker’s account of designing gcx. Watching agents use our CLI revealed repeated failures: guessing flags, retrying unsuccessful commands, and requesting far more output than they needed.

The fixes that came with gcx, our CLI designed specifically for agents, which made the interface more informative. Commands describe their capabilities. Errors explain how to recover. Agents can inspect available fields and filter results before bringing them into context. Knowledge that once required a separate playbook increasingly lives in the tool itself, where it can stay aligned with the implementation.

At its core, gcx asks one practical question: what should the interface tell the agent so it can take the next step correctly?

Lowering the context burden

That question becomes more important as the number of capabilities grows. In his post on progressive tool discovery, Cyril Tovena describes how Assistant discovers detailed tool instructions when it needs them. Instead of loading every schema upfront, it starts with compact entry points and retrieves the relevant manual.

Across the full registered tool surface measured in the post, initial tool definitions shrank from roughly 54,500 estimated tokens to 504. That is a 99.1% reduction in that specific context overhead; actual session savings depend on the capabilities available and used.

The broader benefit is that Assistant can gain capabilities without every conversation carrying all their instructions and that your usage gets cheaper: less tokens in the system prompt, less tax upfront. We still measure the complete workflow: smaller prompts are only helpful if discovery does not introduce excessive steps or delays.

Learn more: Read Ward's blog post, "CLIs in the age of agents: how we designed gcx," and Cyril's blog post, "Progressive tool discovery: battling tool overload in AI agents"

Finding stuff doesn’t need to be hard

Your dashboards, alerts, and incident histories contain knowledge about how your systems work. Making that knowledge accessible requires more than placing documents in a search index.

Ioanna Armouti’s story about improving Assitant's search capabilities describes the decisions behind its retrieval system. For dashboards, embedding raw panel JSON drew attention toward rendering details. Representing a panel through its folder, dashboard, row, description, and queries made its purpose clearer. Incident summaries needed different treatment from noisy activity feeds. Permissions needed checking when results were retrieved, because access can change after indexing.

There is a connection here to tool discovery and dashboard editing: all three make relevant information easier to reach while controlling how much enters the agent’s context. More available information helps only when the agent can find and use the right portion.

The investigation team saw that directly when testing against real incidents.

Learn more: Read Ioanna's blog post, "Search, but deeper: how Grafana Assistant finds the right context"

Faster and better root causes with Investigations

Earlier this year we realized that successful tests on synthetic telemetry were insufficient. Real incidents brought incomplete data, competing explanations, and distracting signals.

In his post, William Dumont describes how we borrowed a concept from the world of competitive programming to compare agent variants on resolved incidents and how that exposed concrete problems.

One agent inferred too much from an alert’s name; fetching the actual alert definition gave it a better starting point. Another avoided a useful tool because its instructions described the wrong query language; filtering retrieved background information reduced irrelevant context.

Scores on the internal difficult-incident suite moved from 52% to 69% during a week of iteration. That score measures performance on those benchmark cases. The lasting value is the ability to identify why one investigation succeeds where another struggles—and to keep testing the difficult behavior of acknowledging insufficient evidence. Ultimately, this work, which is ongoing, translates to more reliable recommendations, which builds better trust and leads to better outcomes.

Learn more: Read William's blog post, "Enter the arena: evaluating and improving Grafana Assistant Investigations against real incidents"

Evaluations at scale don’t need to be expensive

As agents began doing longer sequences of work, our original production evaluator increasingly missed failures because it focused too heavily on response text. Yasir Ekinci and Sven Großmann describe the rebuild: show the evaluator more of the agent’s work, let it recognize partial completion, and test its judgments against a stronger reference reviewer.

They then tested Jev, a model designed for structured decisions. It was substantially faster and cheaper, but agreed with the reference reviewer much less well than the strongest generative judge. We retained the stronger judge for the main quality score and introduced Jev as an optional provider with a trace-triage template. Its suitability for that different task still requires representative validation.

That is an important part of experimentation: understanding where a new approach fits, including where the evidence says to keep what already works.

These projects also explain the relationship between Grafana Assistant and Agent Observability. Building and operating Assistant gives us difficult, practical questions about agent behavior. Agent Observability helps us answer them through traces, evaluations, and comparisons—and makes those capabilities available to customers building agents of their own.

Learn more: Read Sven and Yasir's blog post, "Judge Jev: Can a typed-decision model grade your agent?"

Redefining how we work so we can deliver better products quicker

In my post about how we build AI at Grafana Labs, I described our approach as small, meaningful iterations grounded in customer problems. We take the customer problems and try to solve them. Along the way, some things work (that’s the blog post you can read!), some things don’t work—and that’s okay. We want to move quickly, which means we empower everyone to experiment quickly in any direction.

Learn more: Read my blog post, "How we build AI at Grafana Labs: small steps that add up to actually useful AI"

This week at ObservabilityCon 2026, we’ll take all this one step further, highlighting our continued efforts to deliver AI capabilities that help you work smarter and faster. Be sure to register for the in-person event or watch our keynote livestream.

Grafana Assistant is the easiest way to get started with metrics, logs, traces, dashboards, and more in Grafana Cloud. We have a generous forever-free tier and plans for every use case. Sign up for free now!

GL

منتشرشده در

Grafana Labs Blog

خواندن در منبع

ادامه مطالعه