785 articles for agents, not humans. A knowledge base without vector search

When an agent starts work in an unfamiliar project, it spends the first 30 to 40% of its tokens working out what is going on around it. Not working, orienting. This post describes Happyin Knowledge Space, a library of reference cards I write for agents rather than people: why the card format looks the way it does, why fast-moving domains carry a freshness threshold, why I link cards by hand instead of putting them in a vector database, and how research from chats on several accounts ends up there without any copy and paste. On 22 April 2026, when the Russian original came out, it held 785 cards in 26 domains.

Two problems with how an agent learns a project

A README explains motivation, a tutorial holds your hand, an API reference lists parameters. None of them answers the question the agent actually arrived with: here is my task, which pattern do I copy, and where are the landmines?

The second problem is deeper and takes longer to notice. A model knows "everything", but that everything is spread unevenly through its training data. The longer a technology has been on the internet, the more posts, Stack Overflow answers and tutorials exist about it, and the more weight that approach carries inside the model. When I ask Claude to train a LoRA, the first thing it offers is a recipe from five years ago. Not because it is better, but because there is more of it. For stable technologies that is fine. For anything moving fast, such as model training, agent tooling or security, it means the agent quietly pulls me into the past.

The obvious cure is to run deep research every time and bring in current context. I do. But deep research is expensive: several hundred dollars a month in subscriptions, and the limits still run out almost at once. Worse, each research run disappears with its session. Tomorrow I will run the same search on the same topic and spend the same tokens on what I already found out.

Two ideas came out of this. Research should accumulate, not evaporate. And the format should show the agent what is current now, so that opening a project drops it straight into "this is how it is done here".

The format: a card, not an article

Every card has the same skeleton. At the top, the topic and a one-sentence definition, so the agent knows at once whether it has landed in the right place. Then Key Facts: short statements with numbers, such as versions, thresholds and dependencies. Then Patterns: copy-pasteable code with a language tag. At the bottom, the gotchas, each as a pair of what breaks and what fixes it.

No "let us take a look" introductions and no "in this article we examined" endings. The Kafka broker-architecture card is a ZooKeeper-versus-KRaft table, a commented config, JMX metrics with alert thresholds and a step-by-step migration. It does not read smoothly. But an agent greps "KRaft migration" and gets a working recipe in three steps.

The last block is the most valuable. One line, "min.insync.replicas only takes effect with acks=all", saves half an hour of debugging. The agent read it, did not make the mistake, and did not burn a retry cycle fixing it.

26 domains, grown out of work

In April the largest domain was Image Generation with 58 cards, closely followed by LLM Agents with 57, then Data Science and Security with 56 each (Security grew through a separate folder on CWE classes). After them came Kafka with 43, DevOps 38, Web Frontend 36, Data Engineering 34, and four domains at 33: Python, SQL, Architecture and Algorithms. Fourteen smaller ones made up the rest: iOS, Linux CLI, C++, Java Spring, Testing and QA, BI, SEO, Rust, Node.js, PHP, LLM Memory, Audio and Voice, Writing, and Go.

This is not a plan. It is a map of where my time actually goes when I work with agents: training LoRAs, debugging C++ plugins, research. Every area had collected its own list of places where something broke for me, and those lists became the skeleton.

Knowledge does not age at one speed

Algorithms and mathematics are stable: a card on amortised analysis or network flow written three years ago is still correct. Diffusion training, inference optimisation and ComfyUI nodes change every few months, and what worked in autumn has moved on by spring. Tiled diffusion on very large photos, which I wrote about in Why diffusion draws seams on 40-megapixel photos, is one of those fast-moving topics.

So each domain carries its own freshness threshold. Stable domains have none. In fast domains, a card older than 60 days is marked for review, and a hook that runs once a day puts it on a "check and update" list. It is not a deletion alert. It is a reminder that the topic has probably moved and the card needs checking against what is true now. Stale cards come up for review by themselves instead of quietly misleading the agent.

Links instead of vectors

The obvious architecture for this is a vector database with RAG on top. It finds semantically close text quickly and works well in production. I deliberately did not use one, for three reasons.

A vector store is not human-readable. Markdown I can open in a text editor, grep, diff in git, paste into an email, or print and pin to a wall. That works today and will work in ten years on any computer, with no special tooling. A vector store is a binary that only its own client understands. Change vendor, lose the service, break the API, and the data becomes a pile of numbers nobody can read. I wanted the knowledge base to survive a change of tools, not depend on them.

Vectorisation is close to irreversible. An embedding is lossy, one-way compression. Without the original chunks stored next to it, a file of embeddings is useless, because getting readable text back is close to impossible. Research on embedding inversion exists, but it works on very short fragments, needs the same embedding model, and needs a separately trained decoder. It also ties you to one embedding model: switch models for better quality and you re-index everything, because old vectors mean nothing in the new space.

And the one that matters most to me: a link graph records which topics are adjacent, not which texts are similar. Vector similarity finds topics that overlap in vocabulary and concepts. In real work the valuable links often run between topics that are far apart. My Kafka replication card links to a memory-profiling card, not because the topics are alike, but because tuning a consumer surfaced a memory leak, and experience made them neighbours. In embedding space "replication in a distributed queue" and "memory profiling in Python" sit a long way apart, and semantic search will not build that bridge. A hand-written wiki-link does, and now an agent reading about Kafka is one step away from memory profiling.

The mechanics are simple. Cards reference each other as [[flux-klein-9b-inference]], [[two-phase-commit]], [[saga-pattern]]. At build time a Python hook resolves each slug to a relative path. If a slug is not found, the log gets a warning, and in strict mode the build fails, so a broken link never reaches the live site. In April there were over 2,100 of these links. That is the whole knowledge graph: no embeddings, no vector database, no RAG. Markdown and grep. An agent opens the card on distributed transactions, sees the neighbouring topics under See Also, follows one and carries on. Three steps from the entry point to a working pattern.

It is the same idea as the [[filename]] links in my agents' memory, described in My CLAUDE.md is 582 lines.

The site is a build of the repository

Everything on happyin.space is a static site built from Markdown in an open repository. No database, no backend, no hidden layer. The file docs/kafka/broker-architecture.md becomes the page happyin.space/kafka/broker-architecture/ after a build, and that is the whole mechanism.

Which means anyone can fork it and run it locally in about five minutes:

git clone https://github.com/AnastasiyaW/knowledge-space.git
cd knowledge-space
pip install -r requirements.txt
mkdocs serve        # then open http://localhost:8000

That gives a local copy with every card, full search and the link graph. From there you can clear out my domains, add your own, and point your agents at the local build instead of the public site. That is how I use it myself: most of the time the local build is open, and the public site is a mirror.

A full rebuild took about five seconds, as fast on an old laptop as on a workstation, because underneath is the kind of static site generator the industry has been using for fifteen years. An agent working against a local copy spends no tokens on a network round trip or on waiting for a deploy: rebuild, open the card, take the recipe.

The same build step keeps the links honest. It walks every [[slug]], finds the matching card and writes the relative path, and if it finds nothing, the build fails. I see that locally before committing, and CI runs the same check in strict mode, where any broken link blocks the deploy. In April that meant more than 2,100 links and none of them broken. And because the site is the repository, everything is in git: you can see how a card changed, which facts arrived after which research run, and when it was last touched. For a base sorted by how fast its knowledge ages, that history matters.

How research gets in

The routine is set up so that I never move data by hand. I have several Claude accounts, each with several chats open, and in any of them a deep research run can start at some point: new models, optimisations, bugs, anything. Before, the result lived until the end of the chat. Now every one of those chats follows the same standing rule: when a research run finishes, drop a copy of the result in one central place.

That place is a Claude Code project bound to the knowledge-space repository, with its own research/inbox/ folder that collects raw dumps from every chat on every account. No copy and paste, just a rule each chat reads at the start and follows when its research finishes.

Then comes a second pass. A separate session over the knowledge-space project works through the inbox: it reads each raw dump, pulls out the concrete facts and gotchas, repacks them into the card format, and checks them against what already lives in that domain, so that duplicates enrich existing cards rather than multiply. Then it checks the wiki-links, runs the build, reads the diff and pushes. One such session usually yields 20 to 40 new or enriched cards over a few hours.

Model tiering falls out of this directly, and this is where I finally found a use for Sonnet. For me it had sat between "too clever for simple things" and "too simple for anything interesting". But "read a raw research dump, extract the facts, repack them into the card format, compare with the neighbours in the folder" is exactly its kind of work: mechanical, but with language in it. Sonnet repacks text as well as the larger model and costs noticeably less, so the research chats and the inbox pass both run on it. Checking the wiki-links, deciding whether two cards should merge, or resolving a conflict between two sources is understand-decide-design work, and that goes to the stronger model. The cost difference is a multiple, with no loss of quality.

The result is a flow. I do my main work, run research in different chats along the way, and the base fills up without me moving or formatting anything.

Using it and adding to it

The simplest way to use it is to point your agent at happyin.space/llms.txt and let it pull cards as it needs them. That alone cuts into the first third of tokens that used to go on orientation.

The next level is contributing. The repository has two files written for this: CONTRIBUTING.md, a general guide to preparing pages and sending changes, and AGENTS.md, instructions for your agent. They describe the card format, how dense the text should be, what belongs under Gotchas, how to write wiki-links and how to open a pull request with a new card or a correction. Give your agent the guide and a fresh research result, and it assembles the card itself. Your research enters the base, you stop paying for it again, and so does everyone else. The README states an MIT licence.

The more research is in the base, the less of it anyone has to redo. The more people and agents send cards, the more unexpected bridges appear between domains, and those are the valuable ones. The project page on this site is happyin.space.

What changed after April

Update, September 2026. The repository README now reports 1,287+ articles in 28 domains and 3,139+ cross-references. Most of the growth is two new kinds of page: projects/, 388 pages with one page per tool, model or product that a news pipeline follows, and organizations/, 45 pages with one per company or lab. The freshness rule is now a four-step cycle in the README: stable, yearly, every six months and monthly, with image generation and agent frameworks in the monthly group.

The April figures above (785 cards, 26 domains, 2,100+ links, the 60-day threshold, a five-second build) were true on the day of publication, and I have left them as they were. The same preference for plain files over a service, applied to several agent sessions working at once, is in Several Claudes on one repo.