How I built an AI that actually knows my work

TL;DR: My AI knows my work because everything it needs to know lives in plain files on my computer: memory files it reads at the start of every session, an Obsidian vault holding my accumulated knowledge – years of science writing and technical marketing turned into notes, workflows, playbooks, and skills – and Claude Code working directly in those folders. Add one rule at the end – nothing ships until I’ve read it and asked, would I say this? – and that’s the whole system: an LLM wiki. I’m Julie Kaiser, a science writer, not a coder, and mine grew out of a failed automation in December 2025, one piece at a time. This page is the map.

The problem this solves

Every AI conversation starts with a stranger. You re-explain who you are, what the project is, how you like things done, and by the time it’s useful, the session ends and tomorrow you do it again.

The re-explaining is annoying. The real cost is worse: whatever you figured out yesterday is trapped in yesterday’s chat. The quality of AI help tracks the context it can see, and a fresh chat window sees nothing.

You might think the fix is a bigger model, or a longer context window – dump in all your files and let the AI read everything. It isn’t. A smarter stranger is still a stranger, and context doesn’t accumulate on its own.

How do you give an AI context about your work in a way that accumulates instead of evaporating? This is the system I built in Claude Code, and this page is the whole of it.

The December flop that started it

In December 2025 I thought I’d start learning to build AI agents. I built an automation to read a pile of documents I’d scanned and auto-rename them by date, source, and type, so they’d be filed and usable in our household. I followed online instructions from different people. I installed Docker. I set up an n8n-style automation.

It was a slog. Days of work, and the thing kept inventing wrong dates and useless file names. It would have been faster to rename a thousand files by hand. I gave up, moved to Make, and then abandoned that too.

The interesting part: I did the responsible thing. I followed the guides. I’m a relatively clever person. And the guides led me to days of failure on a task a human could do with a cup of coffee while listening to a podcast.

What changed: I got brave enough to try Claude Code

The thing that beat me for days back then takes minutes now. Same me, same documents, same computer. Claude Code reads the files, works out the dates and sources, renames the lot, and shows me what it did. And when it gets something wrong, I tell it in plain English – that’s not right, here’s how it should be – and it fixes it.

Here’s why that matters to me. Back then, I felt so far behind. I felt like if I didn’t learn to build AI agents, I’d fall behind everybody else. But being behind isn’t permanent in the AI space – at least not yet – because the tools evolve so fast they catch up to meet you. If you tried something six months ago and it was miserable, there’s a good chance it’s trivial now. Worth trying again.

That’s what agentic AI changed: tools you talk to in plain language, working in your actual files and folders. And that’s the basis of the system I built.

What I built: three layers and a rule

• Memory files that tell Claude who I am, what I’m working on, and what matters to me – everything it needs to know about my work.
• A tool – Claude Code – that reads and writes the real files on my computer.
• A knowledge vault in Obsidian, where years of notes live.
• An editorial gate at the end, where I decide what ships and what doesn’t.

That last one matters, because I’m not making automated, faceless content churned out without due diligence. The point of the whole system: it works with my files and my knowledge, and helps me do the tasks I’d otherwise grind through alone – better and faster – with me still deeply embedded in every step.

The layers hand off to each other, and the handoffs are the system. The memory files make every session start warm – it “knows” me. The session works inside the vault, so years of context are already on the table. Whatever the session produces that’s worth keeping gets saved back into the vault, along with a note that it happened, which makes the next session smarter than this one. When things go wrong, those lessons get saved back too. And before anything leaves the house: a quality-control check by me. A discerning one.

None of it is locked to any product, either. It’s files on my computer, and I can open them with Claude Code, Codex, or whatever agentic tool comes next. If a better one ships next week, I point it at the same folders and get back to work. It’s the same system I’ve set up for a client project, too – and building yours with you is what Work with me is for.

The memory layer: how I make Claude remember my work

Claude remembers my work because I keep a folder of plain text files it reads at the start of every session: who I am, what I’m working on, how I like things done – and more. There’s more context in those folders than it could ever load at once, and that’s the trick: it reads what it needs. Enough to know who I am; then I tell it what I’m working on, and it goes and gets what that job requires. It ends up holding exactly the context it needs to get to work – and what it reads is the latest, canonical version of each file. One source of truth.

Mine started as a handful of files and grew one piece at a time, each addition solving a problem I’d actually hit and worked through. The exact approach, including how to start yours in half an hour, is in How to give Claude lasting memory of your work – and the starter memory file is a free download.

The tool layer: why Claude Code

My reasons are honest ones. Everybody was hyping Claude’s writing ability, and I’m a writer. Claude Code can do more than the other versions of Claude. And the instructions I was following to build this system were written for Claude Code.

I’m not a coder, and there’s no coding in the way I use it. The terminal is the price of admission – but you don’t actually have to pay it: Claude Code runs inside the Claude desktop app, in an interface that looks like any other AI chat. And when the terminal is genuinely needed – giving Claude access to an API key happens there, for example; a post on that is coming – Claude tells you exactly how to open it, what to type, and what to do.

I started in Claude Cowork and hit its ceiling; the honest comparison, including who should stay in Cowork, is in I tried Claude Cowork, switched to Claude Code.

The knowledge layer: Obsidian and plain files

“The vault” is where the accumulating happens. Three years of notes undersells it: it holds everything I’ve learned across years of science writing and technical marketing work, transformed into notes, workflows, playbooks, and skills that Claude Code can work in and use.

Mechanically, the vault is a folder on my computer. Obsidian is the program I view it through – markdown files I can read and edit, and Claude can read and edit them too, directly, because a vault is a folder, not a database. I can open the same folder in Finder and see the files for myself. Voice memos, web pages, half-formed ideas – things go in, get filed, processed, and connected to what’s already there, waiting for me to describe them badly in a voice memo and pull them back out for the project I’m ready to work on. I can reach everything through the AI, search it in Obsidian, or look at the files directly. Nothing is trapped in any app.

The daily texture of it, capture to retrieval to writing, is in AI in Obsidian: how I actually use it – and the story of how the vault got built, wrong turns included, is in How my AI wiki actually got built.

The day it looked broken (and wasn’t)

A few days into operating my wiki, I started working in it and the answers came back as if the previous day’s work hadn’t happened. Everything we’d worked on seemed to be gone. My first thought: I broke my wiki. I’m going to have to rebuild this whole thing again from scratch.

But that’s not what happened. Claude Code maintains the wiki – and Claude Code fixed the wiki, in about half an hour.

I told Claude the wiki wasn’t working right and seemed to have forgotten everything we’d done. I did tell it I wondered whether my running parallel sessions had something to do with it. So Claude looked into it for me: it found my old conversations, worked out the last point where everything had been fine – a few days back – extracted what we’d done since, logged it properly, and repaired the files. Did some things, saved some things, asked me a few things. Half an hour, fixed. Then it told me not to run multiple sessions at the same time. Which was fine for a while – but that’s another story.

The reason I’m telling you this: it’s files. You think you’ve broken something, but they’re files, they’re backed up, they’re there. A system made of files can seemingly break and still be perfectly fine, because files can be looked at, compared, and reverted – and the log of what happened can be rebuilt from the chat history.

I was devastated. I thought I’d broken my new “toy” – but it cost half an hour, and everything was fine. That’s the kind of thing to expect if you sign up for an LLM wiki like this. This isn’t software a product team has hammered out and fine-tuned. It’s an AI model operating on a few simple rules, changing them as your needs change, adapting to what you need it to do. And you’re not an expert – you’re still learning. And that’s okay.

The editorial gate: nothing ships unread

The last piece isn’t code. It’s a rule: nothing I’ve made with AI ships until I’ve read it and asked, would I say this?

The rule matters more, not less, because of how much this system can do on its own. There are automations in here. My setup connects to my blog; it can update posts; it could, in principle, draft and publish end to end. That’s exactly why there are multiple checkpoints where content has to pass me before it leaves the house.

Anything AI has touched ships under one stringent rule: it has to be mine. Either I know the subject well enough to vouch for every claim myself – I’m the expert – or I’ve done the research and backed up every claim the AI had a hand in, until I can give it the same guarantee: enough me that I can put my name on it. I refuse to put slop out under my name, and I am not shipping something an AI generated on its own.

Client work runs tighter still. I treat this blog differently than the regulated biotech and pharma writing I do for clients – that work is more hands-on, less AI-drafted, and more rigorously checked at every step. How these blog posts get made is its own story, and catching AI when it invents things is its own post.

Where this is going

My LLM wiki operating system isn’t finished, and I don’t ever expect it to be. It grows the way it started: one piece at a time, each solving a problem I’ve actually hit and want to avoid the next time around.

The working philosophy is simple. I look at my goals, find the friction and the bottlenecks between me and them, and ask how the wiki can reduce them. One day that’s automating a piece of one workflow, another day it’s something else entirely. I focus on one thing for a couple of days and get it working – not perfect, working. Reduce the friction, move forward, improve it later.

And the biggest revelation of having an LLM wiki caught me off guard. Yes, it makes my work faster. It also makes you feel permanently on the verge of being able to do so much more, so much faster – so you take on the crazy idea, because you believe you can pull it off. It lets you work faster. It lets you do more. And it makes you take on more. But I wouldn’t have it any other way.

So here’s my piece of advice: an LLM wiki isn’t a terrifying thing. If I can do it, you can do it. Start tiny: one folder, one file, one session where the AI reads it first. The downloads shelf has the whole starter kit, free, no email gate: a first memory file, the wiki kickstarter, how to use your wiki every day, the technical lessons, and the prompts I actually use.