> ## 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 base > Give agents your runbooks, postmortems, and service docs as a searchable source they retrieve from and cite during a run. The knowledge base is your organization's written knowledge, indexed so agents can search it while they work and cite what they used. Where skills tell an agent *how* to do a job, the knowledge base tells it *what your organization knows* — how this service behaves, what happened last time, who owns what. This page covers what you can put in it, how a document gets indexed, and how an agent retrieves from it at run time. A knowledge base holds what **you** put in it. Nothing lands here on its own — a resolved incident does not become a knowledge-base document, and neither does a run's output. What an agent learns for itself lives in [Memory](/manage-your-agents/build/memory) instead. ## What it is The Komodor Agentic Operation Platform (KAOP) hosts the knowledge base as a wiki: you add pages, KAOP indexes them, and agents search them during a run. The pages are grouped by what they are — Runbooks, Postmortems, Guides, Service docs, Concepts, and Incidents — so the library stays legible as it grows. Find it under **Knowledge**. The knowledge base depends on an embedding model being configured, so it is enabled per workspace. If yours is not set up yet, the page offers **Set up knowledge base** and creates it for you. ## Add a document Press **Add page**, or drag files onto the page. Markdown, plain text, and PDF are supported. Up to 20 files per upload, each up to 10 MB. The metadata you set applies to the whole batch and is what makes retrieval precise later. A document is **Indexing** while it is being processed and **Indexed** once it is searchable. A document that could not be processed shows **Error**. ### The metadata, and why it matters | Field | What it is for | | --------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **Title** | How the page is listed and cited. Set it for a single upload; a batch takes each file's own title or filename | | **Owner** | Who maintains this page | | **Service** | Which service it is about — the most useful filter an agent has | | **Environment** | Which environment it describes | | **Doc type** | What kind of page it is: `runbook`, `postmortem`, `guide`, `service-doc`, `concept`, `incident`. This is what groups the sidebar | | **Sensitivity** | How restricted the content is | | **Tags** | Free-form, comma-separated | Setting **Service** and **Doc type** is the highest-value thing you can do at upload time. An agent investigating `payment-api` can narrow retrieval to that service's runbooks instead of searching everything, which is the difference between a precise citation and a plausible-sounding one. A Markdown file with a YAML frontmatter block has its metadata read from it — owner, environment, sensitivity, type, tags, and the first listed component as the service. Anything you type in the upload form wins over the file's own frontmatter, and the frontmatter block is stripped before indexing so it does not pollute retrieval. ## How a document becomes searchable Worth knowing, because it explains how to write documents that retrieve well. Markdown and plain text are read directly; PDF and Word documents have their text pulled out, with Word headings preserved as Markdown headings. A Markdown document is split on its headings, so each section becomes a separately retrievable chunk that remembers which heading it came from. A long section is split further, with a small overlap so a sentence is never cut in half between chunks. Once as a vector for meaning-based search, and once for keyword search. Retrieval combines both rankings, which is what lets it find the right page whether you remember the exact phrase or only the idea. Use headings generously. Because sections are the unit of retrieval, a document 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. If you change a document outside KAOP and re-upload it, or a document failed to process, you can reindex it from its detail view. ## How an agent retrieves from it Retrieval is a tool the agent calls, not something injected into every prompt. An agent that opts into KAOP's own tool surface gets `search_knowledge`, and calls it when it decides it needs background. A search takes a query, optionally narrowed by service, environment, doc type, or sensitivity, and returns up to ten hits. Each hit carries: | Field | What it is | | --------------------- | ------------------------------------------------- | | Document title | The page the passage came from | | Section | The heading it sits under | | Body | The passage itself | | Score | How well it matched | | Document and chunk id | Exactly which passage, so a citation is checkable | That is the citation payload: when an agent tells you "per the payment-api runbook", the run's evidence shows which page and which section it actually read. See [Runs & evidence](/manage-your-agents/run/runs-evidence). Every Komodor-built catalog agent has knowledge search enabled, and so does the runtime behind agents you create in the console. If you author your own worker, opting in is one SDK call — see [Build from scratch](/manage-your-agents/build/build-from-scratch). An agent with knowledge search enabled can search the knowledge bases in its own workspace. The workspace is the boundary — a document is never reachable from another workspace — but the knowledge base is not the place for a secret only one agent should see. Secrets belong in [credentials](/manage-your-agents/build/credentials-secrets). ## Searching it yourself The **Knowledge** page has its own search across page titles, services, and labels, plus an **Attention** filter for documents that need a look. This is a librarian's view for finding and maintaining pages — the semantic retrieval described above is what agents use during a run. ## Past incidents Incidents your agents have worked are retained by the module that produced them, with their full evidence, and are read there rather than through the knowledge base. See [Incident management & troubleshooting](/modules-and-workflows/sre/incidents). What the knowledge base adds is the *written* record: a postmortem you upload as a page becomes retrievable and citable alongside your runbooks, so the next investigation can find what you concluded last time. Uploading postmortems with the `postmortem` doc type and the affected **Service** set is the single highest-leverage thing you can put in the knowledge base. ## Writing documents 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. * **Keep it current.** A stale runbook is worse than a missing one, because it retrieves. ## Next steps The other half — procedures an agent follows, rather than facts it looks up. Where an agent's citations show up. How KAOP relates what it knows about your systems. Enable knowledge search in an agent you author. ## Related topics - [Concepts & glossary](/get-started/concepts.md) - [Limits & quotas](/reference/limits-quotas.md) - [Knowledge graph](/manage-your-agents/optimize/knowledge-graph.md) - [Skills](/manage-your-agents/build/skills.md) - [Troubleshooting](/reference/troubleshooting.md)