Most agent inventories are lists: agents, tools, connections, each with attributes. Lists answer counting questions well and structural questions badly.

The questions that matter during an incident or a design review are structural. If this MCP server is compromised, which agents are affected and what can they reach? Which data sources does more than one agent touch? Is there a path from a public-facing agent to the payments system? Does agent A dispatch to agent B which dispatches back to A?

None of those are answerable from a list, and all of them are answerable from a graph.

What Goes in the Graph

Nodes: agents, tools, MCP servers, data sources (databases, vector stores, object storage), model providers, external services, and human principals or teams as the origins of task flows.

Edges: an agent calls a tool. An agent dispatches to another agent. An agent reads from a data source. An agent calls a model. A trigger — schedule, webhook, user action — starts an agent.

Edge annotations are where the value is. A structural graph tells you what connects to what. An annotated graph tells you how much it matters:

  • Call volume over a window.
  • Cost attributed to that edge.
  • Latency distribution.
  • Policy outcomes: allowed, blocked, guardrail-modified counts.
  • Data classification flowing across the edge.
  • First-seen and last-seen timestamps.

The annotations turn structure into an operational instrument. An edge that appeared last week, an edge carrying an order of magnitude more volume than last month, an edge with a rising block rate — these are the signals worth surfacing, and they are properties of edges rather than of nodes.

Build It From Traffic, Not Documentation

Architecture diagrams are drawn once and diverge immediately. Agent systems diverge faster than most because adding a tool is a configuration change made by a developer in an afternoon.

Derive the graph from observed activity:

From trace parent-child relationships. Spans naturally encode calls: a tool-call span under an agent span is an edge. Cross-service span links give you agent-to-agent edges. This is the most complete source for instrumented fleets. See OTLP telemetry ingest for agent discovery.

From gateway and proxy records. Every governed call is an edge with full attribution — agent, principal, connection, destination, outcome, cost. This source is more trustworthy than telemetry because it cannot be disabled by the agent and it carries the policy decision.

From configuration, as a supplement. Registered connections tell you what is permitted, which is the useful complement to what is observed. The difference between the two graphs is the scope-reduction opportunity: permitted edges with no observed traffic are grants nobody is using.

Keep both graphs and show them together. "Configured but unused" and "observed but not configured" are the two most actionable states, and neither is visible if you only maintain one view.

The Views That Earn Their Keep

Blast radius from a node. Select an agent, a tool, or a server, and see everything reachable from it — one hop, two hops, transitively. This is the first question asked during an incident and the hardest to answer without a graph. For a compromised MCP server, it is: which agents use it, and through those agents, which data sources and external services are reachable. See post-incident forensics for AI agents.

Reverse blast radius. Select a sensitive data source and see every agent that can reach it, directly or through delegation. This is the review question: who can touch the customer database, and by what path.

Shared dependencies. Nodes with high in-degree. A single MCP server used by thirty agents is a concentration of risk and a single point of failure. Shared dependencies deserve stronger controls than their individual importance suggests, and they are invisible in a per-agent view.

Cycles in the delegation graph. Agent A dispatches to B, B dispatches to A. Cycles produce unbounded loops, runaway cost, and cascading failure. They are almost never intentional and they appear through incremental change — someone adds a delegation edge without knowing the reverse edge exists. A graph makes cycle detection a standard algorithm; a list makes it invisible. See cascading failures in multi-agent systems.

Paths between trust zones. Is there a path from an internet-facing agent to a production write capability? Path queries between a source and a sink answer the question that architecture review is supposed to answer, using actual observed edges rather than intent.

Fan-out from a single trigger. One scheduled trigger that starts an agent that dispatches to five sub-agents that each call three tools is a cost and latency structure worth seeing before the invoice arrives.

Diff over time. New nodes and new edges since last week. This is the change-detection view, and it is the one most likely to catch something before it becomes an incident.

Keeping It Accurate

Decay old edges. An edge observed once six months ago is not part of the current topology. Age out edges with no recent activity, and distinguish "removed" from "not seen lately" so the graph does not silently forget seasonal workloads.

Handle identity carefully. The same agent may appear under different names across telemetry sources. Deduplicate on a stable identifier rather than on a service name, or the graph fragments into near-duplicates and every metric is wrong.

Scope per tenant. In a multi-tenant platform, one tenant must never see another's topology. The graph query is exactly the kind of aggregate query where a missing tenant predicate leaks broadly rather than narrowly, so enforce it at the data layer. See tenant isolation with row-level security.

Bound the rendering. A production estate produces graphs too large to render usefully. Default to a filtered view — one agent's neighborhood, or edges above a volume threshold — with expansion on demand. A visualization that draws two thousand nodes communicates nothing.

Annotate with classification. Marking data sources by sensitivity turns the graph into a data-flow map, which is what makes it useful for privacy review and residency questions. See data residency for AI agents.

Using It in Design Review

The graph is most valuable before deployment, not after an incident. A new agent's proposed connections can be evaluated against the existing topology:

  • Does this create a new path between trust zones?
  • Does it add an edge to a data source that no agent of this class currently reaches?
  • Does it introduce a cycle?
  • Does it increase the in-degree of an already-concentrated dependency?
  • Does it create fan-out beyond a configured depth limit?

These are answerable mechanically, which means they can be checks in a review workflow rather than judgments in a meeting. A policy that says "no new path from an internet-facing agent to a production write capability without approval" is enforceable against a graph and unenforceable against a document.

Common questions

How is this different from a service dependency map in APM?

The nodes and edges are similar; the annotations and the questions differ. An APM map is oriented around latency and errors between services. An agent topology map is oriented around authority and data flow: which agent can reach which data under which policy, with what guardrail outcomes. Both are worth having, and the agent view usually needs to include entities APM does not model — tools, MCP servers, model providers, and human principals.

Do I need a graph database for this?

Not initially. Edges stored in a relational table with recursive queries handle blast radius and path questions at the scale of most estates, and a graph database is worth it when traversal depth and query volume make recursive SQL slow. Starting relational and moving later is a straightforward migration; starting with graph infrastructure for a hundred nodes is premature.

How do I represent an agent that acts for many principals?

Keep the principal as a separate node class and treat the agent-principal relationship as an edge with volume, rather than duplicating the agent per principal. Then the reverse blast-radius question — which humans can reach this data source through which agents — is a two-hop query, which is exactly what you want for insider-risk review. See insider threat in the age of AI agents.

What about agents outside our control, in other organizations?

Model them as boundary nodes with limited internals — you know the edge exists and its volume, and you do not know their downstream graph. That is honest and still useful: the boundary node marks where your visibility ends, which is itself information worth displaying rather than eliding. See cross-org agent federation and trust manifests.

How Praesidia approaches topology

Praesidia derives a topology view from observed activity — ingested telemetry spans and governed-connection records — rather than from declared architecture, so the graph reflects what agents actually call. Edges carry the operational annotations that make the graph decision-relevant: volume, cost, latency, and the policy outcomes recorded at the enforcement point, including blocked and guardrail-modified counts.

Because configured connections are also first-class, the permitted graph and the observed graph can be compared, which is what surfaces unused grants for scope reduction and unregistered edges for adoption. Views are tenant-scoped at the data layer, and discovered entities appearing as new nodes can be brought under governance directly. See operations dashboard for your AI estate and the Praesidia documentation.