Skip to main content
The knowledge base is your organization’s written knowledge, indexed so agents in the Komodor Agentic Operation Platform (KAOP) can search it while they work and cite what they used. Where skills tell an agent how a job is done, knowledge tells it what your organization knows — how this service behaves, what happened last time, who owns what.
The knowledge base holds what you put in it. Nothing lands here on its own: a resolved incident does not become a knowledge page, and neither does a run’s output. What an agent learns for itself lives in Memory instead.

What the library shows for each page

KAOP hosts knowledge as a wiki, and the unit you manage is a page with a path. A page is organized into the wiki’s structure, revised in place, and cited by a path that stays stable.

What each status tells you

A page’s status answers whether an agent can rely on it, which is a different question from whether the platform managed to read it. The library’s own attention filter collects every page that is stale, errored, or has no type, which turns it into a maintenance queue. Only Indexed pages are retrieved, so everything in that queue is invisible to agents until it is dealt with. It is a filter on this list, unrelated to the account-wide Attention inbox.

How a page becomes searchable

A page is split on its top three heading levels, so each section becomes a separately retrievable chunk that remembers which heading it came from. A long section is split further at paragraph boundaries, with a small overlap carried into the next chunk so context spanning a boundary is not lost. Keep paragraphs under roughly 1,500 characters: a single paragraph longer than that is truncated rather than split. Each chunk is indexed by meaning: the query and the chunk are embedded and compared by vector similarity, so an agent finds the right section from a description of the problem rather than from the exact words in it. Write headings and bodies that describe the situation, not keywords to match.
Use headings generously, down to the third level. Because sections are the unit of retrieval, a page with clear headings surfaces the relevant part of a long runbook rather than the whole thing, and the heading is what appears in the citation.

How an agent retrieves from it

Retrieval is a tool the agent calls, not something injected into every prompt. A search takes a query, optionally narrowed by service, environment, type or sensitivity, and returns a handful of passages. Each hit carries the page, the section, the passage, a score, and ids precise enough that the citation is checkable — so when an agent says “per the payments runbook”, the run’s evidence shows which page and which section it actually read. See Runs & evidence.
The account is the boundary: a page is never reachable from another account. But the knowledge base is not the place for a secret only one agent should see — secrets belong in credentials. Retrieval can be narrowed by sensitivity, which groups pages by intended audience — a filter, not a permission boundary. An agent can also be scoped to the tags it may retrieve, and a page with no tags is readable by every agent, so tag a page you mean to narrow.

Writing pages agents can use

  • One subject per page. A page about one service retrieves better than a page about six.
  • Headings that name the situation — “Elevated 5xx after deploy” beats “Troubleshooting”.
  • Concrete thresholds and commands. An agent can act on “scale to 6 replicas if queue depth exceeds 500”; it cannot act on “scale up as needed”.
  • Say when a page does not apply. Explicit non-applicability stops an agent citing the wrong runbook confidently.
  • Write postmortems as pages. Typed as a postmortem and attributed to its service, it is retrievable by the next investigation into the same thing.

Next steps

Skills

Procedure an agent follows, rather than facts it looks up.

Runs & evidence

Where an agent’s citations show up.