Give an AI agent your company knowledge base, and keep every change it makes
Connect AI agents to a knowledge base stored in Git, so every agent edit is a commit you can review, compare and revert.
An AI agent tidies the onboarding guide overnight. The next morning a new hire follows it and cannot reach the VPN: one step points to a server retired last year. Two questions follow. What exactly did the agent change? Can we undo that one change and keep the rest of its work?
If the knowledge base cannot answer both, giving agents write access is a gamble.
What an agent needs, and what the company needs
The agent needs access: to find, read and sometimes edit the right documents. The company needs accountability: a record of every change, in a form people can review and reverse.
Most setups solve the first and skip the second. A search index lets an agent read and a wiki API lets it write, but wiki history is ungrouped, and undoing one edit means editing again by hand.
Why Git fits
Git was built for many authors changing the same files, and it records exactly what a company wants to know:
- each change is a commit, with an author, a time and a message;
- one commit can span several files, so one task is one change;
- a diff shows which lines changed;
- revert undoes one commit and leaves the rest alone;
- branches and pull requests let people review before a change counts.
Agents are good at files, and a folder of Markdown is something they already read and edit.
MCP: how the agent reaches the repository
MCP, the Model Context Protocol, is an open standard for connecting AI applications to tools and data. An MCP server offers tools that any MCP client can call, from a chat assistant to a coding agent.
A knowledge base exposed over MCP gives the agent tools to:
- list notebooks and notes;
- search by topic, and read a note or only its frontmatter;
- create, edit, move or delete notes, each change committed.
The agent never needs a Git command; the server turns its edits into commits.
Setting it up with MyGitNotes
1. Put the knowledge in a repository. Markdown notes, grouped into notebooks, in a repository the company owns. Existing Markdown can be committed as it is.
2. Choose where the server runs. app.mygitnotes.com gives the repository an MCP endpoint over Streamable HTTP, for remote clients such as ChatGPT connectors. The open-source edition runs the same server on your machine over stdio, next to a local checkout, for Claude Desktop or Codex. Or self-host it and keep the endpoint inside your network.
3. Give each agent its own access. Read-only for agents that only answer questions, write for the few that maintain documents. Each grant can be revoked on its own.
4. Keep the agent’s instructions in the repository. Which notebooks it may change, how to word commit messages: write it as a file in the same repository, versioned and readable by the agent.
5. Review the history. Every agent change is its own commit. Read the diff, and revert if it is wrong.
Guardrails worth having
People and agents write at the same time, so writes need care. In MyGitNotes, a write carries the version the agent last read and is refused if the note changed since, so an agent cannot silently overwrite a newer edit. Paths outside the notebooks are refused, and the branch is never force-pushed.
What this does not solve
A commit records what changed, not whether it is right. Someone still has to read the history, at least for documents that matter. And what the agent sends to its model provider leaves your hands under that provider’s terms; self-hosting keeps the knowledge base in your network, not the model’s input.
The VPN step from the opening becomes a five-minute fix: find the agent’s commit, read its diff, and revert it or correct the one line.
The AI agents page covers how companies roll this out.