Ontology-Driven Observability for Agentic Monitoring

Ontology-driven observability extends traditional observability by providing a connected view of system components through a shared model. This model includes services, databases, users, infrastructure, and their relationships, represented as triples in a knowledge graph. The triple format consists of a subject, predicate, and object, such as "checkout-service → depends_on → payments-db."

Even without AI, ontology-driven observability can aid incident investigation. For instance, if a payments database becomes unavailable, the graph can identify affected services, estimate the impact, correlate the incident with service health, and alert the responsible teams with the relevant dependency context. This approach employs deterministic, rule-based monitoring, leveraging the knowledge graph for context while predefined queries and rules perform the analysis.

When introducing LLM-powered agents, ontology-driven observability enables them to investigate incidents dynamically. Upon detecting increased checkout latency, the agent can query the knowledge graph to understand which services are affected and how they depend on each other. The agent can then investigate related metrics, logs, traces, and deployment events to form a root-cause hypothesis. This investigation can be performed by multiple specialized agents working together within a multi-agent workflow.

The workflow begins with detection, followed by exploring dependencies, investigating telemetry, correlating evidence, and finally recommending actions. This approach aligns with Netflix's E2EGraph initiative, which focuses on knowledge-graph-backed observability and agent-assisted root-cause analysis at scale. While the knowledge graph provides structured context, it does not automatically prove causation; the agent must still validate its hypotheses against actual telemetry.

The decision to adopt ontology-driven observability depends on the system's complexity. It is particularly valuable when incidents span multiple services, infrastructure layers, and teams, when telemetry is scattered across various tools, and root-cause analysis requires understanding complex dependencies. For smaller systems, conventional observability practices with consistent instrumentation, useful tags, and distributed tracing may suffice.

Implementing a knowledge graph introduces additional costs, including ontology design, data integration, graph maintenance, and governance.

Before deploying agentic monitoring, it is advisable to test the system in a sandbox or staging environment. The knowledge graph and observability pipeline can operate in a production read-only mode, allowing agents to query approved telemetry and propose explanations without making changes to the system. Controlled remediation actions, such as restarting services or rolling back deployments, should be introduced with strict permissions, independent validation, and human approval where necessary.

Sandboxing and least-privilege access help mitigate the risks associated with incorrect reasoning or unintended tool calls.

In summary, ontology-driven observability complements traditional monitoring by adding shared context and connected system knowledge. While AI agents can use this graph for dynamic incident investigation, they must still validate their hypotheses against actual telemetry. Establishing reliable telemetry and system relationships is the first step, followed by introducing agentic analysis where it provides measurable value.