Make your knowledge base agent-readable
Here is the shape of the problem, in the order teams usually meet it. The knowledge base lives in a database behind a web UI. Someone wants an assistant to answer questions from it. There is no way to read the content directly, so one of three things gets built.
A connector: the vendor’s integration, or an API client you write against their REST endpoints. It paginates, it rate-limits, it returns content in the vendor’s block format that you convert to text yourself. It breaks when the schema changes, and you find out from a bad answer, not an alert.
An export pipeline: a nightly job that dumps the wiki to Markdown, converts it, and pushes it into a vector store. Now you have two copies of the truth and a window — up to 24 hours wide — where the assistant confidently cites a page that was corrected this morning. Deleted pages are worse: they linger in the index until someone rebuilds it from scratch.
A scraper: fetch the rendered HTML, strip the nav and the sidebar and the comment widget, hope the heading levels survived. This works until a UI release changes a class name.
Each of these is a moving part whose only job is to undo a decision made earlier — putting the content somewhere a program could not read. If the content is files, none of them needs to exist.
What agents actually consume
Strip the vocabulary away and a retrieval pipeline or a coding agent needs five mechanical things from a knowledge source:
- Plain text it can read — bytes that are already the content, not a rendering of it or a JSON envelope around it.
- Stable addresses it can cite — an identifier for a passage that still resolves next month and that a human can open.
- Metadata it can filter on — enough structured fields to answer “only the security docs” before spending tokens.
- A change signal it can reindex from — a way to learn what moved since the last run, so indexing is incremental instead of full-corpus.
- Structure it can chunk on — real section boundaries, so a chunk is a coherent unit of meaning instead of 800 characters ending mid-sentence.
Markdown files in a Git repository map onto that list one to one:
| What the agent needs | What the repository provides |
|---|---|
| Plain text | The .md file — the same bytes the writer edited |
| Stable address | The file path, and the URL derived from it |
| Metadata | YAML frontmatter: title, slug, tags, uuid |
| Change signal | The commit log — every published change is a commit |
| Chunk boundaries | The heading tree inside each file |
None of those are features anyone shipped for AI. They are what the storage
format already is. Wiki links add one more: because [[display text|target]]
resolves by uuid, slug, or title, the cross-references between documents form an
explicit citation graph you can walk, rather than a pile of hrefs you have to
guess at.
Three ways an agent gets to the text
1. Clone and read
The blunt one, and usually the right one. git clone hands an agent the entire
corpus with its directory structure and full history in a single operation. A
coding agent works on the checkout directly — one line in AGENTS.md is often
the whole integration:
Product documentation lives in `docs/`, one Markdown file per page.
Read it before changing behaviour it describes.
A retrieval loader is barely longer. Glob the files, split the frontmatter from the body, keep the path as the citation:
for path in Path("docs").rglob("*.md"):
post = frontmatter.load(path)
index.add(
text=post.content,
metadata={"path": str(path), **post.metadata},
)
There is no client library in that snippet because none is needed. The interface is the filesystem.
2. HTTP, for agents that cannot clone
Some consumers do not have a working copy — a hosted assistant, a lightweight tool call, a script in someone’s notebook. The DocuCommit server answers with raw Markdown over a plain GET. One document:
curl "https://docs.example.com/projects/handbook/export/security/auth?format=md"
Or a whole project in one response:
curl "https://docs.example.com/projects/handbook/export?format=md"
Same content, text/markdown, no HTML to strip. The endpoint is the ordinary
export path — the one a human clicks — which is the point: there is no separate
machine API to keep in sync with the human one.
3. Reindex only what changed
This is where the commit log earns its place. Store the SHA you last indexed. Next run, ask Git what moved:
git fetch origin
git diff --name-only --diff-filter=ACMRD "$LAST_SHA" origin/main -- '*.md'
That list is your reindex queue. Deletions and renames come through the same command, so removed pages actually leave the index instead of haunting it. Then record the new SHA. A corpus of ten thousand documents where four changed costs you four embeddings, and there is no drift window, because the diff is computed against the same object your team published.
To be exact about what is DocuCommit’s and what is Git’s: the endpoints above are product features. The diff is plain Git, and it works the same way on any repository of Markdown files.
llms.txt and Markdown twins
Two conventions help agents that arrive at retrieval time — not with a clone, but
with a URL — and both are cheap to adopt. llms.txt is a single Markdown file at
the site root that states what the site is and links its important pages, so a
model does not have to infer the map from a navigation menu. A Markdown twin
is the raw source of a page served at a predictable URL beside the rendered HTML,
so a fetch returns prose instead of a document object model.
This site ships both. There is /llms.txt and a longer
/llms-full.txt, and every documentation page has a twin: take
the page URL, replace the trailing slash with .md. So
/docs/getting-started/repository-layout/ also answers at
/docs/getting-started/repository-layout.md.
Neither is a standard with a specification behind it, and neither will fix a
badly written page. They remove one specific failure — an agent parsing your
chrome instead of your content — and nothing more.
The catch
Access is necessary. It is not sufficient, and three honest limits follow from that.
Stale is stale faster. Removing the export lag means the assistant reads exactly what is in the repository, including the page nobody has updated since the API changed. Direct access makes wrong documentation wrong at machine speed and at scale. The content problem does not go away; it becomes the only problem left.
Retrieval quality is still your problem. Heading structure gives you sensible chunk boundaries, but a 6,000-word page with two headings chunks badly no matter where it is stored. Short documents, real section headings, and accurate frontmatter tags do more for answer quality than any embedding model choice.
None of this is access control. A clone is all or nothing: whoever can clone the repository has every document and every past revision, including the paragraph someone deleted last spring. And server sign-in does not gate reading — anyone who can reach the server reads every page, so the network perimeter around the repo and the server is the real boundary. The same properties that make a reachable repo readable by every helpful agent make it readable by every other one. Decide what belongs in that repository accordingly.
And one thing to be clear about, because it is the actual claim: DocuCommit has no built-in embeddings, no bundled RAG pipeline, no MCP server. It does not index your docs for a model. What it does is keep the canonical copy as plain Markdown in a Git repository you own, which is the part that is hard to retrofit. Everything above is something you can build in an afternoon with tools you already have, precisely because there is nothing to integrate with. Nothing to build is the feature.
Where to go next
For the storage argument on its own terms — what “the repository is the store” means, what it costs, and when it is the wrong answer — read Git-backed documentation, explained. For the practical setup, including how the repository is laid out, see the documentation.
Or look at a real repository through both lenses. There is a live demo, no signup:
Or start the 14-day trial and point your own agents at your own repo from the first commit.