I Built SelfContext So I Could Stop Re-explaining Myself to AI

A developer built SelfContext, a local context layer for AI tools, to stop re-explaining personal history, goals, and preferences in every new AI conversation. The project stores context as ordinary Markdown files and uses skills to help an existing agent ingest, retrieve, and reason from that context, ensuring users own their data. SelfContext is designed to be harness-agnostic and compatible with Obsidian, avoiding lock-in to any single AI interface.

In my last article https://dev.to/joacod/ai-gets-more-useful-when-you-build-the-workflow-around-it-mfl , I mentioned SelfContext https://github.com/joacod/self-context as a brainstorming partner. That was the short version. This is the longer one. I built it because I was tired of starting every useful AI conversation from zero. I already had history, goals, preferences, decisions, and a list of ideas I had already rejected. Every new session still asked me to explain myself again, as if none of that existed. Provider memory did not solve it. Chat history did not solve it. A folder of notes did not solve it either. The tools were happy to remember a random detail with great confidence and forget the decision I actually needed. The useful context stayed scattered, hard to inspect, and stuck to whichever tool happened to remember it this week. I wanted context I own . SelfContext is a local context layer for the AI tool I already use. It is not a chatbot, not another harness, and not a hosted memory product. It is a vault of ordinary Markdown files, plus skills that tell an existing agent how to ingest that context, retrieve it, reason from it, and keep it from rotting. The tagline is the whole product: think with context you own. The technical thesis is simpler than the architecture docs make it sound. Context has a lifecycle. A conversation is temporary. Reasoning is not automatically memory. Only the pieces that will make a future conversation better should survive. I already made a version of this argument for engineering work in Context Is Not Memory, It Needs an Engine https://dev.to/joacod/context-is-not-memory-it-needs-an-engine-f2 . SelfContext is the personal version of that idea, kept small on purpose. Andrej Karpathy's LLM wiki https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f is the pattern underneath this. Raw sources go in. The model compiles an interlinked markdown wiki. You browse it, ask questions against it, and occasionally lint it. The wiki is supposed to compound instead of making the model rediscover the same synthesis on every question. I took that pattern and pointed it at personal context. That change is not cosmetic. A research wiki can be a little generous. If a paper is summarized too eagerly, you can correct it later. A personal vault cannot treat every inference as a fact about you. If the model decides you prefer something because it suggested it and you did not object, that is how you end up with a confident fiction of yourself. So SelfContext keeps the categories visible: Inferences stay reviewable. Advice does not quietly rewrite goals. A brainstorm can be useful and still disappear when the session ends. The model still does the bookkeeping. I still own the meaning. The vault lives on disk. Git ignores it. There is no SelfContext server, database, embeddings layer, MCP product, or custom chat UI. The execution layer is whichever compatible harness I open the repository in. OpenCode, Claude Code, Codex, Pi, something else next month. The model can change. The files stay. That is the part I care about. I do not want to rebuild a second brain every time the industry picks a new favorite interface. Local does not mean invisible to a provider. If I open the vault in a cloud-backed agent, that agent can see what I give it. Git ignore is a commit-safety boundary, not a magic privacy shield. The useful guarantee is more modest: the durable context is ordinary files I can copy, inspect, edit, back up, or delete without asking a product for permission. The vault is compatible with Obsidian https://obsidian.md/ because the files are just Markdown, YAML frontmatter, and standard relative links. That is intentional. I did not make Obsidian syntax canonical. Wikilinks would have been convenient, and also a quiet lock-in. Graph view is nice. It is not the source of truth. If the skill, the harness, and Obsidian all disappeared tomorrow, a copied vault/ folder should still be readable. Viewer state under .obsidian/ is ignored on purpose. It is not personal context. I like tools that can look at the same files without becoming the format. The daily use is not filing. It is thinking. Before I implement something, I often ask SelfContext to challenge the idea from context I have already chosen to keep. Preferred technologies for an MVP. How I usually think about product and UX. Tradeoffs I accept. What I am trying to learn. Which ideas I have already rejected. It also works for narrower questions. How to position myself for a role. Whether a project still matches my goals. What I actually learned versus what I only consumed. Whether a piece of writing still sounds like me. The useful part is not that it "knows me". It gives the conversation a better starting point. That is also why I did not try to make it a complete second brain. Completeness is how these systems become junk drawers. A larger vault is not, by itself, a better one. When it works, it feels less like a product with memory and more like past me tapping me on the shoulder. Hey, we already tried that stack for an MVP. Hey, we rejected this kind of scope. Hey, this fights a constraint we already wrote down. A little rude, but usually right, stupid past-self. Normal use needs no server and no dependency installation. git clone https://github.com/joacod/self-context.git cd self-context Open the repository root in an AI tool that loads project-local Agent Skills, then talk in ordinary language. Three requests do most of the work. Ingest is for when I know exactly what to save: a resume, a decision, a correction, a document, a fact I do not want to reconstruct later. Query is for retrieval and thinking. What does my context say about this? Help me think it through. Compare these options against my current goals. Challenge this idea based on what you already have. Query is read-only by default. A useful conversation does not have to mutate anything. Checkpoint is for the end of a meaningful discussion, when something might be worth keeping and I want the system to decide. It is not "save this chat". It inspects the conversation, keeps the smallest durable outcome, and may correctly keep nothing. That last part is the product. A memory feature that stores everything is just a slower way to pollute the next session. I already have chat history for that, and it is not a second brain. It is a transcript with amnesia. If I pull a newer version of the project, I ask it to upgrade vault latest . The operational instructions can move. The vault stays mine. From the outside it looks like chatting with files. Underneath there are four layers: php existing AI harness + model - SelfContext skills - deterministic vault mechanics - local Markdown vault The harness and model do the reasoning. The skills decide what the request means: ingest, query, checkpoint, review, or advice. Small Python helpers do the boring parts: bounded retrieval, validation, index sync, backups, filesystem transactions. They do not get to decide who I am. A query does not dump the whole vault into the prompt. It prepares a bounded packet, reads the relevant pages, and answers from those. A write goes through a commit boundary: stage, validate, backup, then apply. If something looks contradictory or inferred, it stays visible instead of being flattened into a personality profile. There are optional areas for career, learning, writing, relationships, media, and projects. They are not separate products. They share the same lifecycle. If a domain has no durable context yet, it does not get a folder just to look complete. I also kept a hard split between using the vault and maintaining the project. Asking for career advice should not turn into an architecture review of SelfContext itself. That sounds obvious until you watch an agent treat every conversation as a chance to "improve the system". I do not need a second brain. I need a way to continue a line of thought without renting the history from whichever model is fashionable this month. SelfContext is small because the important part is not the runtime. The important part is a context store I can inspect, correct, and carry across tools. The vault is the asset. Everything else is replaceable.