Sample trajectories on a schedule.
A fixed number of complete runs read end to end each week. Dashboards show aggregates; reading a whole trajectory is what surfaces behaviour nobody thought to measure.
Logs that answer
why.
A record of what an agent called is not enough. Monitoring has to capture what it was reacting to, or no incident can ever be explained.
READ THE DEFINITION ↓TRAJECTORIES · SIGNALS · REPLAY
01 / DEFINITION
The short answer first.What is AI agent monitoring?
AI agent monitoring is the continuous recording and inspection of what an agent does: every tool call, the content that prompted it, the data returned, and the resulting action. Its purpose is not uptime but explanation — being able to reconstruct why a particular action was taken.
Ordinary application monitoring answers whether a system is working. Agent monitoring has to answer a harder question after the fact: why did this system do that? Answering it requires the inputs that shaped the decision, not just the calls that resulted, because the cause of an unwanted action is frequently a piece of retrieved content rather than a bug.
02 / WHAT TO RECORD
The trajectory record.A useful trajectory record is replayable. For each step it holds the objective, the identity the agent is acting as, the tool called with its arguments, the response received, the model's stated reasoning where available, and a reference to the retrieved content in play. Content references matter: when an injected instruction is the cause, the evidence is in the document, and a log without a pointer to it cannot show what happened.
Two practical constraints apply. Full content logging conflicts with data minimisation, so the usual compromise is content hashes and identifiers with the source retrievable from the system of record. And trajectory logs contain the same sensitive material as the agent's inputs, so they inherit its access controls — a log store readable by the whole engineering team can undo the retrieval boundaries the agent respects.
| Signal | What a change indicates |
|---|---|
| Steps per task | Confusion, looping, or a task distribution shift |
| Tool error rate | A dependency changed; recovery behaviour is now in play |
| Scope-boundary events | Attempts to read or act outside permission, successful or not |
| Repeated identical calls | A retry loop the agent cannot exit |
| Proposal rejection rate | Human reviewers disagreeing more often; the leading quality indicator |
| Egress attempts | Outbound requests to destinations not on the allowlist |
03 / SCOPE EVENTS ARE THE IMPORTANT ONES
Denied requests are the signal, not the noise.A denied call
is a finding.
Access-control denials for an agent are not routine noise. They record a system attempting something it was not meant to attempt.
In conventional applications a permission denial is usually a misconfiguration or a user mistake. For an agent it means the model decided to do something outside its scope, and the reason matters: an ambiguous instruction, a confusing tool description, a genuine capability gap, or injected content steering it. Each has a different fix, and all of them are cheaper to find at the denial than at the incident.
Treating denials as findings rather than as noise requires them to be logged with full context and reviewed on a cadence. The rate is also a governance signal: an agent whose scope-boundary events are rising is drifting away from the task its permissions were designed around, which is usually a prompt to revisit AI agent permissions.
04 / REVIEW AND RETENTION
Turning logs into something read.Alert on scope, review on quality.
Boundary events and egress attempts should page someone. Quality signals such as rejection rate belong in a weekly review, not in an alert.
Retain long enough to investigate.
Incidents surface weeks later. Retention has to outlast discovery time, while respecting the retention rules of the underlying data.
A supervision model can also read trajectories, which is part of what MKC2 does: it evaluates AI-generated work and the actions of AI agents, in review-only mode. That makes sampled review affordable at volumes where a human sample would be too thin to be informative — provided the supervisor's own ranking quality has been measured, which is the argument in AI model supervision.
05 / QUESTIONS
Asked when an agent reaches production.What is the difference between agent monitoring and model monitoring?
+
Model monitoring watches output quality and input distribution. Agent monitoring watches actions, access and trajectories. An agent can produce perfectly good text while reading records it should not touch, and only the second kind of monitoring shows it. See AI model monitoring.
Should agent trajectories be logged in full?
+
Structure in full; content by reference where the content is sensitive. Hashes and document identifiers preserve the ability to reconstruct a run without duplicating confidential material into a second store with different access controls.
How long should trajectory logs be kept?
+
Long enough that an incident discovered weeks later can still be investigated, and no longer than the retention policy of the underlying data permits. Those two constraints often conflict, and resolving it deliberately is better than defaulting to whatever the logging tool does.
Can agent monitoring detect prompt injection?
+
It can detect the effects: unexpected tool calls, scope-boundary events, egress attempts, sudden changes in behaviour mid-run. Detecting the injected instruction itself requires inspecting retrieved content, which is why trajectories need to reference their sources. See AI agent prompt injection.
Who should read agent logs?
+
Whoever owns the agent, on a schedule, plus security for boundary and egress events. Logs nobody reads are storage cost, not a control, and the weekly sampled read is what makes the rest of the telemetry meaningful.
Keep a record
that explains itself.
Privilege AI builds systems where retrieval boundaries, actions and evidence are part of the architecture rather than an afterthought.