Your AI Agent Dashboard Should Agree With Your Audit Log

Once agents are reading production, the owner’s question changes from “is it allowed?” to “what is it doing right now?” Which agents are active, what they are reading, how long it takes, and where it fails.

The standard way to build that view is a second set of counters: increment a metric on every request and chart it. We deliberately did not, and the reasons make a decent checklist for anyone building observability for AI agents.

One source of truth

The gateway already writes an audit row for every agent request — the rows behind the activity log, the usage reports and the compliance export. A counter written alongside it is a second write that is supposed to agree with the first. Eventually one fails and the other does not, and the dashboard shows one number while the audit log holds another. From then on nobody trusts either.

So the Live view reads the audit log and nothing else. Every count on it can be reproduced from rows an auditor can export.

Every request leaves a row, including the ones that crashed

That only works if the log is complete, and at first it was not. Some requests never reached the code that writes the audit row: a body that failed validation, an unhandled exception, the abuse guard rejecting an oversized payload. The agent saw a failure. The owner saw nothing.

A middleware now wraps every agent endpoint, outermost, and guarantees at least one row for each request that can be tied to a gateway. It also measures the time to the last response byte and the bytes actually sent, and attaches both after the response has gone, so the agent never waits on it. If a row cannot be written, it is counted as a drop and shown as one. The view is exact or visibly short — never silently short.

Exact percentiles, not histogram buckets

Latency percentiles in most monitoring stacks come from histogram buckets or sketches. Those are good approximations, but a p99 read off buckets can be wrong by the width of a bucket. For one gateway over a window of minutes there is no need to approximate: the view takes the nearest-rank percentile over every request in the window. No sampling.

Windows are 5, 15 or 60 minutes. If a window holds more rows than the view reads, it says the figures cover only the newest rows and suggests a shorter window, instead of quietly reporting a partial number as the whole.

Two clocks, labelled honestly

Gateway time runs from the moment the API received the request to the last byte it sent. Database time is the part spent waiting on the database, including a reconnect when the pool had nothing live.

Neither includes the network between the agent and us, the proxy in front of the API, or the model’s own thinking time. Those are invisible from the server, so the view does not pretend to measure them. When an agent feels slow and gateway time is low, that is useful information too.

“Last seen”, not “connected”

Agent dashboards love a green “connected” dot. MCP over HTTP has no such state: each message is a single POST, and nothing stays open between them. A token that made a request four seconds ago and one that will never call again look identical from the server.

So the view shows when each token was last seen, and how long ago, and never claims a connection exists. It is a less satisfying label and a true one.

From watching to acting

A view you can only watch is half a tool. Failures are split by cause — policy denials, rate limits, budgets, paused tokens — and injection-shield flags are counted separately, so “failing” always has a reason attached. Any agent can be paused from the same panel where you spotted the problem: its next request is refused, and the tokens it delegated stop with it.

The Live view ships in the DBShifts AI Agent Gateway. For what the pause button does under the hood, see Stopping an AI Agent Should Take One Click.