Skip to main content
The Knowledge graph is a map of what the Komodor Agentic Operation Platform (KAOP) has learned about your estate by operating it — the services, clusters, nodes, data stores, buckets, and volumes its agents have encountered, linked to the incidents, cost findings, and agents that surfaced them. This page explains what the graph contains, how to read a node, and how it differs from the two other places agent knowledge lives. Find it under Agents → Knowledge graph. It is enabled per workspace.

​
What the graph is for

Agents accumulate context that no single run shows. One agent investigated a checkout incident and touched a database; another priced an S3 bucket and found waste on the same cluster; a third watches a monitor pointing at the service in between. Individually those are three runs. Together they are a picture of your estate, and the graph is where that picture is legible. It answers the questions that span runs:
  • What do we actually know about this service, and how did we learn it?
  • What sits underneath it — which cluster, which nodes, which data stores?
  • Which incidents have touched it, and which agent found them?
  • Where did a cost finding land relative to the things that were failing?

​
Reading the graph

The canvas is a force-directed map: nodes are resources and the things that reference them, edges are their relationships. Clicking a node selects it and dims everything that is not adjacent, so a neighbourhood is one click rather than a visual hunt. Nodes are draggable, and the usual zoom, pan, and fit-view controls plus a minimap are on the canvas. By default the right panel is the legend: how many resources have been discovered in total, how many came From incidents, how many From cost opt, and what every colour means.

​
What is on the map

Sixteen kinds of node, in four groups: Nodes carry a state, shown as a badge and a coloured dot: Healthy, Degraded, At risk, Idle, Resolved, or Active.

​
How things connect

Fourteen relationship types appear in the graph: contains · runs on · depends on · reads / writes · uses · routes to · stores in · produces to · attached to · watches · affects · targets · investigated · found Edges are drawn as directional curves on the canvas and are not labelled there — the relationship names appear in a node’s Connections list, where each entry reads as an outgoing or incoming relationship and clicks through to the other end.
The last four relationships are the ones that make this more than an inventory. watches, affects, targets, investigated, and found are how a monitor, an incident, a cost finding, and an agent attach to the infrastructure they concern — which is what lets you walk from a service to the agent that learned something about it.

​
Reading a node

Selecting a node replaces the legend with its detail:
Provenance is the field to read first. A node that entered the graph from a cost run and a node that entered from an incident investigation are known to different depths. Knowing which you are looking at stops you treating a passing mention as a verified fact.

​
Finding something

  • Search — matches a node’s name, id, kind, tags, and every one of its detail labels and values. Type a service name, a tag, or a region.
  • Discovered via — narrow to nodes surfaced by Incidents, Cost optimization, or the Service catalog. Multi-select.
  • Type — narrow to any combination of the sixteen node kinds.
  • While a filter is active, a counter reads Highlighting N of the total, so you always know how much of the estate you are looking at.
  • Reset view clears every filter and any selection.
Filtering highlights rather than hides. The graph keeps its shape while you narrow, so a filtered node stays where it was relative to its neighbours — which is what lets you see that the three degraded services are all on one cluster.

​
Three different kinds of agent knowledge

The graph is one of three places knowledge lives, and they are genuinely different things. Confusing them is the most common mistake here.
The knowledge graph is not fed by your knowledge base documents, and it is not a view of agent memory. It is a topology of discovered resources. If you are looking for “what has this agent learned”, that is Memory; if you are looking for “what did we tell it”, that is the knowledge base.

​
Memory

Memory is what agents learned from their own runs. An agent reads and writes one space, so putting two agents in the same space is how learnings get shared between them. A memory has a kind — technique, pointer, constraint, fact, feedback, or preference — and a lifecycle that keeps the space honest: The Activity view shows what changed and why — published by the memory worker, folded into another memory, or dropped. Manage memories and Manage spaces are where you curate what agents can retrieve and which agents share a space.
A memory an agent writes is a draft until it is reviewed. That review step is the whole reason memory can be trusted: an agent that mis-concluded once would otherwise teach that conclusion to every agent in the space, permanently. Archiving is how you take a learning back out of circulation without destroying the record that it was ever believed.

​
Next steps

Knowledge base

The documents you give agents, and how they are indexed and cited.

Skills

Turning a durable learning into a runbook an agent follows.

Incident management & troubleshooting

The module that produces most of what the graph discovers.