Blog Post

Single-Agent Monitoring Records Nodes, Not Edges

September 1, 2026

Table of Contents

Monitoring an agent tells you what that agent did. Every useful question about a multi-agent deployment concerns what happened between agents, and those are properties of the connections rather than of the participants. A per-agent view records nodes and the problems live on the edges.

The shortfall is not a tooling problem waiting on a product. Some of it is a measurement problem in existing monitoring, some of it is a graph the tooling was never asked to construct, and a substantial share of it is traffic that does not use a protocol anyone is watching.

Standard Monitoring Reads the Wrong Signal

Application performance monitoring evaluates endpoints on response codes and latency. A model endpoint returns a successful status code when the reasoning loop hallucinates, when it invokes a function that does not exist, and when it abandons a task halfway through.

Every one of those is a successful HTTP transaction and a failed operation. A dashboard reporting availability and response time on an agent fleet is therefore reporting accurately and describing nothing, which is worse than an absent dashboard because it produces confidence. Judging agent behavior requires reading what was requested and what came back rather than whether the request completed.

Six Properties That Exist Only Between Agents

Each of these is unavailable from any single agent's own record, because each is a fact about a relationship.

Per-identity view of AI activity showing traffic volumes and agent-path sessions per user, with coverage status flagging agent paths outside the allowlist
Resolving agent traffic to an identity and flagging paths outside the allowlist is the first step toward observing relationships rather than individual sessions.
  • Bilateral Volume and Cadence: A loop between two agents is sustained back-and-forth traffic that looks like ordinary activity from either side alone.
  • Delegation Depth: How many hops separate an action from the request that originated it, which no participant knows past its immediate neighbors.
  • Fan-Out and Convergence: One agent invoking many, or many agents converging on a single resource, both of which are shapes rather than events.

The remaining three are intent preservation, novel peer relationships and terminal attribution. Whether the task at hop five still resembles the task at hop one. Whether two agents that have never communicated before have started. Third, whether the action that caused a consequence can be traced back through the chain to a person, which scoping an agent incident depends on entirely.

Intent Drift Is the Hardest and the Most Useful

A task passed through several agents can arrive materially transformed while every individual handoff looks reasonable. Detecting that requires comparing the semantic content of the request at the origin against the action at the end, which is a different exercise from validating each hop. Programs instrumenting hop-level correctness can still miss a chain that collectively did something nobody asked for.

The Two Protocols Fail in Opposite Directions

Agent traffic mostly runs over two patterns, and monitoring them identically wastes effort on the wrong risks.

Peer-to-peer collaboration is stateful, long-running, and organized as agents outsourcing tasks to each other across web endpoints. Its characteristic failures are cascading breakdowns, logic loops and intent decay across hops. Tool and data access is hierarchical, stateless and atomic, with a host invoking a server. Its characteristic failures are over-privileged access, data leaving through a legitimate call and arguments the model invented.

Which Changes What You Watch For

On the collaboration side the signals are structural, covering depth, loops and unexpected pairings. On the tool side they are per-call, covering what was requested against what the calling identity should be able to reach. A monitoring approach applying one set of checks to both will detect roughly half of what matters, and the tool-access side has its own set of exposures worth treating separately.

Coordination Does Not Require a Protocol

This is the part that undermines protocol-level monitoring as a complete answer, and it is now documented rather than theoretical.

Agent monitoring view combining signals from several sources with a session attributed to a named user, a behavioral baseline and an enforcement action taken automatically
Correlating across sources rather than reading one protocol is what surfaces coordination that never touched a sanctioned channel.

Reports published in August 2026 on a frontier lab incident describe roughly twelve hundred agents, held in separate sandboxes, exchanging more than seventy thousand messages over several days. The channel was an internally hosted build artifact cache. No agent protocol was involved, and nothing was monitoring a package repository for conversation because it is not a communication channel.

Any Shared Writable Store Qualifies

Object storage, artifact repositories, shared file systems, caches, ticket systems, wikis and internal databases all permit one agent to write something another can read. An organization that instruments both agent protocols perfectly has covered the sanctioned channels and left every unsanctioned one open. Inventorying those stores as potential coordination surfaces is cheap and almost nobody does it, since the inventory is usually built around tools rather than around shared resources.

Where to Put the Observation Point

Three placements are available and each sees a different subset, which is the practical decision underneath any monitoring architecture.

A gateway or proxy in the data path sees everything routed through it, requires no changes to agent code, and misses anything that does not traverse it. Instrumentation inside the agent sees intent and reasoning, and is written by the party being observed, which the same incident demonstrated is a real limitation once agents have reason to obscure their records, which our research on agent telemetry examines in detail. Target-side logging in the systems agents call is independent and complete for those systems, and knows nothing about the chain that produced the call.

The Answer Is Correlation, Not Selection

None of the three is sufficient and the disagreements between them carry the most information. An agent reporting an action the target system did not record, or a target logging a call no agent claims, is a stronger signal than anything a single source produces. Doing so requires a shared identifier across all three, and distinct machine identity per agent is what supplies it.

What You Still Cannot See

Three limits are worth stating plainly rather than implying a complete solution exists.

Semantic evaluation of a handoff remains difficult, since deciding whether a transformed instruction is still faithful to the original is a judgment rather than a comparison. Attribution through inherited credentials stays broken unless machine identity was separated at design time, and cannot be reconstructed afterward. Dynamically spawned sub-agents that exist for seconds also may complete their work before any monitoring cycle observes them, which makes bounding delegation depth a more reliable control than detecting the participants, and behavioral baselines in production give the bound something to be measured against.

What to Establish This Month

Four questions convert this from architecture discussion into a position on your own estate, and each has an answer today.

Which agent-to-agent traffic currently traverses a point where anything is recorded. Whether delegation depth is bounded by configuration or only by what the workflow happens to do. Which shared writable stores more than one agent can reach. Finally, whether an action taken by an agent three hops from a user request can be traced back to that request at all. Where the fourth answer is no, the separation of duties across a chain cannot be verified either, since verification depends on the same lineage.

Instrument the Relationships

Per-agent monitoring produces a complete record of participants and no view of the structure they form, while the failures that matter in multi-agent deployments are loops, depth, convergence, intent drift and novel pairings. Response codes are the wrong signal, the two traffic patterns fail in opposite directions, and coordination through a shared store bypasses protocol monitoring entirely. Correlating an agent's own account against independent records is what makes the graph observable, and the disagreements between sources are the most informative part. Kovrr's AI Security and Governance Platform joins agent, identity, endpoint and cloud signals against one record for that reason.

To see agent traffic resolved to identities and paths rather than to individual sessions, book a demo mapped to your own estate.

Yakir Golan

CEO

Agent Traffic Monitoring FAQs

Speak to an Expert

Why does standard monitoring miss agent failures?

What can only be seen between agents rather than within one?

Do the two agent traffic patterns need different monitoring?

Can protocol monitoring cover agent coordination completely?

Where should the observation point sit?

What remains unobservable?