AI
-
Jina AI - Your Search Foundation, Supercharged.
Embeddings, rerankers, web reader, deepsearch, small language models. Search AI for multilingual and multimodal data.
-
The Capture Trap: Why Your Note Vault Is a Graveyard
Open your notes app and scroll to the bottom of the inbox. How many of those clippings have you reread? How many turned into anything? The answer is probably “almost none.” You have hundreds of saved articles, and half-finished thoughts, and the pile only ever grows. That’s not a second brain. That’s a graveyard.
I walked through Forte’s CODE workflow recently, four stages from Capture to Express. This post is about the stage everyone skips, and why skipping it is so easy that most vaults quietly die of it.
Capture feels like work. It isn’t.
Clipping an article gives you a little hit. You found something useful, you saved it, you can close the tab and feel like you made progress. But you didn’t learn anything. You filed it. The act of saving stands in for the act of understanding, and your brain happily accepts the substitution.
The Zettelkasten people have a name for this: the collector’s fallacy. Gathering material feels like knowledge work, so you keep gathering, and the gathering itself becomes the hobby. The collection grows. Your understanding doesn’t. You end up with a beautifully organized library you’ve never read.
Capture is frictionless now, which makes the trap worse. Web clippers, voice memos, a hotkey that drops anything into your inbox. The easier it gets to collect, the faster the graveyard fills.
Express is where the value is, and it’s the part that hurts
Express is the stage where you do something with a note: write the post, make the decision, ship the code, send the reply. It’s the only stage that produces anything. It’s also the one that takes effort, because it forces you to actually think about the material instead of just owning it.
So it gets deferred. Forever. And a vault where nothing ever reaches Express is just an expensive way to forget things slowly.
The fix isn’t more capture discipline or a prettier folder structure. It’s making Express the default destination of a note instead of an optional last step you’ll get to someday.
Give every note a lifecycle
Stop treating notes as either “saved” or “not saved.” Give them a status, a small piece of frontmatter that says where the note is in its life:
rawis something you captured and haven’t processed.distilledis a note you’ve summarized in your own words.expressedis one that fed into actual output.
Now your vault has a pulse. You can query it. “Show me everything still sitting at
rawfrom the last two weeks” turns the invisible backlog into a list you can act on. The graveyard problem was always that dead notes looked exactly like live ones. A status field makes the dead ones visible.Point an agent at the backlog
This is where it gets fun, and where a CLI agent that can read your vault earns its keep.
Once notes carry a status, you can hand the boring half of Express to an agent. Wire up a weekly job that does three things:
- Query every note still sitting at
raw. - For each one, draft a two-sentence summary and a single question: is this worth keeping, and what would you make from it?
- Drop the results in front of you as a short review list.
You’re no longer staring at a wall of three hundred clippings. You’re answering ten questions about ten notes, and the agent did the reading. The notes you keep get promoted to
distilled. The ones you don’t get archived without guilt. Either way they leave the inbox, which is the whole point.The model as a sparring partner
The last piece is using the model to get from a distilled note to actual output. Hand it a cluster of related notes and an outline, and ask it to argue with you. Where’s the thesis weak? What’s the counterargument? What example would make this land?
The model doesn’t write the thing for you, and you don’t want it to, that’s how you end up with generic mush in your own voice. It pushes the note one stage further down the pipeline, from a pile of research into a draft with a spine. You take it from there.
That’s the anti-graveyard loop. Capture stays frictionless, because friction there is bad. But every captured note now enters a pipeline that pushes it toward output instead of letting it rot in an inbox. The status field makes the backlog visible, the agent works it down for you, and the model helps you ship.
A vault isn’t valuable because of what’s in it. It’s valuable because of what comes out. Build the part that gets things out, and the graveyard turns back into a brain.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
Sources
- Tiago Forte, Building a Second Brain (2022) — the CODE workflow and the “Express” stage as the antidote to collect-and-forget note-taking.
- Christian Tietze, “The Collector’s Fallacy” (Zettelkasten.de, 2015) — why gathering material feels like learning when it isn’t, and how the collection becomes the hobby.
-
Four Ways to Build Your Own Agentic Harness
The model is the commodity. You rent it. Everything else, the loop, the tools, the state, the permissions, the memory, the orchestration, is the harness. And the harness is the part you get to own.
So the real question, when people say they want to “build their own agent,” isn’t which model. It’s how much of the scaffolding you want to inherit versus how much you want to build yourself. That’s the whole decision. Where you land on that spectrum gives you, more or less, four approaches.
A: Build on top of a full harness
This is the composition-heavy approach, and it’s the one I’ve mostly done. You take a fully featured harness like Claude Code or opencode (and I think a few of the newer agentic IDEs support this now too), and you extend it. Sub-agents, skills, slash commands. You can call these things remotely with CLI commands and wire your own behavior around them.
There are two flavors here. You can build your harness inside the existing one, or you can build it around the existing one. Either way, you own all the agent definitions, the skills, the model choices. But you inherit a lot too: which tools the agent can call, the permission model, all the safety controls. You don’t get to change those, you just get to use them.
And honestly? That’s the appeal. You don’t start from scratch. Somebody already solved the boring, dangerous parts. You show up and build the part you care about.
B: Self-host a fully open harness
This one looks a lot like A, but with one important difference: the underlying harness is open. You’re self-hosting and extending something fully open-source, then polishing and tailoring it to your needs.
The trade is control. In approach A, the tools and permissions and controls are handed to you and you live with them. Here, the entire stack is yours to crack open. If the permission model annoys you, you change it. If you want a tool to behave differently at the loop level, you can reach in and do that. You’re still not building from nothing, but nothing is off-limits either.
C: Assemble from primitives
Now we’re getting low. With this approach you build your harness up from very minimal pieces. Think of it like a full-stack framework in the web world, except for agents. Something like pydantic-ai’s SDK, or pulling aider in as a library rather than running it as a tool.
You don’t start from absolute zero, but you’re close. You define the agent loop yourself. You register the tools. You add the features you need, one at a time. You’re scaffolding basically everything, and all you’re inheriting is a handful of core primitives that you get to shape into whatever you want.
This is the approach for people who have opinions and want to express all of them. It’s more work. It’s also the most yours.
D: An agentic harness framework
The last one is a different animal, and I’ll admit it took me a second to see why it’s its own category. These are orchestration frameworks like LangGraph or Letta (formerly MemGPT). They’re not coding CLIs. They’re SDKs for building a custom agent application: graphs, state machines, first-class memory.
The distinction that finally clicked for me is what you’re building. With A through C, you’re mostly building a personal dev tool, something that helps you write code. With D, the harness is the product. You’re shipping it. A domain agent, a service, a customer-facing thing that happens to be agentic under the hood. The orchestration framework is what you reach for when the agent isn’t your tool, it’s your deliverable.
So where do you land?
There’s no correct answer here, just a trade you’re making on purpose. The more you inherit, the faster you move and the less you control. The more you build, the more it’s yours and the more of the boring, dangerous plumbing you’re now on the hook for.
For most of what I do, A is the sweet spot. Building around and within an existing harness is just so much easier than starting cold, and I’d rather spend my time on the agent definitions than on reinventing a permission model. But if I were shipping an agent as a product instead of a tool, I’d be over in D without thinking twice.
Figure out which thing you’re building first. The approach falls out of that.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
Sources
- Anthropic, “Claude Code” (GitHub) — documentation and repository for the terminal-based agentic coding tool that reads codebases, runs commands, and integrates MCP servers.
- Aider AI, “Aider” — official documentation and pair-programming guides for the open-source, git-native AI coding assistant.
- Anomaly Co., “OpenCode” — official homepage and repository for the open-source terminal, desktop, and IDE-based AI coding agent.
- Pydantic, “Pydantic AI” — official documentation and API references for the type-safe Python agent framework designed for structured agent trajectories.
- Letta AI, “Letta” (GitHub) — repository for the stateful agent runtime (formerly MemGPT) that manages persistent memory tiers and agentic state machines.
-
Five Places RAG Shows Up in Agentic Systems
Ask most people what RAG is and they’ll tell you it’s semantic document search. You chunk up a pile of text, embed it, stuff it in a vector database, and pull the relevant bits back at query time. That’s the textbook example, and it’s a good one. But retrieval augmented generation does a lot more work inside agentic systems than “search the docs,” and I think it’s worth walking through where it actually shows up. So let’s talk about it.
1. High-Precision Semantic Search
This is the one everybody knows, so let’s get it out of the way first. You take raw text and convert it into high-dimensional vectors, where distance corresponds to conceptual similarity. Store those vectors, index them, and you can look things up by meaning instead of exact keywords.
The interesting part is how you index them, because the algorithm you pick is a real tradeoff.
HNSW (Hierarchical Navigable Small World) builds a multi-layer graph. The upper layers have long-distance links for fast routing across the space, and the lower layers have short-distance links for local search. You get low query latency and near-perfect recall. The catch is memory. It wants to keep the raw vectors around, so the footprint gets big.
IVF-PQ (Inverted File with Product Quantization) goes the other direction. It partitions the vector space into cells using k-means clustering, then compresses the high-dimensional vectors into compact quantized codes. Partition, then squish. That cuts memory consumption dramatically, which makes it a great fit for massive datasets with millions of vectors. The price you pay is recall accuracy, since all that compression throws away detail, and rebuilds get slower when you add new data.
Neither one is “correct.” You pick based on whether you’re optimizing for recall or for fitting the index in memory.
2. Tool Selection (RATS)
Here’s where it gets less obvious. Picture a CLI harness. As your developer toolkit grows, your agent slowly gets “equipped” with dozens or hundreds of possible actions. APIs, database calls, helpers, command executors. At some point you’ve just overloaded the thing with too much stuff.
Three bad things happen when you do that:
- Tool space interference (TSI). Overlapping tool descriptions confuse the agent, and it calls the wrong one.
- Context window saturation. Every tool schema, whether it’s JSON or Markdown, eats thousands of tokens. Pile up enough MCP servers and custom skills and you’re soaking the context window, which drives up cost and latency.
- The lost-middle problem. Models tend to ignore tools and instructions buried in the middle of a very long prompt.
Retrieval augmented tool selection fixes this by treating your tools like a corpus. Instead of dumping every schema into the prompt, you retrieve only the handful of tools relevant to the current task. The agent sees a short, sharp menu instead of the entire pantry.
3. Dynamic Few-Shot Prompting
Few-shot prompting is a reliable way to enforce formatting constraints like a strict JSON schema, teach reasoning paradigms like chain of thought, or train an agent on error recovery. The problem is that static examples baked into a prompt are a guess. They might not match the task in front of you.
RAG lets you select the examples at runtime. You curate a database of gold-standard trajectories, each one pairing a specific query or error case with the correct step-by-step reasoning, tool calls, and final output that solved it. When a new task comes in, you search that database using the user’s intent, grab the top few most similar past trajectories, and prepend them to the system instructions.
So the agent always gets examples that actually resemble what it’s being asked to do, instead of whatever examples you happened to hardcode three weeks ago.
4. Long-Term Agent Memory
Work directly with a model and it forgets everything the moment the session closes. Your preferences, your corrections, the choices you already made. Gone. For an agent to be useful, it needs persistent memory across sessions. I’ve written about this before.
One system here is mem0, which uses a hybrid RAG architecture to persist state. It does asynchronous fact extraction, conflict resolution when new information contradicts old, and grounds the retrieved memories back into the prompt. The retrieval layer is what lets the agent surface the right past fact at the right time instead of replaying the entire history.
5. Evaluation and Test Harnesses
Testing AI in production is hard because the outputs aren’t deterministic. So you build evaluation harnesses that run your agent across hundreds of test cases, and RAG turns out to be a quiet workhorse in that loop.
Two ways it helps:
- Diffing the test suite. Running every eval on every pull request is slow and expensive. Instead, query a vector index of your test suite using the git diff as the query, and run only the cases relevant to the code you actually touched.
- Semantic assertions. Exact string matching is useless when you’re verifying something like an agent’s summary. Instead, the harness retrieves historic successful runs and uses vector similarity to ask whether the new output matches the intent and tone of the target, rather than matching it character for character.
None of this replaces the document-search version of RAG. It’s the same core trick, embed things, retrieve by similarity, ground the result, pointed at different problems: which tool, which example, which memory, which test. Once you start seeing retrieval as a general-purpose way to feed an agent the relevant slice of a much bigger pile, it shows up everywhere. I’ll probably keep finding more.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
Sources
- Yury A. Malkov and Dmitry A. Yashunin, “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs” (arXiv:1603.09320, 2016) — details on the multi-layer graph architecture and logarithmic complexity of the HNSW index.
- Hervé Jégou, Matthijs Douze, and Cordelia Schmid, “Product Quantization for Nearest Neighbor Search” (IEEE Transactions on Pattern Analysis and Machine Intelligence, 2011) — explains compressing high-dimensional vectors and combining product quantization with inverted file indexing (IVF-PQ).
- mem0ai, “mem0: The Memory Layer for Personalized AI” (GitHub) — documentation and codebase for the persistent, self-improving memory layer for AI agents.
- Mostafa Ibrahim, “Agentic RAG vs Classic RAG: From a Pipeline to a Control Loop” (Towards Data Science, March 2026) — commentary on the shift from static document retrieval to agentic control loops and its associated system failure modes.
- Microsoft Research, “Tool-space interference in the MCP era: Designing for agent compatibility at scale” — the tool-space interference (TSI) problem from section 2, where overlapping tool descriptions degrade agent tool selection.
- rewire.it, “Dynamic Tool Allocation for AI Agents (The RATS Pattern)” — the retrieval-augmented tool selection (RATS) pattern from section 2: a router retrieves a relevant subset of tools from a larger catalog.
-
A Field Glossary for Agentic Knowledge Work
Everywhere you look right now, somebody is saying agentic this and agent that. Harness, scaffold, skill, subagent, agentic OS. The vocabulary is piling up faster than anyone can keep track of, and a lot of it gets used loosely, sometimes by people who don’t actually know what the words mean.
So I figured I’d write down my own working glossary. This isn’t a textbook, and I’m not pretending these are official definitions. It’s how I think about the terms when I’m doing the work. If you’ve been nodding along in conversations without being totally sure what a harness is, this one’s for you.
Agent
There are a lot of flavors of agent, and I’m not going to catalog all of them. Generally speaking, an agent is some code wrapped around an LLM that runs in a loop, has access to tools, and can act using those tools.
That’s the key difference from a plain prompt-and-response call. A direct call to the model gives you one answer and stops. An agent has some degree of autonomy. It can decide to use a tool, look at the result, and keep going. The loop and the tools are what make it an agent instead of a chatbot.
Harness
A harness is the program that sits on top of the model. It manages conversation state, runs the reasoning loop, gives the model access to tools, and enforces the guardrails, things like permissions, controls, and budget.
Here’s an easy way to understand it. The model is the intelligence. The harness is the control on the intelligence. The harness sits between you and the LLM.
A harness can show up in a lot of places. It might be a CLI. It might be a GUI or an app on your phone. It might be a chat thread. You could wire up something like OpenClaw to talk to you in WhatsApp or Telegram, and that chat becomes your harness, while OpenClaw is also a harness underneath. So yes, harnesses can call other harnesses. It’s turtles a little way down.
Scaffold
You’ll hear people say scaffold or scaffolding. This is usually just another word for harness. The prompt, the tools, and the control structure wrapped around the model. Same idea, different label.
Framework or SDK
These are the libraries you build harnesses with. LangChain, the various agent SDKs, or a ready-to-run harness like Claude Code or Hermes.
Worth flagging that framework and SDK mean something specific in regular programming. In the agentic context they’re a little looser. They’re what you build agents and harnesses out of. And it doesn’t have to be off-the-shelf. You can absolutely build your own framework for building your own harnesses if that’s where your head is at.
Context Engineering
This is the big one. The term comes from Karpathy, and while it mattered even more a year ago than it does today, it still applies.
Context engineering is deliberately managing what’s in the context window of the current session. It’s the work of deciding what gets loaded into context and, just as importantly, what gets left out. It’s the successor to what we used to call prompt engineering. The framing shifted because the prompt is only one piece of what the model sees, and the rest of it matters a lot.
MCP
Model Context Protocol. I won’t go deep here, it deserves its own post. MCP is an open protocol for exposing tools and data to an LLM harness. It’s the standard way for your harness to reach out and use third-party software or pull in outside data.
Skills
Skills are a major, important thing, and I’m not going to do them justice in a glossary entry. But here’s the definition.
A skill is a reusable, often self-created capability that bundles up the instructions an agent needs to accomplish a specific task. You can find skills all over the internet now. Everybody’s got their own. You can generate your own pretty easily with the CLI, and harnesses like Claude Code or Hermes can even author their own skills. The word does the work here. Skills are capabilities. It’s how you extend what your agents and harnesses can actually do.
Subagent
A subagent is an isolated child agent spawned from inside a working session.
Say you’re in your harness of choice with a main session running. That orchestration session can fork off a new agent with its own context window, hand it a specific task, and say go do this. The subagent runs on its own, often in parallel with others, working in the background. The main session knows when it finishes and can check the work.
A lot of the time you’ll have a second subagent review the first one’s output. That review loop is the whole idea behind the agentic maturity model, which is a way of thinking about how to structure this kind of work. It’s on GitHub if you want to dig in.
Agentic OS
This is an orchestration layer that combines agents, memory, and tools. It’s not really an operating system, but the name has stuck. You take all these concepts, the skills, the agents, the memory, the tools, and combine them into one organized whole. People are calling that amalgamation an agentic OS.
Second Brain / PKM
A personal knowledge vault. I posted about this just this week. It’s a personal knowledge base that the model can read, search, and extend. Your notes, your references, your accumulated thinking, made available to the agent.
Vibe Coding vs. Agentic Engineering
This is the distinction I care about a lot.
Vibe coding is not really knowing what you’re doing or how it’s being done. Anyone can vibe code. You describe what you want and you accept what comes back.
Agentic engineering is knowing what you’re doing and caring about how it gets done. Not everyone can do that part.
The way people put it is that vibe coding raises the floor and agentic engineering raises the ceiling. Vibe coding lets anyone build something. Agentic engineering lets a professional move a lot faster than they used to. Both are real. They’re not the same thing.
That’s the glossary, at least the version that lives in my head. None of these terms are settled, and half of them will probably mean something slightly different in six months. But hopefully this has helped!
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
Sources
- Vibe coding — Wikipedia — the term coined by Andrej Karpathy (Feb 2025); the “vibe coding vs. agentic engineering” distinction the post draws.
- Andrej Karpathy, "+1 for ‘context engineering’ over ‘prompt engineering’" (X, June 25, 2025) — the origin of the term “context engineering” as the successor to prompt engineering.
- Model Context Protocol — Wikipedia — MCP as the open standard introduced by Anthropic (Nov 2024) for exposing tools and data to LLM harnesses.
- Emma Roth, “Anthropic launches tool to connect AI systems directly to datasets” (The Verge, Nov 25, 2024) — news coverage of the MCP launch.
- Agentic Maturity Model — GitHub — the AMM referenced in the Subagent entry; Level 3 describes the worker-plus-reviewer subagent pattern.
-
Two Kinds of Memory for Your CLI Agent
So you set up a memory layer for your local CLI agent. Now what? How do you actually get that memory in front of the agent so it does something useful?
I’m going to walk through what I did with mem0, but the shape of this applies to pretty much any memory layer. The first thing worth understanding is that CLI agents work with memory in two very different ways, and the difference matters.
The first way is text that’s always loaded. It gets injected into every session’s context automatically. No action needed on the agent’s part, it’s just there. This is your guaranteed data, the stuff that shows up at the start of every conversation.
The second way is semantic memory. For me that’s mem0 and the tooling I’ve built around it. This layer is accessed through an MCP server that exposes commands like
recallandremember. It’s poll-based. The agent has to decide to callrecall, because nothing gets auto-injected. The agent needs to be smart enough to say “I’m not sure about this, let me go look it up.”Those are the two flavors. Let me break them down.
Layer 1A: The Shared Instructions File
For most CLI agents, this is a single markdown file that the harness auto-loads into every session. Claude Code reads
CLAUDE.md. Gemini and Antigravity readGEMINI.md. AndAGENTS.mdhas become the cross-tool convention, read by OpenCode, Antigravity, and Cursor alike. Same idea everywhere, just a different filename.The one rule here: keep it minimal. Every line in this file is context you’re paying for on every single session. So don’t dump your whole knowledge base into it. The durable conventions, the project-specific facts, the things you only occasionally need? Those belong in your semantic layer, not here. This file is for the handful of rules that need to be loaded 100% of the time.
Layer 1B: Auto-Memory
Claude Code shipped a feature called auto-memory. It lives in
~/.claude/projects/, inside a subfolder that’s basically a slug of your project’s path on disk. In there you get amemoryfolder with aMEMORY.mdfile alongside the individual memory files.MEMORY.mdworks like an index. It holds short pointers to the durable memories stored next to it, and the whole thing gets loaded every session. It’s still part of layer 1, the always-loaded kind.Worth noting: this is a Claude Code thing. OpenCode and Antigravity don’t load or even know about these files. There’s no equivalent. Antigravity does have its own separate memory store that it syncs on its own, but it’s a different mechanism entirely, not a reader of Claude’s auto-memory.
Layer 2: The Semantic Layer
This is where it gets fun. I built a small MCP server in Go, a local binary that forwards requests to another server on my network. That server talks to two databases: Qdrant for the vectors, and Neo4j for the graph. The three functions I lean on most are
recall,remember, andadd_relation.If MCP is new to you, the short version: it’s an open standard that lets your agent connect to external tools and data over a common protocol. Instead of N bespoke integrations, you run one MCP server per capability and the host discovers it. People call it “a USB-C port for AI,” which is annoying and also pretty accurate.
Wiring it up is just config. For Claude Code, it goes in
~/.claude.jsonunder the top-levelmcpServers.memoryblock. For OpenCode, it’s~/.config/opencode/opencode.jsonundermcp.memory, withtype: localand a command that runs the binary.The Part People Forget
Here’s the step that ties it all together. Setting up the MCP server doesn’t do anything on its own. Remember, the semantic layer is poll-based. The agent won’t call
recallunless it knows it should.So you go back to layer 1, your always-loaded instructions, and you add a few lines telling the agent how and when to use the MCP server. Something like “before answering questions about this project, call
recallwith a relevant query” and “when the user tells you something worth keeping, callremember.” That instruction is small, it’s cheap, and it’s what turns a dormant memory store into a memory layer the agent actually reaches for.That’s the whole architecture. Always-loaded text that’s guaranteed but expensive, and a semantic store that’s huge but only as good as the agent’s instinct to go check it. Get both layers talking and your agent stops forgetting who you are every morning.
Sources
- mem0 — GitHub — the universal memory layer for AI agents that the post describes wiring up; 59.6k stars, Apache 2.0.
- Model Context Protocol — Wikipedia — MCP as an open standard introduced by Anthropic (Nov 2024) for connecting AI systems to external tools and data sources.
- Emma Roth, “Anthropic launches tool to connect AI systems directly to datasets” (The Verge, Nov 25, 2024) — news coverage of the MCP launch; confirms the “USB-C port for AI” framing and the standard-protocol pitch.
- Jonathan Kemper, “Claude Code now remembers your fixes, your preferences, and your project quirks on its own” (The Decoder, Feb 27, 2026) — news coverage of the auto-memory feature; confirms the
MEMORY.mdper-project file and the~/.claude/projects/directory structure. - How Claude remembers your project — Claude Code Docs — official documentation for
CLAUDE.mdfiles and the auto-memory system.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
-
Karpathy's LLM Wiki: Your Second Brain, Maintained by the Machine
A few months ago Andrej Karpathy dropped a GitHub gist that coined a term I haven’t stopped thinking about: the LLM Wiki. The pitch is simple enough to fit on a napkin. Obsidian is the IDE, the LLM is the programmer, and the wiki is the codebase.
Sit with that for a second. It reframes your second brain as something the model builds and maintains, not something you query. When I walked through the history of the second brain, this is the corner I promised to come back to.
Compile, Don’t Retrieve
The usual move with a big pile of notes is query-time RAG. You ask a question, some vector embeddings go find the closest chunks, and the model stitches together an answer on the spot. It works, but the knowledge never gets organized. You’re re-deriving structure every single time you ask.
Karpathy flips it. Instead of retrieving at query time, the LLM compiles the knowledge ahead of time and keeps it current. The result is a persistent, cross-linked markdown wiki. The model doesn’t get bored, doesn’t skip the boring summary, doesn’t forget to update the index. It just keeps the thing tidy.
Google landed in a similar spot with their Open Knowledge Format (OKF), which formalizes the same idea as a curated markdown bundle with an open spec. So this isn’t one person’s hot take. The pattern is in the water.
The Three Components
Karpathy’s wiki has three parts, and the separation is the whole point.
Raw sources. Your curated collection of source documents. These are read-only. The LLM reads them but never edits them. He recommends a
raw/directory, with subdirectories for non-text files. This is your ground truth, and keeping it untouchable is what keeps the rest honest.The wiki. A directory of LLM-generated markdown: summaries, entity pages, concept pages, comparisons, overviews. The model owns this entirely. It creates the pages, maintains the cross-references, and enforces consistency. You’re not in here hand-editing.
The schema. A document like
CLAUDE.mdorAGENTS.mdthat tells the LLM how the wiki is structured, what the conventions are, and how the workflows run. It evolves as you use the system. Think of it as the contract between you and the machine.The Three Operations
The classic Second Brain CODE method has four steps. Karpathy’s version lands on three operations, which I appreciate.
Ingest. You add a source. The LLM reads it, writes a summary page, and updates the index. While it’s in there, it can also touch up related entity and concept pages and log the event. One new document ripples outward into everything it connects to.
Query. You ask a question against the wiki. The model finds the relevant pages, reads, and synthesizes an answer as markdown, tables, whatever fits. Here’s the part I like: a useful exploration can be filed as a new page. So the act of asking a good question makes the next answer easier to produce. The knowledge base gets smarter by being used.
Lint. A periodic health check. The model hunts for contradictions, stale claims, orphan pages, broken references, and missing concepts. The gaps. Then it suggests new questions to ask and new sources to chase. It’s the maintenance pass you’d never do yourself.
The Supporting Cast
A few files make the whole thing run:
index.mdis the content catalog. Every page, a link, a one-line summary, and some metadata, grouped by category. The model reads this first on a query.log.mdis an append-only chronological log with greppable entries like## [DATE] operation | title.qmdis a local markdown search engine (BM25 plus vector plus an LLM re-rank), available as a CLI or MCP server, for when the wiki outgrows a plain index lookup.
And because this lives in Obsidian, you get some nice perks for free. The Web Clipper turns a browser tab into markdown straight into
raw/. Graph View is a visual lint, hubs and orphan pages pop right out. Dataview pulls frontmatter into dynamic tables. And Marp spits out slides directly from your wiki pages.Why This Clicks for Me
The thing I keep coming back to is the read-only
raw/boundary. So much of the anxiety around AI touching your notes is “what if it mangles something I care about.” Splitting sources from the generated wiki means the model can be as aggressive as it wants in the wiki layer, and your source of truth never moves. The worst case is you regenerate a summary page. No harm done.I haven’t fully committed my own vault to this yet, but the shape is right. A knowledge base that maintains itself, where asking good questions leaves the place better than you found it. I’ll probably keep poking at it.
Sources
- Andrej Karpathy, LLM Wiki: A Pattern for AI-Maintained Knowledge Bases — the three components (raw/wiki/schema), the three operations (ingest/query/lint),
index.md,log.md,qmd, and the Obsidian tooling (Web Clipper, Graph View, Dataview, Marp). - Sam McVeety & Amir Hormati, “Introducing the Open Knowledge Format” (Google Cloud Blog, June 12, 2026) — Google’s OKF as a curated markdown bundle with an open spec, explicitly formalizing the same LLM-wiki pattern.
- Tiago Forte, Building a Second Brain (2022) — the CODE method (Capture, Organize, Distill, Express), the “classic” four-step workflow this post lines up against Karpathy’s three operations.
- Roger Montti, “Google Cloud Announces The Open Knowledge Format” (Search Engine Journal, June 15, 2026) — independent news coverage of OKF, including the quote linking it back to Karpathy’s LLM Wiki gist.
- Cecilia Meis, “Google Launches Open Knowledge Format, an AI Standard” (Semrush Blog, June 23, 2026) — news coverage framing OKF as a vendor-neutral markdown spec for AI agent knowledge.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
-
A Brief History of the Second Brain
The phrase “second brain” is glued to Tiago Forte and the productivity wave of the 2010s. But the ambition behind it is nearly five centuries old, and the method is a lot older than the name. So let’s walk the timeline, because the story is more interesting than the buzzword.
It Starts With Slips of Paper
Go back to antiquity and you’ll find people keeping personal notebooks of quotes, recipes, and observations. The commonplace book. Nothing fancy, just a place to park the ideas worth keeping.
Things get more systematic in the mid-1500s. A naturalist named Conrad Gessner suggested cutting notes into individual slips and gluing them onto sheets so you could rearrange and reassemble ideas from pieces. That modular instinct, breaking knowledge into movable units, is the seed of what the Germans would later call the Zettelkasten, the “slip box.”
About a hundred years later, Thomas Harrison built the Arca Studiorum, the “ark of studies.” It was a literal cabinet where paper slips hung on labeled metal hooks, sorted by subject. The design was published posthumously by Vincent Placcius in 1689, which makes it one of the first documented personal knowledge devices. Leibniz reportedly relied on it for one of his projects. A hundred years after that, Carl Linnaeus was working with standard-sized paper slips, over a thousand of which survived. Basically the index card before the index card existed.
For roughly 300 years this stayed a scholarly habit. Researchers, clergy, naturalists, the PhD crowd. Not something the general public thought about.
The Idea Goes Electric (In Theory)
In 1945, Vannevar Bush wrote an essay in The Atlantic called “As We May Think,” and described the Memex: a desk-sized microfilm machine that would store all of your books, records, and correspondence, with mechanical “associative trails” linking related items together. It never got built. But read that description again and tell me it doesn’t sound like every linked-notes tool we use today.
Then comes the patron saint of the second brain: Niklas Luhmann. From the 1950s onward he built a Zettelkasten of around 90,000 index cards over four decades. Each card got a unique ID, each linked to others by ID, a physical knowledge graph made of paper. Out of it came dozens of books (some counts say 70) and hundreds of articles. He described the system as a thinking partner he could have a conversation with. His archive was digitized and put online in 2019, so you can go poke around in it.
Luhmann wasn’t a one-off. The 20th century is full of scholars running the same playbook:
- Walter Benjamin (Arcades Project, 1927-1940)
- Roland Barthes (12,250 cards)
- Hans Blumenberg (30,000+ cards)
- Arno Schmidt (100,000+ cards for Zettels Traum)
- Mario Bunge (70 books, 540 articles out of his card files)
The Computer Was Supposed to Be the Second Brain
Through the 1980s to the 2000s, we still didn’t have today’s vocabulary. We had the PIM, the personal information manager, and the PKM, personal knowledge management. The personal computer itself was pitched as the thing that would know everything about you.
Apple, Xerox, and Microsoft all took a swing:
- NoteCards (Xerox PARC, 1985) was modeled directly on 3×5 index cards with typed links, an early hypertext take on the slip box.
- HyperCard (Apple, 1987) handed people a hypertext stack system, and its card metaphor was a straight callback to the Zettelkasten. It’s also what inspired Ward Cunningham to build the first wiki in 1994.
- Outliners like MORE, Ecco Pro, and Lotus Agenda chased hierarchical thought.
- OneNote (Microsoft, 2003) was the first mass-market freeform digital notebook.
- Evernote (2008) nailed the capture half with “remember everything,” but stayed folder-and-tag based, never a graph.
Zettelkasten Goes Public
In 2017, a writing coach named Sönke Ahrens published How to Take Smart Notes. He translated Luhmann’s dense German academic method into plain English for students and knowledge workers, and put the slip-box workflow, capture, permanent notes, link, develop, in front of a non-academic audience for the first time.
Almost in parallel, Tiago Forte coined the modern “second brain” and aimed it squarely at the everyday knowledge worker. Through Forte Labs he taught PARA (Projects, Areas, Resources, Archives), an action-oriented filing system that rejects the Dewey Decimal instinct, and the CODE workflow (Capture, Organize, Distill, Express) for the life cycle of a note. The 2022 book Building a Second Brain turned it into a movement.
From Folders to Graphs
Then the tools caught up to Luhmann. Roam Research (2020) made bidirectional links the whole point. Its early adopters were overwhelmingly academics, PhD students, and writers, and they showed everyone what diligent linking actually buys you.
Obsidian launched around the same time and is what most people picture now. Local-first, plain markdown, bidirectional links, a huge plugin ecosystem, and a motto that matters: your data is yours. That’s the real pitch. With Roam, Evernote, or Notion you can get your data in, but getting it back out in a format you own is a different story. You’re renting access to your own thinking. Obsidian doesn’t do that. It’s just markdown files on your disk. For my money that makes it the default, and everything with lock-in is a harder sell.
Either way, the shift is the headline: we moved from folders and notebooks to graphs. Links and backlinks. The knowledge graph stopped being a Luhmann eccentricity and became the norm.
And Now You Hook It Up to an LLM
Which brings us to right now. Somewhere around 2023, people started asking the obvious question: what if you point a language model at your second brain? The best way I’ve found is through a CLI-based agentic harness like Claude Code, pointed at your notes. I’ve been running Claude Code against my own vault for over a year, and the same approach works with other agentic coders. OpenCode is good, and Google’s Antigravity (Gemini) has been pretty good too.
There are different strategies for structuring a vault so an agent can read and extend it, and I’ll dig into those in a future post. One you may have heard of is Karpathy’s recent “LLM wiki” idea, which isn’t just about plugging an LLM in, it’s an opinion about how to structure the vault so the model works well with it.
That’s the real evolution. For 500 years the second brain was storage you read from. Now it’s becoming something that reads and writes back.
Era Metaphor Key figure/tool What it solved 1540s-1890s Card file / commonplace book Gessner, Harrison, Linnaeus Modular scholarly notes 1945 Memex (associative trails) Vannevar Bush The idea of external memory 1950s-1990s Zettelkasten (linked slips) Niklas Luhmann Memory as a thinking partner 1980s-2000s PIM (folders, notebooks) HyperCard, OneNote, Evernote Digital storage 2010s Methodology + capture Tiago Forte (BASB, PARA/CODE) A repeatable workflow 2020-22 Knowledge graph Roam, Obsidian Connection over hierarchy 2023- Agent-readable wiki LLMs, Claude Code, Karpathy Active synthesis Gessner was gluing paper slips onto sheets so he could rearrange his ideas. We’re doing the same thing. We just gave the slip box a way to talk back.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
Sources
- Vannevar Bush, “As We May Think,” The Atlantic, July 1945 — the Memex proposal.
- Memex — Wikipedia — background on the Memex device and its hypertext legacy.
- Zettelkasten — Wikipedia — Gessner’s glued slips, Harrison’s Arca Studiorum (published by Placcius, 1689), Linnaeus’s paper slips, and the 20th-century card-file users (Benjamin, Barthes, Blumenberg, Schmidt, Bunge).
- Niklas Luhmann — Wikipedia — the ~90,000-card Zettelkasten, digitized and put online by the University of Bielefeld in 2019.
- NoteCards — Wikipedia — the Xerox PARC hypertext system (1985) modeled on 3×5 index cards.
- HyperCard — Wikipedia — Apple’s 1987 hypertext stack system; Ward Cunningham traces the wiki concept back to a HyperCard stack.
AI Obsidian Second brain Note-taking Zettelkasten Knowledge management
-
Six Months with Git-Native Issue Tracking: Am I Still Using Beads?
Back in January, I wrote about discovering beads, a git-native issue tracker built specifically for AI-assisted development. I was pretty hyped. Having agents track their own tasks natively inside the git repo felt like the missing link for long-running autonomous workflows.
It’s been six months. So, the inevitable question: am I still using it?
Short answer: yes, but no longer as my default.
So this is where my task-tracking workflow actually landed in mid-2026.
The Shift Away From the Default
In January, I was trying to force beads into every single project I spun up. New repo? Init beads. Quick experiment? Init beads. As the months went on, I realized I was over-engineering things.
For a lot of projects, the task tracking built into Claude Code is good enough for day-to-day work. If an agent just needs to hold a checklist for a couple of hours during a coding session, standing up a full git-native tracking system is overkill. The lightweight, ephemeral tasks handle that perfectly, and they disappear when the session ends, which is exactly what you want for session-scoped work.
Wrapping the Real Things
For durable issue tracking, I pivoted back to where the code already lives.
Instead of leaning on beads, I built a couple of custom agent skills that wrap the GitHub CLI (
gh) and the GitLab CLI (glab). Now when an agent needs to pull down tasks, update tickets, or log a blocker, it just talks directly to GitHub or GitLab through those wrappers.The split looks like this: the remote issue tracker is the source of truth, and lightweight Claude Code tasks handle immediate session context. That combination has been far more resilient for me than routing everything through a separate system. The truth stays where my teammates and my future self will actually look for it.
Where Beads Still Lives
I haven’t abandoned beads. It still sticks around on a handful of repos where it’s useful.
The big one is my Obsidian vault, the “second brain” I wrote about earlier this week. When I’m managing personal research, blog pipelines, or local-only projects that don’t need a heavy GitHub project board, the git-native approach is still fantastic. No remote, no API, no ceremony, just issues that travel with the repo. Version 1.0 leaned into that even harder by moving to an embedded Dolt backend, basically git for your database, so there’s no separate server to babysit and the full history lives right alongside the code.
Beads isn’t worse than I thought in January. It’s just a sharper tool than I was treating it as. I was reaching for it everywhere when it was really built for a specific shape of project.
The hype of January has settled into the pragmatism of June. Not every project needs a custom tracking system, and sometimes letting your agents talk to GitHub directly is the easiest path forward.
What are you using to keep your agents on task these days?
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].