Knolo
Log inStart building — free

Blog

How-to

June 23, 2026 · 14 min

Connect Your Whole Brain to Every AI Tool You Use — The Knolo Connector + Knowledge Wiki

Connect Your Whole Brain to Every AI Tool You Use — The Knolo Connector + Knowledge Wiki

Every AI client you open starts from zero. Cursor doesn't know what you figured out in Claude Desktop. Claude Desktop doesn't know what your custom agent discovered last Tuesday. ChatGPT has never heard of your project. You re-explain yourself, every time, to every tool.

This is the AI amnesia problem — and it's not a model quality issue. The models are fine. The problem is architectural: knowledge is trapped per-tool, per-session, per-conversation. Nothing accumulates.

This post shows you how to fix it. The Knolo Connector turns your Space into a remote MCP server — a single knowledge endpoint that every MCP-enabled client can read simultaneously. Pair it with the knowledge-wiki skill, and that endpoint isn't just a static file dump. It's a self-maintaining, compounding brain that gets smarter every time the Ingestor agent runs.

By the end, you'll have one source of truth that Cursor, Claude Desktop, ChatGPT, and your own agents all read from — and optionally write back to.

All of them

MCP clients

Cursor, Claude Desktop, ChatGPT, custom agents

< 15 min

Setup time

Connector + first MCP client

Zero

Code required

no Docker, no local server, no config files

Compounding

Knowledge model

Karpathy-inspired wiki, not one-shot RAG


The Problem: Your AI Tools Have Amnesia

Here's what the average AI-heavy workflow looks like in 2026:

  • You open Cursor to work on a codebase. You explain the architecture, the conventions, the decisions you made last sprint.
  • You open Claude Desktop to think through a problem. You explain the context again.
  • You spin up a custom agent to do research. It starts from nothing.
  • You open ChatGPT for a quick question. Zero context.

Every tool is an island. The insight you captured in one session doesn't travel. The architectural decision you documented in Cursor doesn't reach Claude. The research your agent compiled doesn't inform your next conversation.

Reddit's developer communities have been naming this frustration precisely:

"Every time you open a new Cursor window, start a new Claude Code session, or spin up a new agent, it starts from zero. It doesn't know the architectural decision you made yesterday. It doesn't know the bug you fixed last week."

"What Claude learns, Hermes knows." — r/AI_Agents, describing exactly the value prop of shared MCP memory

"In the age of model churn, we need to realize that the model is rented, your personal context is owned. Start asking 'where does my context live, and do I actually own it?'"

The model is rented. Your context is owned. The question is whether your context is trapped inside one tool — or portable across all of them.


The Solution: Build Your Brain Once, Attach It Everywhere

The Knolo Connector is a per-Space remote MCP server. Every Space you create in Knolo gets its own Connector endpoint — a URL you paste into any MCP-enabled client once, and that client can read from your Space's knowledge base from that point forward.

The architecture is simple:

Architecture diagram showing three layers: Raw Sources (documents, PDFs, web pages) flowing into Wiki Mind (interconnected wiki pages maintained by Ingestor Agent and verified by Lint Agent), then through the Knolo Connector MCP endpoint to four clients: Cursor, Claude Desktop, ChatGPT, and Custom Agents. Bidirectional arrow labeled Allow Writes between Connector and clients.
The Knolo Connector architecture — one knowledge base, every MCP client, bidirectional with Allow Writes enabled

What this gives you:

  • One source of truth. Your knowledge base lives in one Knolo Space. Every client reads from the same place.
  • Simultaneous access. Cursor, Claude Desktop, ChatGPT, and your custom agents can all be connected at the same time. They all read the same knowledge.
  • Optional write-back. With Allow Writes enabled, any connected client can contribute back to the knowledge base. Your IDE assistant adds notes on what worked in a codebase. Your research agent files its findings. The brain accumulates from every direction.
  • No engineering. The Connector is a URL. You paste it into a JSON config. That's the entire setup.

The Karpathy Angle: Why a Wiki Beats One-Shot RAG

Most knowledge tools do one-shot RAG: you ask a question, the system retrieves relevant chunks, answers, and forgets. Nothing accumulates. The next query starts fresh.

Andrej Karpathy published a different idea — that an LLM should compile a knowledge wiki rather than repeatedly re-read raw sources. His gist (published early 2026, 5,000+ GitHub stars) articulates the pattern: instead of querying raw documents on every request, an LLM agent maintains a cross-referenced wiki. Sources get processed once, compiled into interlinked pages, and the wiki improves over time. Queries get answered from the wiki, not the raw sources.

The knowledge-wiki skill is Knolo's implementation of this pattern. Here's what makes it different from a static knowledge base:

Two-column diagram comparing One-Shot RAG (left) vs Compounding Wiki (right). One-Shot RAG shows a flat line: Query → Retrieve → Answer → Forget, looping back to Query with no accumulation. Compounding Wiki shows an upward curve: Ingest → Compile → Wiki Grows → Query answers from wiki → Lint verifies → Wiki improves, with 'Knowledge compounds over time' label.
One-shot RAG forgets everything. The Karpathy/Knolo pattern compounds — the wiki gets better with every ingest cycle.

By the numbers

Karpathy's LLM Wiki gist has 5,000+ GitHub stars and spawned implementations across Obsidian plugins, Claude Code skills, and Reddit threads. The knowledge-wiki skill is Knolo's no-code implementation of this pattern — install it in minutes, no Python required.

The distinction matters for the Connector use case. When your MCP clients read from a Knolo Space, they're not reading a pile of raw documents. They're reading a compiled, cross-referenced, actively maintained wiki. The context they get is richer, more connected, and more current than anything a simple RAG retrieval would return.


Tutorial 1: Set Up the Knolo Connector — Add It to Cursor, Claude Desktop, and ChatGPT

This tutorial covers the Connector setup alone. If you want the full knowledge-wiki skill setup, skip to Tutorial 2 — it includes the Connector as the final step.

Step 1: Create the Connector in Space Settings

  1. Open your Knolo Space
  2. Go to Settings → Connector
  3. Click Generate Key — this creates a knc_ prefixed API key
  4. Copy the MCP Endpoint URL shown in the panel

The endpoint URL looks like: https://mcp.knolo.io/v1/[your-space-id]

This is the only URL you'll need for every client.

Step 2: Add to Cursor

Cursor supports MCP servers via a JSON config. You can add Knolo at the project level (.cursor/mcp.json) or globally.

Project-level config (.cursor/mcp.json in your project root):

{
  "mcpServers": {
    "knolo": {
      "url": "https://mcp.knolo.io/v1/[your-space-id]",
      "headers": {
        "Authorization": "Bearer knc_[your-key]"
      }
    }
  }
}

Global config (Cursor Settings → MCP Servers): paste the same JSON into the MCP servers configuration panel.

After saving, Cursor will show Knolo as an active MCP server in the status bar.

Step 3: Add to Claude Desktop

Claude Desktop reads MCP config from claude_desktop_config.json. Location:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
  • Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the Knolo server to the mcpServers object:

{
  "mcpServers": {
    "knolo": {
      "url": "https://mcp.knolo.io/v1/[your-space-id]",
      "headers": {
        "Authorization": "Bearer knc_[your-key]"
      }
    }
  }
}

Restart Claude Desktop. Knolo will appear in the MCP tools panel.

Step 4: Add to ChatGPT

ChatGPT's MCP support (added in 2026) works through the Custom Connectors panel in Settings:

  1. Go to Settings → Connectors → Add MCP Server
  2. Paste your Knolo endpoint URL
  3. Add the Authorization: Bearer knc_[your-key] header
  4. Save and enable

ChatGPT will now be able to search and read from your Knolo Space in any conversation.

Step 5: Test — Verify All Clients Are Reading from Your Space

The fastest test: add a distinctive piece of content to your Knolo Space (a specific phrase or fact that couldn't be guessed), then ask each client about it.

In Cursor: "What does our architecture doc say about the database schema?"
In Claude Desktop: "What's in my Knolo knowledge base about [topic]?"
In ChatGPT: "Search my Knolo Space for [distinctive phrase]"

If all three return the same grounded answer, the Connector is working.

Tip

The knc_ key controls what the connected client can do. By default, clients can only read. To allow clients to write back to your Space, toggle Allow Writes in Space Settings → Connector. More on this in Tutorial 2.


Tutorial 2 (Flagship): The Knowledge-Wiki Skill + Connector — Your Self-Maintaining Brain, Everywhere

This is the combination that changes how you work. The knowledge-wiki skill builds a brain that maintains itself. The Connector makes that brain reachable from everywhere. Together: a compounding, portable, shared second brain.

Why This Is the Killer Combination

  • knowledge-wiki: a brain that maintains itself — the Ingestor agent compiles new sources into interlinked wiki pages, the Lint agent verifies coherence and catches contradictions. Knowledge compounds over time.
  • Connector: a brain that's reachable from everywhere — one MCP endpoint, all your clients, simultaneously.
  • Together: you ingest once, and every tool you use gets smarter.

Step 1: Install the knowledge-wiki Skill

  1. Go to knolo.io/skills and find the Knowledge Wiki skill
  2. Click Install — choose your target Space (or create a new one)
  3. Knolo installs the skill and creates:
    • Raw Sources Mind — an immutable archive of everything you feed in. Sources land here first and are never modified.
    • Wiki Mind — the compiled, interlinked wiki. This is what your MCP clients will read.
    • Wiki Librarian assistant — a conversational interface for querying your wiki directly inside Knolo
    • Ingestor agent — runs on a schedule, reads new sources from Raw Sources, and compiles them into wiki pages
    • Lint agent (optional) — runs after each ingest cycle to verify wiki coherence, catch broken links, and flag contradictions

What the pattern actually does: The Ingestor agent doesn't just index your documents — it compiles them. It reads a new source, identifies what's already in the wiki that's related, updates existing pages, creates new pages where needed, and maintains the cross-reference links between them. This is the Karpathy pattern: the LLM is the programmer, the wiki is the codebase, and the Ingestor is the commit.

Step 2: Ingest Your First Sources

Drop content into the Raw Sources Mind:

  • Documents: PDFs, Word docs, Markdown files — drag and drop into the mind
  • Web pages: paste a URL and Knolo fetches the content
  • YouTube transcripts: paste a video URL and Knolo extracts the transcript
  • Notes: paste text directly — meeting notes, research snippets, anything

The Ingestor agent runs on its configured schedule (default: every 6 hours) and processes new sources automatically. You can also trigger it manually from the agent panel.

After the first ingest cycle, open the Wiki Mind. You'll see structured wiki pages with cross-references between them — not a flat list of documents, but a connected knowledge graph.

Step 3: Attach the Connector

Follow Tutorial 1 above. The key difference when using the knowledge-wiki skill: point your MCP clients specifically at the Wiki Mind for the cleanest results. The Connector exposes your entire Space by default, but you can configure it to surface the wiki pages preferentially.

In Space Settings → Connector:

  1. Generate your knc_ key
  2. Copy the endpoint URL
  3. Add to Cursor, Claude Desktop, and ChatGPT (see Tutorial 1 steps 2–4)

Step 4: Ask Questions Across Tools

Now the interesting part. Your wiki is live. Every client is connected. Try this:

In Cursor: Open a codebase and ask a question that requires domain context — something your wiki knows but the model doesn't. "What's our convention for handling async errors in this codebase?" Cursor reads from your wiki and answers from your actual documented conventions, not from generic best practices.

In Claude Desktop: Ask a research question that your wiki has covered. "What are the key arguments in the sources I've ingested about [topic]?" Claude reads the compiled wiki pages and gives you a synthesised answer — not a list of raw document excerpts.

In a custom agent: Your agent can now read from the wiki as part of its workflow, grounding its outputs in your accumulated knowledge rather than starting from scratch.

All three are reading the same wiki. All three give you answers grounded in the same source of truth.

Step 5 (Optional): Enable Allow Writes

With Allow Writes enabled, the knowledge flow becomes bidirectional. Any connected client can contribute back to the wiki.

Useful patterns:

  • IDE assistant adds notes on what worked — your Cursor agent discovers a solution to a recurring problem and writes a note to the wiki. Next time the problem comes up, every tool knows the answer.
  • Research agent files its findings — an agent that monitors a topic area can write its weekly summary directly to the wiki, where the Ingestor will incorporate it into the broader knowledge structure.
  • Meeting notes auto-ingested — drop meeting notes into Raw Sources from any client; the Ingestor compiles them into the wiki on the next cycle.

Heads up

Allow Writes means any connected client — including external AI tools — can modify your knowledge base. Use it deliberately. The recommended pattern: enable Allow Writes for trusted clients (your own agents, Cursor in a controlled project), and keep it disabled for public-facing or shared Connector endpoints.

The Lint Agent: Post-Action Verification

The Lint agent is the quality layer. It runs independently after each Ingestor cycle and does three things:

  1. Checks coherence — are the wiki pages internally consistent? Does page A contradict page B?
  2. Verifies links — are cross-references between pages still valid after the latest ingest?
  3. Flags contradictions — if a new source contradicts something already in the wiki, the Lint agent surfaces the conflict for review rather than silently overwriting it.

This is the post-action verifier pattern — a separate agent that checks the work of the writer agent. It's how you maintain knowledge base integrity at scale without manually reviewing every ingest cycle.


Use Cases: What This Looks Like in Practice

Use Case 1: The Developer with a Shared Codebase Context

Alex is a solo developer working across multiple projects. Each project has its own architectural decisions, conventions, and gotchas — the kind of institutional memory that normally lives in your head and nowhere else.

He set up a knowledge-wiki Space with one wiki per project. Each wiki contains: architecture decisions, debugging notes, API quirks discovered through use, and code conventions. The Ingestor runs whenever he drops in new notes.

All his AI tools — Cursor for coding, Claude Desktop for thinking, a custom research agent — are connected to the same Connector endpoint. When he opens a new Cursor window on a project, it already knows the context. When he asks Claude about a design decision, it reads from the wiki. When his research agent writes a summary, it files it to the wiki automatically.

Result: zero re-briefing. Every tool starts informed. The institutional memory he used to carry in his head is now portable and persistent.

Use Case 2: The Research Team with a Shared Knowledge Base

A four-person research team at a consultancy was drowning in source material — papers, reports, transcripts, client briefs. Each researcher had their own notes. Nothing was shared. Every new project started from scratch.

They set up a shared Knolo Space with the knowledge-wiki skill. All researchers drop sources into the Raw Sources Mind. The Ingestor compiles them into a shared wiki. Every researcher's AI tools — different clients, different preferences — connect to the same Connector endpoint.

Now when one researcher ingests a relevant paper, every team member's tools know about it. When the Lint agent flags a contradiction between two sources, the team resolves it once and the resolution lives in the wiki. The knowledge base compounds across the whole team, not just one person.

Result: onboarding new team members takes days instead of weeks. Client briefs are grounded in the accumulated research. No one starts from scratch.

Use Case 3: The Solo Operator's Personal Second Brain

Sophia runs a one-person consulting practice. She reads constantly — newsletters, reports, client conversations, industry analysis. The problem: none of it was connected. Notes in one app, bookmarks in another, ideas in a third.

She set up a Knolo Space as her personal second brain. Everything she reads goes into Raw Sources. The Ingestor compiles it into a wiki that cross-references ideas across sources. Her AI tools — Claude Desktop for writing, ChatGPT for quick questions, a custom agent for weekly research digests — all connect to the same Connector.

When she's writing a client proposal, Claude Desktop reads from her wiki and grounds the proposal in her actual accumulated thinking — not generic AI output. When she asks ChatGPT a question, it can reference what she's already learned on the topic.

Result: her AI tools feel like they know her. Because they do.


Why This Matters: The Narrative

Most tools do one-shot RAG — ask, retrieve, answer, forget. Knowledge never accumulates. The next session starts from zero.

The knowledge-wiki skill makes knowledge compound. The Connector makes that compounding brain portable. Together, they solve the AI amnesia problem at its root: not by giving each tool better memory, but by giving all tools access to the same memory.

The Karpathy framing is the right one: instead of re-reading raw sources on every query, the LLM maintains a compiled, cross-referenced wiki. Queries get answered from the wiki. The wiki gets better over time. And with the Connector, that wiki is reachable from everywhere — not trapped in one tool.

This is the architecture that makes AI tools feel like they know you. Because they're all reading from the same place: your brain.


Frequently Asked Questions

What MCP clients does the Connector work with?

Any MCP-enabled client. As of June 2026, that includes Cursor, Claude Desktop, ChatGPT (via Custom Connectors), and any custom agent built on an MCP-compatible framework. The Connector exposes a standard MCP server interface — if a client supports MCP, it works with Knolo.

Can multiple teammates share the same Space and Connector?

Yes. A Knolo Space can have multiple Connector keys — one per teammate, or one shared key for a team. Each key can have different permissions (read-only vs. read-write). The knowledge base is shared; the access control is per-key.

Does Allow Writes mean any AI tool can modify my knowledge base?

Only connected clients with a valid knc_ key can write. Allow Writes is a toggle that enables the write capability for connected clients — it doesn't open your Space to the public. You control which clients have keys, and you can revoke keys at any time. The recommended pattern is to keep Allow Writes disabled for clients you don't fully control, and enable it only for trusted agents and tools.

What's the difference between the Connector and just using Knolo's built-in assistant?

Knolo's built-in assistant (the Wiki Librarian) is great for querying your knowledge base from inside Knolo. The Connector extends that access to external tools — your IDE, your AI clients, your custom agents. The Connector is how your existing tools get access to your Knolo knowledge base without you switching contexts.

How often does the Ingestor agent run?

The default schedule is every 6 hours. You can change this in the agent settings — hourly for fast-moving knowledge areas, daily for slower-moving research. You can also trigger the Ingestor manually at any time from the agent panel.

Does this work with self-hosted MCP servers?

The Knolo Connector is a cloud-hosted remote MCP server — no Docker, no local setup, no maintenance. It's designed to work with any MCP client that supports remote server URLs (as opposed to local stdio servers). Cursor, Claude Desktop, and ChatGPT all support remote MCP servers as of 2026.


Get Started

The fastest path to a connected brain:

  1. Install the knowledge-wiki skill at knolo.io/skills
  2. Drop in 3-5 sources you care about (articles, notes, PDFs)
  3. Let the Ingestor run once
  4. Go to Space Settings → Connector, generate a key, copy the endpoint URL
  5. Paste it into Cursor, Claude Desktop, or ChatGPT
  6. Ask a question that requires your knowledge — watch it answer from your wiki

The whole setup takes under 15 minutes. The brain compounds from there.

Knolo skill

Knowledge Wiki

A self-maintaining knowledge base that compiles sources into interlinked wiki pages — powered by the Karpathy LLM Wiki pattern.

Install the skill →


Related reading: What Is an AI Workspace? Complete Guide for 2026 · How to Create an AI Agent for Your Business Without Coding in 2026 · What Is Multi-Agent AI? A Plain-Language Guide for Non-Technical Teams · Knolo vs. Zapier MCP: Which Should You Use to Automate Your AI Tools?

Keep reading

Build your own AI system with Knolo

Describe what you want and Knolo builds it. No code, no nodes, no setup time.

Try Knolo free