How to Build a Personal Context Layer with Claude, Codex, and Obsidian

Most people still use AI like a chat utility. They open a window, paste some material, get an answer back, and move on.

That works for one-off tasks. It is thin support for work that needs to stay organized, reviewed later, or handed back to the same model a week from now.

A more durable pattern is to keep the working context in a folder you own: notes, briefs, transcripts, source files, drafts, templates, and outputs, with an agent working on top of that structure. This is close to what Simon Willison calls context engineering: the useful work is not only prompt wording, but assembling the right instructions, state, tools, and history around the model.

Treat the file system as the source of truth

Each client, project, workstream, or research area gets its own folder. The folder becomes the workspace. The chat thread becomes one interface into it, not the place where the work lives.

When the files live locally, you keep ownership of the material and the structure around it. You can inspect the source notes, rename them, version them, archive them, or hand them to a different model without rebuilding the context from scratch.

This is where the current tool stack is already pointing. OpenAI documents Codex and project instruction files for local work, while Anthropic documents user and project settings, hooks, subagents, and MCP as the way Claude Code carries local rules and tool access into work. Obsidian fits the same pattern because it works on normal Markdown files and folders instead of a proprietary backend.

Keep the architecture simple

Start with one parent context folder and a small set of child folders underneath it. The parent layer handles cross-cutting work. The child folders handle domain-specific work.

Each child folder should have its own local contract. In Codex that is usually AGENTS.md. In Claude Code the same role can be split across project settings, hooks, subagents, and connected tools. The important part is not the file name. The important part is that each folder carries its own rules, summaries, and conventions with it.

The parent layer should stay narrow. It can roll up weekly status, compile monthly summaries, surface open actions, keep naming rules consistent, and route new material into the right child folder. It should not try to own every local decision inside every project.

Make Markdown the working format

For most intermediate work, Markdown is the best default. It is readable in any editor, easy to diff, easy to search, and easy for agents to rewrite safely.

That makes it a good home for meeting notes, daily briefs, research summaries, action logs, working outlines, dashboards, and recurring reports. A lot of knowledge work does not need to start in Word or PowerPoint. It can stay in Markdown until there is a real delivery reason to export it.

Obsidian is useful here because it can work directly on an existing folder of notes, stores notes as normal files, supports internal links with automatic link updates on rename, and uses properties in frontmatter when you need light structure. That is enough to give the folder a usable interface without making Obsidian the system of record.

Eric J. Ma has written about arriving at a similar place from the knowledge-management side: once the notes are already plain text and local, agent workflows stop feeling bolted on and start feeling native to the material itself.

Use the contract for operations, not philosophy

A project contract should be operational. It should tell the agent what the folder is for and how to behave inside it.

A simple child folder can stay plain.

Once that scaffold exists, the agent can do real maintenance work inside the folder: rename files, summarize calls, extract actions, update dashboards, and draft deliverables against the right template.

Design intake before you design automation

A context layer goes stale when new material enters too slowly or lands in the wrong place.

There are three reliable intake paths.

The important part is that new inputs do not stay marooned in chat or inboxes. They need to land in the project folder, get renamed, get summarized, and show up in the notes and rollups that people actually use.

A practical starting workflow

What to avoid

The goal is not to build an elaborate second brain. The goal is to keep active work in a structure that both you and the agent can read, maintain, and reuse.

Sources