Agent Trust in 2 Weeks: Part 2, What to Monitor

In Part 1 we learned about how to get traces flowing into your Monte Carlo instance. Now that we have the data ingested, we now must consider what we should actually be monitoring.

MC provides four purpose-built monitor types for AI agents in production. Together they cover the full agent lifecycle: inputs → performance → behavior → outputs, with an additional monitor type to check that structural guardrails are functioning correctly.

With autonomous agent observability within the Monte Carlo platform, monitor setup is driven by the Monitoring Agent. After learning about your agents, infrastructure, architecture, and use cases, this agent will direct you toward a recommended monitor setup. Of course, you have the option to set up monitors manually, as well.

The Monte Carlo monitor types

1. Evaluation Monitors — Monitor Output Quality

Continuously assess the quality and correctness of agent outputs at production scale. Supports LLM-as-judge, deterministic/code-based checks, and MC’s built-in low-code evaluation templates. Runs asynchronously — does not block agent responses. Triggers alerts when output quality degrades over time via anomaly detection.

• Use for: Detecting hallucinations, monitoring prompt/model changes, ensuring response relevancy at scale

2. Metric Monitors — Monitor Performance

Track operational performance metrics across the agent stack. Even when outputs are correct, degrading performance quietly destroys user experience and drives up cost. Metrics monitored include: latency, token usage, error rates, request volume, and span duration.

• Use for: Cost control, SLA enforcement, identifying model or infrastructure regressions before users notice

3. Trajectory Monitors — Monitor Behavior & Decision Paths

Monitor the sequence and frequency of tool calls and execution paths within an agent’s reasoning process. AI agents are non-deterministic — a behavioral issue (skipped step, tool loop, wrong execution order) doesn’t always produce an error but can silently cause incorrect outputs, cost spikes, or security risks. Trajectory Monitors define expected execution patterns and alert when they’re violated.

• Supported conditions: span A occurs before span B, task X occurs more than N times, step Y does not occur before step Z, two steps appear together or separately
• Use for: Compliance/governance use cases (e.g., “did auth check run before data write?”), preventing runaway loops, debugging complex multi-step agent failures

Note: Trajectory Monitors detect deviations from expected execution paths — they are not a runtime security tool and do not prevent prompt injection, jailbreaks, or malicious inputs.

4. Validation Monitors — Monitor Trace Field Constraints

Enforce per-trace and per-span constraints, alerting when individual trace fields violate a rule you’ve defined. Where Trajectory Monitors look at the relationships between spans, Validation Monitors look at the properties of a given trace or span — which model ran, how many tokens it consumed, how long it took. These are the checks that tell you which specific traces broke a rule, rather than telling you that a pattern has shifted.

• Example alerts: model is not in the set gpt-5, claude-3, llama-4; total_tokens is greater than 200
• Use for: Pinning an approved model allow-list, enforcing token ceilings and cost guardrails, catching individual traces that exceed a latency limit

Here’s a helpful way to think about the monitor types as mapped against the main pillars of agent trust

Deciding what monitors to prioritize

The pillars aren’t a checklist to complete top to bottom. Rather, they’re different layers of agent trust as a whole, and which one you prioritize configuring first depends on the specific qualities of your agent.

1. Does your agent answer, or does it act?

An answering agent — one which summarizes, retrieves, drafts, or queries — fails by producing a wrong output that looks right. With this agent type, there are often no error or exceptions thrown, and problems are only noticed when a human identifies a mistaken answer, sometimes days or weeks later. In this case, output leads as a priority pillar to monitor, with context coming in second.

An acting agent — one which writes to systems, calls APIs, files tickets, or moves money — has a more serious failure mode than a bad sentence. It’s a plausible-looking sequence that skipped a step or took the wrong one. In this case, behavior and validation lead as the pillars to monitor first.

Most real agents do some of both, so you should rank your monitoring priorities by how your agent responds when it’s wrong and what the consequences of that are to your business.

2. Where does its context come from?

If your agent is warehouse-grounded — i.e. text-to-SQL, Cortex, Genie, anything reading your tables — you should prioritize monitoring context first, ahead of output. This is because the impact of context errors can be devastating to the entire downstream flow of your agent’s operations, and you may not know until it is too late. A stale table or an unannounced schema change can produce a fluent, confident, yet entirely wrong answer. Every output monitor you build downstream, in the meantime, will be only be showing you a symptom of it, not the root cause.

This is also where Monte Carlo’s agent lineage feature is also critical: an active data quality issue on an upstream table surfaces directly on the agent’s page, which turns a potentially hours-long investigation into a quick troubleshooting exercise.

If your agent is RAG- or vector-backed, lean on output evaluations that check faithfulness to what was retrieved.

If your agent pulls little external context — tool-calling with no retrieval — Context ranks lowest. Skip it and come back if the architecture changes.

3. How often does it run?

Anomaly detection needs a baseline. An agent handling tens of thousands of traces a day builds one quickly, and ML-thresholded monitors on latency and error rate become useful within days.

An agent running a few dozen times a day will not develop that baseline quickly enough, and ML thresholds on it will generate noise that teaches your team to ignore the alert channel. This can be worse than having no monitor at all.

If you are dealing with a low volume agent, start with deterministic monitoring. Validation rules and code-based evaluations are true or false regardless of sample size, and you can add ML-thresholded metric monitors once you have the volume to support them.

The same logic governs evaluations. Every LLM-as-judge run is an LLM call, and individual scores are inherently a little flaky — the same input can score differently on a rerun. Judge them on trend, not on instance, and sample rather than scoring every trace.

Worked examples

Below are three common agent profiles, and for each one, the monitor you would actually build first in practice:

Customer-facing support agent · high volume · RAG-backed

Build this first: an evaluation monitor scoring answer relevance and faithfulness to the retrieved content.

Then, in order: metric monitors on P95 latency and error rate → trajectory monitors on the retrieval step → context evaluations.

Why this order: every answer this agent produces reaches a customer, so silent quality degradation is your most expensive failure mode. High volume also means you’ll have a reliable baseline within days, so anomaly detection starts making an impact almost immediately.

Internal text-to-SQL analytics agent · moderate volume

Build this first: context evaluations on the handful of tables the agent queries most often.

Then, in order: an evaluation monitor on answer correctness → metric monitors on latency and token spend → trajectory monitors on how the agent constructs its queries.

Why this order: failures in this agent type are typically sourced upstream, not in the agent itself. If you build output monitors first, they’ll faithfully alert you to the symptoms of a stale table for weeks while the actual problem sits untouched.

Agentic workflow writing to production systems · low volume

Build this first: a trajectory monitor asserting the required sequence — that the approval step occurs before the write, and that tool calls aren’t looping.

Then, in order: a validation monitor pinning the approved model allow-list, so a silent model swap can’t slip through on an agent that moves money → an evaluation monitor on the action taken → metric monitors on error rate.

Why this order: a wrong action costs far more than a wrong sentence, and it’s the failure that goes unnoticed until it has already moved downstream. Low volume also rules out anomaly detection as a starting point, whereas both trajectory conditions and validation constraints are deterministic and work on day one at any scale.

Day one is not day zero

Before you configure any monitor type, you will still be able to get some insight into your agent’s performance in Monte Carlo. The moment traces land, you get an Agent Summary view automatically – a dashboard which shows you trace volume, latency distributions, token consumption, and error rates.

It’s a good idea to spend the first week reading them rather than building. You’re learning what normal looks like on this agent, and normal is the thing every threshold you set later is defined against. Building monitors on day one means guessing at baselines that you can actually measure by day five.

How to know when you have enough

There are seemingly unlimited factors about your agent that you can monitor, so when is enough really enough to get a reliable picture? Rather than a set number of monitors, consider these guiding questions:

1. Would you find out from a monitor, or from a person? Take your last real agent incident and walk it backwards. If the first signal was a human alerting you rather than a monitor, then you have a coverage gap.
2. When an alert fires, does anyone know what to do? If an alert has no clear instructions that direct the team to act, it isn’t really building agent trust – it’s just noise. Every monitor needs an owner and an obvious first move.
3. Does each pillar have at least one monitor you’d defend? The four key pillars of agent trust span the entire spectrum, from data to outputs, as to what could go wrong with AI in production. It’s important to have at least some visibility across each otherwise you may be blind to certain issues.

When all three hold, you probably have a comprehensive enough monitoring strategy.

Start here

You don’t have to work this out alone, and you shouldn’t have to. We run the first two weeks with you — one pillar at a time, on your agent, against your data.

Next in this series: Part 3 — Traces are flowing. Now what?