Context is everything: High-quality knowledge work at speed with Claude Cowork & Obsidian
Applying Andrej Karpathy's context wiki in real life
Imagine you need to build a business case for a new product. The old way, you’d comb through Google and industry reports to size the market, analyse the opportunity and forecast the revenue. The new way, you hand the task to an LLM, run deep research, and get a solid draft back in minutes.
Solid, but not as sharp as if you’d done it yourself. So you iterate. And the reason it falls short is always the same: the model doesn’t know what you know. It hasn’t sat in your meetings, read your internal docs, or absorbed the dozen small decisions that shaped the project. You can keep refining the prompt, but there’s a ceiling to how much context you can type into a box.
Which raises the question: what if Claude or ChatGPT knew everything you knew, and took it all into account every time it answered?
That gap is what this piece is about. It’s the difference between working with a new hire who knows nothing on day one and one who’s already read every doc and sat in every meeting. The missing ingredient isn’t a smarter model, it’s your context, and the good news is you can hand it over.
Earlier this year, engineering legend Andrej Karpathy shared how he built a context wiki for his LLM. Rather than leaning on the model’s memory or retrieval-augmented generation (RAG), where the AI searches a source like a tool or the web and grabs snippets on the fly, his wiki is a set of local markdown files: quick for the model to pull into context, and just as readable for a human through a tool like Obsidian. The idea took the tech world by storm, and it’s since become central to how I work as an AI-first PM. Here’s what I’ve learnt so far.
Using the context
Let’s start with what the system can do. I’m a PM, so my examples are product ones, but this applies to anyone who does knowledge work: the principle is the same whether you’re writing PRDs or pitch decks, case notes or board updates.
A daily briefing built around me. Every morning opens with a scheduled briefing, and it’s nothing like a generic news digest. It leads with a motivational quote pitched at whatever I’ve been wrestling with lately, then a competitive and market-intelligence read tied to the specific initiatives I care about, the latest AI developments and tools worth folding into my workflows, and finally the critical items I need to be across that day. It’s the difference between “here’s the news” and “here’s your day”.
From discovery to draft in minutes. As a Principal PM, I lead with discovery: customer research and observations, voice-of-customer, market research. That feeds a point of view, then Product Requirements Documents (the brief engineering traditionally builds from) and HTML prototypes I share with internal teams and customers for feedback, before handing them to engineering to build. For you that might be a client proposal or a research brief. Instead of writing each document or building each prototype from scratch, I lean on the fact that Claude already knows everything I’ve captured in that initiative’s folder. I just ask it to fill in a template or build an HTML from what I’ve learnt. The drafts aren’t perfect and still need my revision and judgement (perhaps thankfully; “taste” is having a moment in tech right now), but starting from a rich draft beats starting from a blank page or a context-free prompt every time. Newer models like Fable 5 have pushed the quality up another notch.
Enriching the work with data. In a perfect world I’d have a clean, well-structured database Claude could query for any answer. We’re not quite there, and sometimes the only option is to navigate to a dashboard myself. Even then, context earns its keep: when I need a particular number, I ask, and Claude points me straight to the right dashboard. I follow its steps, screenshot the relevant tab, and feed that back for it to incorporate. From there it can go further, even building a financial model to help forecast the value of a given project.
Comms, decks and a live status hub. Because it can see my context, Claude also handles the connective tissue of the job: drafting Slack follow-ups to meetings and tagging the right people, building interactive HTMLs or presentations depending on what a stakeholder prefers, and summarising a project’s status for executives. To stay on top of everything, I built an HTML hub with tabs that gives me and my colleagues an at-a-glance view of my initiatives and links out to the underlying artifacts like my PRDs and prototypes. Claude refreshes it weekly and posts a progress summary to stakeholders on Slack.
Okay, so how do you get to this?
Generating the context
First things first. I have predominantly used Claude Cowork for this, but the approach should work with whatever LLM provider you prefer. Before Claude can be useful, you need to build the scaffolding: the folders and files that hold your context. The good news is that you don’t have to start from a blank page or organise any of it by hand. Your AI tool can do the heavy lifting at every step; you’re just directing it. No need to code, either.
I started with connectors. I plugged Claude into Slack, Outlook, Google Drive, our internal knowledge base, Zoom, Chrome, Figma, Databricks, Confluence, Jira, GitHub, and anything else I touch in a normal workday, so it could see my conversations and context rather than guess at them (read more about connectors here). Then I designated a single folder on my laptop as my Claude Code and Cowork home, told Claude about my key work initiatives, and asked it to pull from all those sources to set up and populate a folder structure:
A General Knowledge folder for context on the company, the industry, a glossary and similar reference files
A People folder that doubles as my personal CRM
A Meetings folder for every meeting and its transcript
A Templates folder showing how I like each type of document to look (a Product Requirements template, say), with a companion Examples folder holding a couple of filled-in examples to reference
An Initiatives folder with a subfolder per initiative, holding every document and artifact tied to that piece of work
The local markdown files in these folders have become my primary source of truth. Why local? It’s quicker and cheaper to access than reaching out to a tool or the web every time. Why markdown? Because it’s easy for a model to read and light on fluff, while still being perfectly legible to a human. Sitting above all of it, CLAUDE.md acts as persistent memory: the knowledge that cuts across every project and should always be in context, like key acronyms, references, my timezone, my main initiatives and areas of responsibility, and my goals.
From there I had Claude generate the starting documents. A vault index, so it (and I) can find things quickly. A markdown file per meeting. A person file for everyone I’d interacted with. A status file per initiative, so I can get an instant read on where each one stands, and a companion meetings file per initiative that pulls together the key points from every relevant conversation.
Data was the trickiest piece. Ideally, connectors (Databricks, Amplitude, Tableau and the like) feed the numbers straight in. Where that isn’t possible yet, I fall back to something cruder: I screenshot relevant dashboard tabs and get Claude to generate a detailed descriptive markdown file. The most critical component is a dashboards file that maps out where everything lives, so when I ask “where do I find this data?”, Claude points me to the right link, I grab the view it needs, and hand it back a fresh screenshot. Every time I come across a new dashboard, it goes into that overview.
I also pull in anything else worth keeping: notes from courses I’ve done, for instance, so Claude can apply that thinking directly to my work rather than me trying to remember every detail and reapply it myself.
All of this makes the context easy for the model to read. But I also wanted it to stay human-readable, so I installed Obsidian and pointed it at the exact same folder I use for Claude Code and Cowork. One vault, two audiences: me and the model.
Keeping it fresh
A one-time setup feels great for about a week. Then reality sets in: meetings pile up, projects move on, decisions get made in threads you never filed, and slowly your context drifts out of sync. Stale context isn’t just less useful, it’s actively misleading, because you keep trusting a second brain that’s quietly out of date. So the real work isn’t building the vault, it’s keeping it alive.
The principle underneath all of this is simple: for the AI to act as a true second brain, it has to be exposed to everything you know. If it doesn’t see the meeting, it doesn’t know the decision. So the first habit to build is capturing everything. I take detailed notes on every meeting and interaction I reasonably can, such as through Zoom’s meeting summaries.
Capturing is only half of it, though; the notes still need to land in the right place. Rather than filing by hand, I built a couple of skills to do it for me. (A skill is a small saved instruction I can trigger by name; you can read more here.)
The first is a process-meeting skill. I point it at a meeting summary and it does the rest: it saves the transcript as a new markdown file in my Meetings folder, updates the relevant people files in my personal CRM, refreshes the status file for any initiative the meeting touched, and even pulls in meeting-adjacent Slack messages so the record reflects the full picture, not just what was said out loud.
The second is a wrap-up-my-day skill. At the end of the day it reads back through my emails, messages and meeting notes, checks that everything has been processed and filed, updates the vault index so nothing gets lost, and pushes the whole vault to GitHub as a backup. It’s the daily sweep that stops small gaps from compounding into big ones.
Then there’s the material that doesn’t live on my laptop. Once a week, a scheduled task updates a local index of my Google Drive, so collaborative docs and presentations are searchable without me having to go hunting for them. The alternative, letting Claude run live semantic search (RAG) across my entire Drive on every request, would be slow, expensive and noisy; a lightweight index it can scan in seconds is far better.
The best part is that none of this runs on willpower. The skills fire on a schedule, so keeping the vault current isn’t a discipline I have to summon each day, it just happens in the background. Everything I learn, the AI learns, without me thinking about it. The second brain grows with the first.
Where it breaks down
None of this is perfect, and I’d be doing you a disservice to pretend otherwise.
The biggest risk is staleness. The whole system rests on the AI being exposed to everything I know, so the moment I stop feeding it (a week of unprocessed meetings, a project that quietly moves on without its status file catching up), the context starts lying to me by omission. Stale context is worse than no context, because you trust it. The fix is discipline, and the trick is to remove the discipline from the equation: the meeting and wrap-up skills run on a schedule so keeping the vault current isn’t something I have to actively remember to do.
Accuracy improves a lot with good context, but hallucinations don’t disappear. And the quality of the output is only ever as good as the quality of what goes in. If a meeting summary misattributes a decision or garbles a number, that error propagates into the people files, the status docs, everything downstream. Correct attribution in the source notes matters.
Collaboration is the piece I’m still working out. The markdown files live on my Mac, which is perfect for me and awkward the moment I want to share. If a colleague needs a doc I still end up putting it in Google Drive; HTML prototypes I publish via GitHub Pages. I’ve tried Confluence and haven’t found it friendly enough; a shared Obsidian vault is tempting but unproven for a team. The Drive index helps me scan what lives in the cloud, but “one source of truth that’s also easy to share” is still an open question.
And then there’s working on the go. Until recently I could only use Claude’s Dispatch with the laptop open, because the Claude chat apps don’t have access to this whole markdown system unless I park it in the cloud or in dedicated project files. GitHub, Obsidian’s sync, or Drive can bridge that gap, but none of it is seamless yet. Luckily there have been a few recent announcements (see below) that have begun tackling this challenge.
What’s next
There are a few things I’m watching and playing with.
The clearest near-term shift is devices. The single biggest limitation today is that all this lives on my laptop, and that’s changing fast: Cowork is coming to mobile and web, and ChatGPT Work is rolling out across devices. Once the markdown system is reachable from my phone, the ‘only when the laptop’s open’ constraint mostly dissolves.
There’s an ongoing debate about file formats. An Anthropic engineer recently shared that they’re moving from markdown to HTML, which may win out as models get faster and context windows get larger. For now I still find local markdown the most efficient option (no connector load times, minimal fluff), but I’m holding the choice loosely.
Conceptually, this is all part of a ladder the field keeps climbing: prompt engineering, then context engineering, and now what people are starting to call loop engineering. Fable 5, Anthropic’s latest frontier model, has given me a taste of where the quality is heading.
The thread running through all of it is portability. Because the context is just files I own, I’m never locked in. When the next model shows up (like GPT-5.6 just did, or whatever comes after), the second brain comes with me. That, more than any single feature, is why I think this is the right foundation for AI-native knowledge work.