> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Knowledge graph

> Explore the resources your agents have discovered while operating the fleet, and how they connect to incidents and cost findings.

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:

| Group                   | Node kinds                                                    |
| ----------------------- | ------------------------------------------------------------- |
| **Infrastructure**      | Cloud account · Region · Cluster · Node pool                  |
| **Workloads**           | Service · Workload                                            |
| **Data & storage**      | Database · Cache · Queue · S3 bucket · Volume · Load balancer |
| **Operations & agents** | Monitor · Incident · Cost finding · Agent                     |

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.

<Tip>
  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.
</Tip>

## Reading a node

Selecting a node replaces the legend with its detail:

| Section             | What it holds                                                                                            |
| ------------------- | -------------------------------------------------------------------------------------------------------- |
| **Identity**        | The node's name and kind, with badges for its state, environment, region, and cluster where those apply. |
| **Provenance**      | One sentence saying how this node came to be known.                                                      |
| **Discovered via**  | Which surface surfaced it — **Incidents**, **Cost optimization**, or **Service catalog**.                |
| **Details**         | The node's own attributes, as labelled values.                                                           |
| **Tags**            | Its tags.                                                                                                |
| **Connections (N)** | Every relationship it has, each clickable.                                                               |

<Info>
  **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.
</Info>

## 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.

<Note>
  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.
</Note>

## 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.

| Surface             | What it holds                                                                                                                    | Where                        |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- |
| **Knowledge graph** | Resources discovered by operating your estate, and how they relate to incidents, cost findings, and agents.                      | **Agents → Knowledge graph** |
| **Memory**          | What agents learned from their own runs — techniques, constraints, pointers, and facts, reviewed before they become retrievable. | **Memory**                   |
| **Knowledge base**  | Documents you gave the platform, indexed so agents can search and cite them.                                                     | **Knowledge**                |

<Warning>
  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](#memory); if you are looking for "what did we tell it", that is the
  [knowledge base](/manage-your-agents/build/knowledge-base).
</Warning>

### 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:

| State               | Meaning                                                          |
| ------------------- | ---------------------------------------------------------------- |
| **Awaiting review** | An agent wrote it. It is a draft, and no agent retrieves it yet. |
| **Active**          | The space's memory worker published it. It is retrievable.       |
| **Archived**        | Taken out of what any agent can retrieve, without being deleted. |
| **Superseded**      | Folded into another memory that replaced it.                     |

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.

<Info>
  **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.
</Info>

## Next steps

<CardGroup cols={2}>
  <Card title="Knowledge base" href="/manage-your-agents/build/knowledge-base">
    The documents you give agents, and how they are indexed and cited.
  </Card>

  <Card title="Skills" href="/manage-your-agents/build/skills">
    Turning a durable learning into a runbook an agent follows.
  </Card>

  <Card title="Incident management & troubleshooting" href="/modules-and-workflows/sre/incidents">
    The module that produces most of what the graph discovers.
  </Card>
</CardGroup>


## Related topics

- [Knowledge base](/manage-your-agents/build/knowledge-base.md)
- [Memory](/manage-your-agents/build/memory.md)
- [Optimize — how it works](/manage-your-agents/optimize/how-it-works.md)
- [Orchestration](/manage-your-agents/run/orchestration.md)
- [Azure Investigator](/manage-your-agents/build/catalog/azure-investigator.md)
