AI Agent Observability: What to Monitor

AI agent observability is the practice of knowing what an autonomous agent is doing, whether it is doing it well, and why it did what it did — from the record of each run, not from a hunch that “it seems fine.” For business work, that means monitoring the whole task, not the model call underneath it.

Application observability was built for software that fails loudly. A service throws an exception, latency spikes, a queue backs up — the failure is a signal, and the signal is the alert. An agent fails quietly. It reads the wrong record, applies last quarter’s discount rule, or answers confidently from a knowledge base that went stale two months ago, and every one of those does exactly what a healthy run does: it returns. The response is fluent. The status is success. And the work is wrong.

So the question business and IT teams should ask is not “is the agent up.” It is “is the agent doing good work, and can I prove it.” Those are different questions with different signals. Uptime tells you the agent responded. Observability tells you what it did — which tools it touched, which sources it cited, where it stopped to ask, what it cost, and whether any of that is drifting away from what it did last week.

This post is what to monitor. It is deliberately vendor-neutral on the metrics — the signals apply to any agent program — and it names where an Insulin agent already records the evidence you monitor, and which numbers you compute on top of that record yourself.

What is AI agent observability?

AI agent observability is the ability to answer three questions about an autonomous agent at any time: what is it doing, is it doing it well, and why did it do what it did. It is the difference between an agent you deployed and an agent you can stand behind.

It is not the same as monitoring in the classic sense, and the gap matters. Monitoring watches a system for the failures you anticipated — is it up, is it fast, is it erroring. Observability lets you ask questions you did not anticipate, after the fact, from what the system recorded. For an agent, the interesting failures are always the ones you did not anticipate: not “the API timed out” but “why did it refund the wrong customer while returning a perfectly worded confirmation.” You cannot alert on a failure you never imagined. You can reconstruct it — if the run left a record.

Two rules keep agent observability honest, and both are easy to skip:

Observe the whole task, not the model call. The unit of work is the job the agent was asked to do — read the context, use the right tools, make the change, know where to stop. A trace of the underlying model call tells you tokens and latency. It does not tell you whether the agent completed the task correctly. Monitor the outcome, and treat the model metrics as one input to it.
The record is the ground truth, not your memory of the demo. “It worked when I tried it” is the least reliable evidence in an agent program. Real traffic is ambiguous and adversarial in ways a demo is not. What an agent did last Tuesday at 3 a.m. is knowable only from the run it left behind — so the first observability question is always whether that run was captured at all.

The observability substrate: the run record

You cannot monitor what was not recorded, so observability starts with the record every agent action leaves behind. In Insulin, that record already exists and is the thing you read: every trigger an agent or job fires creates a run, and each run captures what happened — the trigger that started it, what the agent read, what it drafted, and the action a human approved. That is the raw material of observability; the metrics below are what you compute from a stream of these runs.

Two properties of that record are what make monitoring possible at all:

Every run is on the record, including the ones that did nothing. A run that was filtered, rate-limited, or failed is still a row, not a silent gap — which is why the absence of an expected run is as visible as its presence. An observability signal you can only see when things go right is not a signal. The runs table on each job’s detail page is where this history lives, run by run.
The approval step is itself an inspectable queue. Because an Insulin agent holds its consequential actions for human approval, the reversible steps — reading, drafting, planning — run unattended while the irreversible ones wait for a person. Every one of those pauses is a record of a decision the agent chose not to make alone. That queue is not just a safety control; it is a monitoring surface, because the rate at which an agent lands in it tells you how much of the work it is actually handling versus handing back.

Everything that follows is a metric you derive from this substrate — either by reading a run directly, or by computing a rate across many of them.

What to monitor

Score the program on the signals a business owner and an IT owner would both recognize. Each has a why that makes it worth the effort, and a where — the place the evidence actually lives, so the metric is grounded in the run record rather than estimated. Track each on its own; they trade off against each other, and one clean run tells you nothing.

Signal	Why it matters	Where you see it
Task completion	Distinguishes an agent that finishes the job from one that starts it and quietly hands it back. A high response rate with low completion means people are still doing the work.	Rate of runs that completed the task end to end, computed across the run history; the `Completed` vs. `Failed`/`Cancelled` outcomes in the runs table
Escalation / approval-queue rate	Tells you how much the agent is actually handling versus deferring. Rising too fast means it lost confidence or scope; falling to zero can mean it stopped asking when it should.	The human-approval queue — the share of runs that paused for a person, and which actions they were
Correctness / groundedness	Fluent and correct are different things. For work answered from your documents, the check is whether each claim traces to a real source, not whether it reads well.	The cited sources a grounded agent returns — open the citation and confirm the claim is there; ungrounded claims are the ones to sample
Cost per task	The honest unit is the completed task, not the model call. An agent that answers each message cheaply but takes eight tool calls and three retries to finish one job is not cheap.	Tokens and tool calls recorded per run, summed to the task and priced — measured per task, never per message
Latency	Slow work is a failure with a different face, but the bar depends on the surface: an interactive agent lives on responsiveness, an overnight job does not.	The duration recorded on each run; compare against the bar for that surface, not one global target
Error / retry rate	Retries and errors are the leading edge of a regression — the run that “worked” after three attempts is a warning, not a success.	`Failed` runs and the retry counts inside a run’s record; a rising retry rate on a previously clean job is the early signal
Drift	The world moves under a static agent: prices change, a policy is rewritten, a knowledge base goes stale. Yesterday’s correct answer becomes today’s wrong one with no code change and no error.	The trend of the signals above over time — completion sliding, groundedness sampling worse, escalation creeping up — read across the durable history, not a single day

A useful way to hold these: the first six tell you how the agent is doing now, and drift is the one that tells you whether now is different from before. An agent program with no view of drift is one that will be surprised by a slow failure it could have watched arrive.

Completion and escalation: the two rates that describe the workload

Task completion and escalation rate together answer one question a program owner actually has: how much of this work is the agent carrying? Completion is the share it finished; escalation is the share it handed back. Watch them as a pair, because each is meaningless alone.

Completion is not response rate. An agent can respond to every request and complete none of the tasks — it answered, but a person still had to finish the job. Compute completion from the outcomes in the run history: the runs that reached a done, correct end state versus the ones that failed, cancelled, or stalled. A high response rate sitting on top of low completion is the specific pattern that makes a demo look ready and a rollout feel like more work, not less.

Escalation is the more interesting rate, and Insulin gives it to you directly because approval is a first-class step. The human-approval queue is the escalation record — every run that paused for a person is a row in it. Monitor the rate two ways. A sudden climb usually means the agent lost confidence or hit inputs outside its scope, and is worth investigating before it becomes user-visible. A rate that falls to near zero is not automatically good news: it can mean the agent stopped escalating decisions it should still be routing to a human, which is exactly the failure mode a business-focused scorecard weights most heavily. The number you want is stable and appropriate, not simply low.

Correctness and cost: the signals you have to compute, not just read

Correctness and cost are the two signals where the run record gives you the raw material but not the finished metric — you have to do a little work on top of what Insulin captures. That work is worth it, because these are the signals a demo hides best.

For correctness on grounded work — anything the agent answers from your documents rather than general knowledge — the strongest signal is traceability. An Insulin agent attached to a knowledge base returns cited sources, so a response is grounded in your company’s information rather than the model’s guesswork. That turns correctness monitoring into a concrete, sample-able check: pull a set of runs, open the citations, and confirm the claims are actually in the cited source. An answer with no traceable source is not one you can mark correct; it is one you have to re-verify by hand, and the rate of those is itself a signal worth watching. Grade against a ground truth you defined before you looked — reading an output and asking “does this seem fine” is how a confident, wrong agent passes.

For cost, the unit is the completed task, not the model call. Each run records the tokens and tool calls it consumed; the metric you want sums those to the task and prices them, so an agent that takes many cheap calls to finish one job shows up as expensive — which it is. Because an Insulin agent lets you pick the model that suits the work, cost is a dial you set per use case, not a fixed property of “the agent” — so monitor it against the bar for that use case. A quick triage agent and a deep analysis agent should not be held to the same cost line, and the run history is what lets you see the real per-task cost of each instead of estimating from a single call.

Latency, errors, and drift: the signals that warn you early

Latency, error rate, and drift are the leading indicators — the signals that go bad before completion and correctness do, which is what makes them worth watching even when the agent looks healthy.

Latency is the duration recorded on each run, and the only rule is to judge it against the surface. An interactive agent that takes thirty seconds has failed; an overnight scheduled job that takes thirty minutes has not, and trading that latency for a stronger model or more thorough retrieval is often the right call there. Watch for the run that suddenly takes far longer than its neighbours — that divergence is frequently the first visible sign of a problem that has not yet turned into a failure.

Error and retry rate is the same idea one step earlier. A Failed run is an obvious signal, but the quieter one is the run that succeeded on its third attempt: it returned, so it looks fine, but a retry rate climbing on a job that used to run clean is a regression announcing itself. Read the retries inside the run record, not just the final status, or you will mistake a struggling job for a healthy one.

Drift is the signal none of the others give you directly, because it is not about any single run — it is about the trend across many. Prices change, a policy gets rewritten, a knowledge base ages, and a static agent keeps confidently returning the answer that used to be right. There is no exception, no failed status, no alert — just completion sliding, groundedness sampling worse, or escalation creeping up over weeks. This is the entire reason a durable run history matters: drift is only visible when you can compare this month against last, so the value is not the single run you can open but the pattern you can see across all of them.

A note for the IT owner specifically: none of the above requires a bespoke dashboard to start. The run history and the approval queue are the primary sources; the metrics are rates and trends you compute from them. Build the alerting and the charts your program needs on top of that record — but the record, not a tool you have yet to buy, is what makes the monitoring possible.

Frequently asked questions

What is AI agent observability? AI agent observability is the ability to know what an autonomous agent is doing, whether it is doing it well, and why it did what it did — from the record of each run rather than a hunch. For business work it means monitoring the whole task, not just the model call underneath it.

How is agent observability different from uptime monitoring? Uptime monitoring tells you the agent responded. Observability tells you what it did — which tools it touched, which sources it cited, where it escalated, what it cost. Agents fail quietly: a wrong action can return a fluent response and a success status, so uptime alone misses it.

What should business and IT teams monitor for an AI agent? Task completion, escalation or approval-queue rate, correctness and groundedness, cost per completed task, latency, error and retry rate, and drift over time. Track each separately — they trade off — and ground each in the run record rather than estimating it.

Where does the data for agent observability come from in Insulin? From the run record. Every trigger an agent or job fires creates a run that captures the trigger, what it read, what it drafted, and the approved action. The runs table and the human-approval queue are the primary sources; metrics like completion rate and cost per task are computed across them.

How do I detect that an AI agent has drifted? Drift shows up as a trend, not a single failure: completion sliding, groundedness sampling worse, or escalation creeping up over weeks, with no error to alert on. It is only visible when a durable run history lets you compare recent runs against older ones.

Takeaways

Observability is not uptime. Uptime says the agent responded; observability says what it did and why — and agents fail quietly, returning a fluent, successful-looking run that is wrong.
Monitor the whole task, not the model call. The unit of work is the job the agent was asked to do, and the model’s tokens and latency are one input to that, not the measure of it.
The run record is the substrate. Every trigger creates a run capturing what the agent read, drafted, and had approved — and the human-approval queue is an inspectable record of every decision it chose not to make alone.
Watch completion and escalation as a pair: how much work the agent finished versus handed back. A high response rate on low completion means people are still doing the job.
Compute cost and correctness, don’t just read them — per completed task for cost, and by tracing claims to cited sources for groundedness. Grade against a ground truth defined before you looked.
Latency, retry rate, and drift are the early warnings. Drift especially is a trend, not a failure, and is only visible when a durable history lets you compare this month against last.

Ready to monitor an agent from its own record instead of a hunch? See how an Insulin agent is scoped, approved, and grounded, how jobs capture every run for measurement, or get a demo.

AI Agent Observability: What Business and IT Teams Should Monitor