How to build a trust platform for your agent with Grafana Agent Observability

Observing fast-growing agentic workloads is no small feat, especially if you try to build your own monitoring stack or rely solely on tools built for a time before LLMs.

At Grafana Labs, we know this all too well. 

Grafana Assistant went from an internal hackathon project to generally available in a little over six months. And while it was great to see how eager our users were to adopt it, that interest came with plenty of growing pains as we managed scaling and complexity behind the scenes. Reviewing contributions to the prompt, tool set, and agent harness became a nightmare as changes piled on from multiple teams. Bespoke dashboards just weren’t cutting it. (You can read more about our experience in this post on Unprompted, our new engineering blog.)

If you’ve been building agents, you’ve probably faced some similar frustrations. The good news? You don’t have to blindly walk through the same growing pains that we did. We built Agent Observability as an internal tool to address these challenges, and today we’re making it generally available to Grafana Cloud users to help you watch your agents, test their behavior, and step in when something’s off. 

But having the right tool is only the first step. This post will document guidance and best practices for building a robust trust and monitoring setup to monitor your own agents, based on the phases we went through building Assistant.

Phase 0: Early prototype and initial deployment

It’s exciting to start with a fresh idea, pick an agent framework, and say the first “Hello, world!” to a new agent. In fact, you can get surprisingly far by adding tools and single-shot examples to the system prompt, then doing some simple Q&A testing.

After getting the agent to a place where it generally feels solid and helpful, you can run an initial benchmark or test suite with a barebones set of use cases the agent needs to address. But once it’s deployed to production for the first time and the first issue appears, the cracks start to show. A customer may reach out regarding a strange conversation or an internal user might message on Slack with a screenshot of a conversation that went off the rails. How do you begin to troubleshoot this?

The next step in development is making sure that these conversations can be found and triaged efficiently. Like traditional software monitoring, this is done through instrumentation of the agent’s code.

Phase 1: Monitoring live traffic

There are two main facets that are important to monitor when observing an agent. The first is traditional engineering metrics such as latency, cost, number of tokens, and errors. These metrics can give developers a sense of the general maintainability of the agent, identify cost anomalies, and do an initial round of improvements to the agent, such as reformatting the prompt to introduce prompt caching and save on tokens. When the finance department comes down to the engineering team and asks for the costs to maintain an agent, this step will provide the answer.