This episode brings agent observability to production scale: defining success metrics such as task completion, error rate, and latency; building dashboards for agent activity and tool usage; and setting up alerts for failed actions and anomalous behavior.

Episode 19 taught you how to release agents with a safe pipeline: testable and rollback-able. But a safe pipeline is useless if no one knows whether the released agent is actually working well in the field. The logging in episode 7 is still enough for one agent; for many agents serving thousands of conversations, you need full-scale observability.
Episode 20 covers the three pillars of production observability: metrics that answer "is the agent succeeding", dashboards that display activity and tool usage in real time, and alerts that flag failures and anomalous behavior before they become major incidents. Here is the roadmap for this episode:
Most applications are measured with uptime and HTTP status codes. Agents cannot be measured that way — a request can be technically successful while answering with wrong information. That is why the three core metrics for agents must be understood differently from ordinary applications:
| Metric | What it actually measures | Problem indicator |
|---|---|---|
| Task completion | Percentage of tasks completed within step limits, judged from the final result | The agent routinely fails to finish tasks |
| Error rate | Proportion of conversations ending in error, escalation, or timeout | Model degrading, tool changing, prompt regression |
| Latency | Time from input to final output, including tool call time | Slow tool, ballooning model, uncontrolled reflection loop |
Task completion is the metric that most distinguishes agents from other applications. To measure it, the agent needs to tag its own conversations with the final outcome status, then store it together with the telemetry:
import { metrics } from "@hermes/telemetry";
await agent.run(input, {
onComplete(result) {
metrics.histogram("agent.latency_ms", result.latencyMs);
metrics.increment("agent.tasks_total", { outcome: result.outcome });
metrics.observeConfidence(result.confidence);
},
});Notice the metric pattern above: always label the metric (outcome, confidence) so the dashboard can be broken down per category. An unlabeled metric only tells you "something is wrong"; a labeled metric tells you "where it is wrong".
Raw metrics are useless until visualized. A good agent dashboard has two layers: a summary layer for the operations team, and a detail layer for debugging. For dashboards, Hermes exports metrics in the Prometheus format, which can be consumed directly by Grafana or your favorite observability stack.
scrape_configs:
- job_name: hermes-agents
metrics_path: /metrics
static_configs:
- targets: ["agent-api:9100"]In Grafana, arrange panels that answer business questions, not just display charts:
One dashboard for everything is a recipe for failure. Make at most three dashboards: one for executives (summary), one for on-call (active alerts), and one for engineering (trace details).
Dashboards are only useful if someone is watching them. At night, no one watches — so you need alerts that work tirelessly. There are two classes of alerts for agents: reactive alerts for failures, and proactive alerts for anomalies that have not yet become failures.
groups:
- name: agent-health
rules:
- alert: HighErrorRate
expr: rate(agent_errors_total[5m]) > 0.2
for: 10m
labels:
severity: page
- alert: ToolLatencySpike
expr: histogram_quantile(0.95, rate(agent_tool_latency_seconds_bucket[5m])) > 5
for: 5m
labels:
severity: warning
- alert: ConfidenceDrop
expr: avg(agent_confidence{phase="final"}) < 0.5
for: 30m
labels:
severity: warningThe rules above translate the three signals we have already discussed: high error rate, ballooning tool latency, and plummeting confidence. For proactive alerts, also install simple anomaly detection: compare current metrics with last week's baseline, and alert if they deviate by several standard deviations — for example, the number of escalations suddenly doubling, or the tool usage pattern changing drastically with no release at all.
Warning
Alerts that are too sensitive will be disabled by a tired team, and then the whole system goes blind. Start with loose thresholds and rare pages, then tighten over time. A good alert is one that does not bother you — until it truly is needed.
Metrics tell you that there is a problem, dashboards tell you what is wrong, but to find why, you need tracing. Every agent conversation must have a trace ID that follows its entire journey: from input, planning, each tool call, reflection, to the final output.
hermes log stream --trace-id conv_8f3a --format jsonThis trace ID must also appear in the logs of other applications the agent calls — otherwise it is impossible to connect a user complaint with the wrong tool step. With tracing, incident investigation changes from "watch the dashboard" to "follow the conversation trail": which step produced the wrong answer, which tool returned weird data, and in which phase the agent decided something wrong. This is exactly the provision you need for the next episode on Ops & Governance.
Episode 20 built the foundation of production-scale observability: success metrics that distinguish technical success from functional success, layered dashboards that answer different questions at every level, reactive and proactive alerts that guard the night, and tracing that connects everything into one complete story per conversation.
Key takeaways:
In the next episode 21 we use all these observability signals to run daily operations: incident playbooks, rollback and safe mode, governance policies for agent usage, and documentation of responsible AI practices. See you there!