My AI workspace: one vault, three agents, and a wiki that learns

For a long time my projects lived everywhere. Notes in one app, scripts in random repos, and most of the context only in my head. Every new chat with an AI assistant started from zero, and I explained the same things again and again: where the server is, how we deploy, what I already tried last week. At some point it became obvious that the problem is not the model, it is the memory around it.

So I built one workspace for everything, and this post is about how it works, which ideas I borrowed, and what it looks like on real tasks.

One folder, opened by humans and agents

The base is boring on purpose: a plain folder that is a git repo and an Obsidian vault at the same time. I read and navigate it in Obsidian, with all the backlinks and graph view, and agents work in the same files from the terminal. Every project gets its own folder with three parts: raw/ for sources, wiki/ for knowledge, and repo/ which is just a symlink to the real code repository. There are also shared folders for global knowledge, skills, coding rules and a couple of scripts.

I use three agents every week: Claude Code, Codex and Kilo Code. Each of them is good at different things, and I switch between them depending on the task and on limits. This is exactly why the next idea mattered so much.

One instruction file for all agents

Each agent wants its own config file, and keeping three copies in sync is a guaranteed way to have three different truths. Luckily there is now a shared convention, AGENTS.md, which most coding agents read. So the workspace has one AGENTS.md with all the rules: layout, conventions, what to do at session start and end. CLAUDE.md contains only an import of it.

The same trick works for skills. Reusable workflows are written in the Agent Skills format, a folder with a SKILL.md inside, and they live in one place. Claude’s skills folder is just a symlink to it, so a skill like “create a new project” or “ingest new sources” works the same in every agent. My personal coding rules (keep diffs small, no overengineering, short docs) also live in one folder, and the instruction file says which rule applies to which file pattern.

For tools I use MCP servers, and here again there is one source of truth: a single .mcp.json. A small script generates the configs for Codex and Kilo from it, and nobody edits those generated files by hand. Result: I can start a task in one agent, continue it in another, and both know the same rules and have the same tools.

A wiki instead of chat history

The most important idea came from Andrej Karpathy’s LLM Wiki note. The point is simple: humans bring raw sources and ask questions, and the model writes and maintains a wiki from them. You don’t query a pile of documents every time, you query knowledge that was already compiled.

In my setup raw/ is immutable. Exports, PDFs, transcripts, emails go there and are never edited. wiki/ belongs to the agent: it creates pages, splits them, merges duplicates and rewrites them when something changes. Two small files make it work in practice. index.md lists every page with a one-line summary, so the agent reads the index first and opens only the pages it needs, which is much cheaper on context than reading everything. log.md is append-only and records what was ingested, asked or fixed and when. And there is a rule I like a lot: good answers become pages. If I ask something and the answer will be useful later, it goes into the wiki instead of dying in a chat window.

Next to it every wiki has a glossary, a small table with term, short name and meaning. It sounds like bureaucracy, but it removes a lot of friction. When I type “CF” or “YD” the agent expands it from the glossary, and when the same term starts to appear in two projects it moves to the global glossary.

A loop that learns

A wiki keeps facts, but I also wanted the setup to remember mistakes. So every session ends with a reflect skill. The agent goes over what happened, updates the project wiki, tool notes and glossaries, and writes general lessons to a LEARNINGS.md file which is loaded into every new session. Once a week a retro skill cleans this file, merges duplicates, deletes rules that turned out wrong, and turns repeated workflows into new skills.

Some lessons that are now permanent: old Intel binaries in /usr/local/bin silently break things on an Apple Silicon Mac, so use the Homebrew ones; GitHub’s OIDC trust for AWS can require the immutable sub format for some repos, not the simple repo:owner/name; and when you patch files on remote servers with a script, keep a backup copy and count the matches after the edit. Each of these cost an hour once. Now they cost nothing, for every agent.

To keep the wiki healthy, a SessionStart hook runs a small lint script before I even say hello: broken links, orphan pages, missing index entries, raw files nobody has ingested yet. The agent sees this report and can offer to fix it.

Guardrails before power

Giving agents access to servers, DNS and cloud accounts is useful and also a bit scary. So the rules are explicit. Read-only commands are allowed without asking, anything that changes state needs confirmation, and destructive actions (deleting, publishing, DNS changes) always need a clear yes from me. Secrets never go into notes, they stay in the keychain or ignored .env files. Projects with personal data are excluded from git. Even small preferences are stored as memory, for example that commits should not have AI co-author lines, or that answers should be short, without lectures.

Use case: this blog in one evening

This blog was a 2023 Hugo site with an outdated theme and a manual deploy script. In one long session with the agent we moved the repo to GitHub and set up deploy on push with GitHub Actions and AWS OIDC, so there are no long-lived keys anywhere. Then we upgraded Hugo, switched to the Roadster theme, made the site bilingual and translated all posts to Russian.

After that came the part that is easy to postpone forever: canonical links, hreflang, structured data, a robots.txt that explicitly allows AI crawlers, and an llms.txt file so agents can read the site without parsing HTML. Analytics went in behind a consent banner, the domain was verified in Search Console with a DNS record, and the first ad campaign was prepared. Every decision and every gotcha went into the project wiki on the way, so the next session starts with full context instead of archaeology.

Use case: offsite backups for servers

For a small infrastructure I needed backups that don’t live with the same provider as the servers. The agent wrote the backup scripts and rolled them out over SSH to several hosts. One rollout went wrong in a very instructive way: a copy step failed silently, and the idempotency check was looking for the wrong text, so the same snippet was inserted three times into a config. We cleaned it up, and the lesson went straight into LEARNINGS.md: keep errors visible on copy steps, make the guard match exactly what you insert, count matches after, keep a backup. The next rollout was clean, and no agent will repeat this mistake in my workspace again.

Use case: yearly paperwork

The least exciting one is maybe the most useful. Every year I have tax declarations to prepare in more than one country, and each of them is a separate project with its own wiki. Bank statements, payslips and official forms go to raw/, and the agent turns them into pages with numbers, deadlines and links to the source documents. Personal data that several projects need, like family details and ID numbers, sits in one page that the others link to, and the whole thing is excluded from git.

There was also a small technical surprise here. Text extracted from government PDF forms often comes out with every digit separated by spaces, which makes amounts unreadable. The fix is to render the pages to images and let the model read them as images. Now this is a learning too, and next year it will just work.

What I would take from this

You don’t need my exact setup. If I had to start again, I would begin with one folder and one instruction file, keep raw sources apart from generated knowledge, make the agent write down its lessons and load them every time, and add guardrails before adding more access. The tools will change every few months, but these habits survive.

It is still a work in progress, and I keep changing it almost every week. If you have your own way to fight the “every chat starts from zero” problem, I’m really curious to hear it. Drop a comment below.