---
title: "Let AI Agents Write to Your Knowledge Base, Not Just Read It"
description: "Most AI setups let an agent read your notes but never update them. Here's why write-back matters and how to let Claude, ChatGPT, and Cursor safely write to your knowledge base."
author: "MDflow"
date: 2026-07-08
reading_time: "13 min"
canonical_url: https://mdflow.cz/blog/ai-agents-write-to-knowledge-base
md_url: https://mdflow.cz/blog/ai-agents-write-to-knowledge-base.md
---

# Let AI Agents Write to Your Knowledge Base, Not Just Read It

*Published July 8, 2026 · 13 min read*


Almost every "connect your AI to your notes" tutorial stops at half the job. You wire up an agent, it can search your documents, quote them back, and ground its answers in your own writing — and then it hits a wall. The moment it learns something worth keeping, decides a status should change, or notices a stale cross-reference, it can do nothing about it. It can read your knowledge base. It cannot touch it.

That read-only ceiling is the single biggest gap in most agent-memory setups today. And it is a strange one, because the thing large language models are genuinely, tirelessly good at is exactly the thing read-only setups forbid: the bookkeeping. Updating the status line. Filing the note. Keeping the index honest.

> **TL;DR** — To **let AI agents write to your knowledge base** you need a connection with write access — an HTTP API or an MCP server that exposes create, update, move, and delete, authenticated by a token you control. Read-only setups keep your knowledge stale; read+write setups let the agent do the bookkeeping and keep it current. [MDflow](/) exposes full read/write over both an [HTTP API](/docs/api) and an [MCP server](/docs/mcp), with automatic version history on every agent edit, so write-back is safe and reversible.

## What "write-back" actually means

Write-back means an AI agent can **change** your knowledge base, not just query it. Concretely, the connection exposes operations like *create a document*, *replace a document's body*, *rename it*, *move it to another folder*, and *update a folder's description* — and the agent is allowed to call them.

The distinction matters because "give your AI access to your notes" quietly splits into two very different postures:

| | Read-only agent | Read + write agent |
|---|---|---|
| Search & retrieve context | ✅ | ✅ |
| Answer grounded in your docs | ✅ | ✅ |
| Record a new decision or note | ❌ | ✅ |
| Update a status or living document | ❌ | ✅ |
| Fix a broken cross-reference | ❌ | ✅ |
| Keep the knowledge base current | You, by hand | The agent, as it works |

Read-only is the safe-looking default, and plenty of integrations ship only that. But it hands the agent a library card and takes away the pen. The knowledge base still only improves when a *human* remembers to update it — which is precisely the chore humans abandon, which is why wikis rot.

Write-back flips the economics. As Andrej Karpathy put it about agent-maintained knowledge, *"LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass."* The maintenance that causes people to give up on their notes is the maintenance an agent is happy to do forever — but only if you let it hold the pen.

## Why letting agents write is useful

**For developers, write-back turns a knowledge base into shared state.**

- **The knowledge base maintains itself.** When the agent that *uses* your docs is the same agent that *updates* them, currency becomes a by-product of the work instead of a separate task. Decisions get recorded because recording them is one tool call away.
- **Agents get durable memory between sessions.** A read-only agent forgets everything the moment the context window closes. An agent that can write persists its findings to markdown you own — so the next session, or a different agent entirely, picks up where the last one left off.
- **Multiple agents coordinate through one source of truth.** A planning agent writes a spec; a coding agent reads it and writes back progress; a review agent appends notes. They never talk to each other directly — they read and write the same documents, the way a team coordinates through a shared doc rather than a meeting.
- **It stays portable.** When the substrate is plain markdown over an open API, you are not betting your memory layer on one vendor's proprietary store. Any agent that can make an HTTP request can participate.

**For AI agents, write-back closes the loop.**

- **From guessing to recording.** An agent that can only read has to re-derive what it already figured out last time. An agent that can write leaves itself a note — provenance, not repetition.
- **Structured bookkeeping at scale.** Touching fifteen files to keep a cross-reference consistent is tedious for a person and trivial for an agent. Write-back is where that strength finally has somewhere to land.
- **Tasks and status become live.** If a task is just a markdown checkbox in a document, an agent with write access can check it off, add a due date, or file a new one — and it shows up everywhere that document is read.

## Which workflows benefit most

Write-back is general, but a handful of workflows go from awkward to natural the moment the agent can hold the pen.

1. **Agentic coding.** The innermost coding loop — write, test, fix — runs against a spec and a plan. When the agent can update the plan, mark steps done, and record decisions in markdown, the spec stops drifting from reality. See [the agentic coding loop](/blog/agentic-coding-loop) for the full picture.
2. **A self-maintaining wiki or "second brain."** The [Karpathy-style wiki](/blog/karpathy-style-wiki) pattern is entirely built on write-back: the LLM curates and updates a plain-markdown knowledge base so it compounds instead of rotting.
3. **Meeting notes, research logs, and daily journals.** Point an agent at a conversation or a set of sources and have it *write the summary into your workspace* — filed in the right folder, cross-linked, ready to retrieve later.
4. **Living project documentation.** Runbooks, architecture decision records, and status docs that an on-call or project agent keeps current as things change, instead of a doc that was accurate the day it was written.
5. **Task and pipeline automation.** Because a task in MDflow is just a checkbox line in a document, any agent that can write a document body can create, complete, or reschedule tasks — turning your [markdown tasks](/markdown-tasks) into an automation surface.

The common thread: anywhere the knowledge base should reflect *what just happened*, write-back removes the human transcription step that otherwise never gets done.

## How to let an agent write to MDflow

Here is the concrete part — the implementation guidance. MDflow exposes the same read/write operations two ways: a [Model Context Protocol server](/docs/mcp) for agentic clients, and a plain [HTTP API](/docs/api) for scripts. Both are authenticated by a **Personal Access Token** you create and can revoke. (Agent control is a Pro feature.)

### 1. Create a token

In MDflow **settings**, create a Personal Access Token (it looks like `mdf_…`). Copy it once — it grants read and write access to your workspace and nothing outside it, and you can revoke it instantly at any time.

### 2. Connect over MCP (Claude, Cursor, Codex)

For clients that send their own auth header — Claude Code, Cursor, the OpenAI Responses API — point them at the hosted remote server with your token:

```bash
claude mcp add --transport http mdflow https://mdflow.cz/api/mcp \
  --header "Authorization: Bearer mdf_your_token_here"
```

Claude.ai and the ChatGPT app connect to the same endpoint with a browser OAuth sign-in instead of a pasted token — add `https://mdflow.cz/api/mcp` as a custom connector and authorize. Once connected, the agent has **write tools**, not just read tools:

```text
mdflow_create_document       # file a new markdown note in a folder
mdflow_update_document_body  # replace a document's body
mdflow_rename_document       # rename it
mdflow_move_document         # move it to another folder
mdflow_create_folder         # organize as it goes
mdflow_update_folder_description  # keep the context signal current
mdflow_update_document_sharing    # publish or share the result
```

So a prompt like *"summarize this thread and save it to my Research folder, cross-linked to the related notes"* becomes a real action: the agent calls `mdflow_get_context` to find the neighbours, then `mdflow_create_document` to write the summary — and it is in your workspace, in markdown, when the conversation ends.

### 3. Or write over the HTTP API (scripts, pipelines)

For a server-side script or a non-MCP tool, the same operations are REST calls with a bearer token. Create a document:

```bash
curl -X POST https://mdflow.cz/api/v1/documents \
  -H "Authorization: Bearer mdf_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{"folder_id":"<folder-uuid>","title":"Standup 2026-07-08","body":"# Notes\n\n- [ ] Ship write-back post"}'
```

Replace its body later:

```bash
curl -X PUT https://mdflow.cz/api/v1/documents/<id>/body \
  -H "Authorization: Bearer mdf_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{"body":"# Notes\n\n- [x] Ship write-back post"}'
```

That is the whole model: a token you control, and a small set of write operations any agent or script can call.

## How MDflow fits

MDflow was built on the producer-and-consumer idea from the start — the point was never a read-only reference, it was a workspace people **and** agents can both write. Here is what already lines up, and where we are headed.

### What already lines up today

**Full read/write over API and MCP.** Every operation an agent needs to maintain a knowledge base — create, update, rename, move, delete documents and folders, edit folder descriptions, manage sharing — is available over both the [HTTP API](/docs/api) and the [MCP server](/docs/mcp). This is the differentiator against read-only setups: the pen is included.

**Automatic version history on every write path.** This is what makes write-back *safe*. Every saved change — from the editor, the API, **or** an agent — captures the previous version automatically. An agent edit is never destructive: you can view a line-by-line diff and restore any prior version with one click. Give an agent the pen and you still keep the undo button. (Version history is a Pro feature.)

**Scoped, revocable access.** A [Personal Access Token](/docs/api) grants read and write to exactly one account's workspace and can be revoked immediately from settings. You decide when an agent can write, and you can end it in a click.

**Folder descriptions the agent keeps current.** In MDflow every folder carries a description that is the *primary ranking signal* for [`mdflow_get_context`](/docs/mcp) retrieval. Because agents can write those descriptions too, the retrieval quality improves as the agent works — the thing it reads to find context is the thing it can also keep accurate. (More on that in [folder descriptions as agent context](/blog/folder-descriptions-agent-context).)

**Tasks as a write target.** A task in MDflow is a markdown checkbox inside a document, not a row in a separate database. So an agent writing a document body can create, complete, or schedule [tasks](/markdown-tasks) that appear in the aggregated Tasks view — write-back reaches your to-dos, not just your prose.

**Everything stays portable markdown.** What the agent writes is plain markdown you own, readable in the [editor](/), fetchable as a raw `.md` twin, and exportable as a `.zip` of your whole workspace. Write-back does not lock your memory into a proprietary shape.

### Where we are headed

This is **direction, not a dated commitment**, but it is the shape of our thinking:

- **Append and patch semantics.** Today an agent replaces a document body; a natural next step is finer-grained *append a section* or *edit this block* operations, so a long living document can be updated without rewriting the whole thing.
- **Richer write-side context.** Surfacing the compounded folder cascade to the agent *before* it writes, so new documents land in the right place with the right cross-links by default.
- **Agent-assisted enrichment.** Letting an agent propose folder descriptions, cross-links, and structure for knowledge you already have — the bookkeeping, offered proactively.
- **Finer-grained tokens.** Scopes and per-folder permissions, so you can hand an agent write access to one corner of a workspace rather than all of it.

## The bottom line

Reading is table stakes. Any decent integration can let an agent search your notes and quote them back. The gap — and the differentiator worth caring about — is whether the agent can **write**: record what it learned, keep the status honest, fix the cross-reference, file the note. That is the maintenance humans abandon and agents never tire of, and it is exactly what read-only setups forbid.

MDflow gives an agent the pen and keeps you the undo button: full read/write over an [API](/docs/api) and an [MCP server](/docs/mcp), scoped to a token you can revoke, with automatic version history behind every edit so nothing an agent writes is ever lost. Let the agent do the bookkeeping — and let your knowledge base finally keep up with your work.

[Start free](/login) · [Connect an AI agent](/docs/mcp) · [Read the API docs](/docs/api)

## Frequently asked questions

### Can an AI agent write to my notes, or only read them?

It depends entirely on the tool. Many AI knowledge-base integrations are read-only: the agent can search and retrieve your documents but cannot change them. To let an agent write back, you need a connection that exposes create, update, move, and delete operations — a read+write HTTP API or an MCP server with write tools, authenticated by a token you control. MDflow's API and MCP server support all of these today.

### How do I let Claude update my documents?

Connect Claude to a knowledge base that offers write tools over the Model Context Protocol (MCP). In MDflow you create a Personal Access Token, add the remote MCP server (`https://mdflow.cz/api/mcp`) to Claude, and Claude can then call tools like `mdflow_create_document` and `mdflow_update_document_body` to write markdown back into your workspace — while automatic version history keeps every prior version.

### Is it safe to give an AI agent write access to my knowledge base?

It is safe when three things are true: access is scoped to a token you can revoke, every write is versioned so nothing is destroyed, and you can review changes. MDflow captures a new version on every write path (editor, API, and agent), so an agent edit is always reversible with one click, and Personal Access Tokens can be revoked instantly from settings.

### What is the difference between read-only and read+write agent memory?

Read-only memory lets an agent consume context you maintain by hand — it can answer questions but the knowledge base goes stale unless a human updates it. Read+write memory lets the agent also do the bookkeeping: record decisions, update a status doc, fix a cross-reference, file a new note. That closes the loop so your knowledge base stays current as a by-product of the work, not as a separate chore.

### Which AI clients can write to MDflow?

Any MCP-capable client with write tools, plus anything that can call an HTTP API. That includes Claude Code, Claude Desktop, Cursor, Codex, the OpenAI Responses API, and Claude.ai and the ChatGPT app via an OAuth connector. All of them can create, update, move, and share markdown documents in your workspace once connected.

## Further reading

- Andrej Karpathy — [the "idea file" gist, `llm-wiki.md`](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) (the primary source for the agent-maintained wiki pattern)
- MDflow — [The Karpathy-Style Wiki: A Knowledge Base Your AI Maintains](/blog/karpathy-style-wiki)
- MDflow — [The Agentic Coding Loop, and the Markdown Memory It Needs](/blog/agentic-coding-loop)
- MDflow — [Folder Descriptions as Agent Context](/blog/folder-descriptions-agent-context) · [MCP documentation](/docs/mcp) · [API documentation](/docs/api) · [Markdown for AI agents](/markdown-ai)