A Complete Starter Guide to Setting up Your Context OS
And why it matters.
Over the past few months I’ve built several client implementations, presented to two separate groups of GTM professionals, shipped dozens of iterations and ran hundreds and hundreds of tests on all things context engineering.
Today I’m sharing the starter guide to how to conceptualize, deploy and actually get value out of the confusing web of hype that is Claude Code (what is that?), context engineering (ok why do you need to engineer context) and OpenClaw (a lobster?) -- btw I don’t do anything with Clawdbot, not my thing, but the principles should still help.
What is a Context OS?
A context OS is an AI-driven knowledge base that centralizes all your scattered context (sales transcripts, CRM data, process docs) into a unified company brain that’s both human readable (plain English) and optimized for agents.
Why Should I Care?
Close up day to day: you want to be faster at shipping tests, building product, fulfilling services right? Good. At its simplest a context OS lets you ship, learn faster, and compound those learnings. The whole feedback loop.
It does this without regard for the domain (Lawyers are using Claude Code for their problems), but today we are focused on software via agentic development and Go to Market.
Your context OS makes it easier to ship and learn drastically faster by replacing endless context switching, and having to explain yourself over and over, with compounding intelligence - once you solve a problem inside your context OS you can save it and scale it up later.
The more you use your context OS the smarter it gets, over time becoming a living source of truth for all your work and a competitive edge.
Stepping back: we are in the middle of the technological wave of our time and the “how does this all work and why does it fit together” is still very much up for grabs. I want the context OS version since I believe it amplifies human intuition, expertise and taste and I believe in a world where technology frees each of us to embrace our humanity.
Why Claude Code?
Claude Code is different than your regular ChatGPT or Claude app since it’s local to your computer. It can read and write files, and run commands. It has the simplicity of a purposefully constrained toolset that creates emergent dynamics. It can take its limited tools and string them together to get greater than the sum of its parts outcomes.
It could be any agent CLI tool that reads and writes to your local files and runs commands. This is important because it allows the model to push information in and out of its context window and take actions on your behalf.
Custom GPTs and Claude Projects are a box someone else designed. A context OS is YOUR file system, YOUR structure, YOUR rules. The AI conforms to your world, not the other way around. Custom GPTs lose context between sessions, can’t search across documents, can’t create persistent artifacts, and can’t be version-controlled or shared. A context OS does all of these.
How to Know if this is For you?
Take this article itself and this quickstart guide and feed it to your preferred AI that knows about what you do. Have it evaluate it and give you honest feedback on the value to cost to setup and your level of technical proficiency.
Context OS Architecture
Every app you use (Slack, HubSpot, Notion, Salesforce) is just reading and writing files. They hide the file system from you behind a UI. That made sense when humans were doing the work. Now AI is doing the work, and all that complexity in between you and the base computer is getting in the way.
HOW APPS WORK HOW CONTEXT OS WORKS
You You
| |
v v
[ App UI ] Plain English
[ API ] files (.md)
[ Database] |
| v
v AI Agent
Files (reads + writes
(hidden) directly) A context OS strips out the middle layers. Your knowledge lives in plain English files that both you and AI can read, write, search, and build on.
How to Setup & How it Works:
The Two Layers
Your system has two layers. Think RAM vs hard drive.
Operational docs are your RAM. The ICP brief, the objection doc, the messaging framework. Stuff you work from every day. These live in 00_foundation/.
Atomic knowledge base is your hard drive. Individual concepts, validated patterns, evidence from transcripts. You don’t access it daily, but it’s there when you need to look something up. This lives in knowledge_base/.
Operational docs reference the knowledge base but don’t redefine it. Your ICP brief references the concept of “buyer pain points.” It doesn’t re-explain what buyer pain points are. That lives in the knowledge base as its own node.
The Two Layers + The Graph
These aren’t just two folders. They’re layers in a compression chain, and within each layer, nodes link sideways to form a knowledge graph.
LAYER 2: OPERATIONAL DOCS (your RAM)
+-----------+-----------+-----------+
| ICP Brief | Messaging | Objection |
| refs: | refs: | refs: |
| [[pain]] | [[pain]] | [[trust]] |
| [[icp]] | [[value]] | [[pain]] |
+-----+-----+-----+-----+-----+----+
| | |
+-----------+-----------+ <-- references flow down
| | |
+-----+-----+----+------+----+-----+
| Pain | ICP | Trust |
| Points | Segments | Erosion |
| | | |
| [[trust]]--+-----------+->[[trust]] <-- wiki-links
| [[icp]]----+->[[icp]] | | connect sideways
+------+-----+-----+-----+----+-----+
| | |
LAYER 1: KNOWLEDGE BASE (your hard drive)
| | |
......v...........v..........v.......
: transcripts, emails, raw docs :
: (the evidence everything :
: traces back to) :
:...................................: Each layer compresses the one below it. Your positioning doc doesn’t re-read 200 transcripts. It synthesizes the patterns layer. The wiki-links ([[concept-name]]) between nodes are what turn flat files into a graph the AI can navigate.
This is why 95% of your queries can be answered by reading just 5% of your content: synthesis docs at the top of each domain.
Three Files That Govern Everything
CLAUDE.md is your system’s constitution. It’s the first thing the AI reads every session. Where everything is, how things relate, what the naming conventions are. If you had to drop someone into your business with zero context and tell them to go do a task, what would you give them? That’s your CLAUDE.md.
taxonomy.yaml defines your blessed tags: what categories exist, what domains you track. Start with 10-15 tags. Add new ones only when 3+ documents show the need.
ontology.yaml defines how concepts relate to each other: what relationship types exist, what linking rules apply. This is the rule set that keeps your knowledge graph navigable as it grows.
A side note: I am actively iteration on a new version of Context OS, it will automate much of the maintenance overhead these files create.
What You Need
A Claude account (Pro at $20/month minimum)
An editor: VS Code, Cursor, or the terminal
A GitHub account (free)
Clone the Quickstart
git clone https://github.com/jacob-dietle/gtm-context-os-quickstart.git
cd gtm-context-os-quickstartOpen it in your editor, then run /quickstart. In about 10 minutes you’ll have a working directory structure, a CLAUDE.md navigation guide, taxonomy and ontology files, and your first processed content.
Ingest Your First Content
Start with 15 transcripts. 5 is too thin for patterns to emerge. 500 is too much to process without structure first. 15 is the sweet spot where the system starts seeing patterns across conversations.
Drop them into a directory and tell the system to ingest. Joel set his up live during a workshop. It took him longer to install VS Code and connect Claude Code than to build the actual system. He dumped screenshots, PDFs, slide decks, web copy, and sales call analyses into a directory, told it to ingest, and went and did other stuff while it processed.
Your First Prompt
After ingesting, ask: “What meaningful information can be extracted from these calls?”
If results are weak, get more specific:
“What are the top 3 objections prospects raised?”
“What patterns do you see in how prospects describe their current pain?”
“Create a 1-page ICP brief with demographics, pain points, and buying triggers”
Your First Artifacts
From those 15 transcripts, you should get:
An ICP brief
Top objections with best responses
A “what we do” narrative reusable in docs and onboarding
Prompts for anyone on your team to “ask the company brain”
Push to GitHub
Once you’re happy with the initial state, push it to GitHub. This is your undo button. Save Version A, make changes, roll back if you don’t like them. For teams, GitHub is how your system owner reviews and approves changes through pull requests.
How to Use
Once the quickstart scaffolds your system and you’ve ingested your first batch of transcripts, here’s what the actual day-to-day looks like.
Ingesting New Context
Anytime you get new transcripts, documents, or raw context, drop them into a directory and run /ingest. The system reviews the new material against your existing taxonomy and ontology, then appends to the knowledge graph using that rule set. It doesn’t start from scratch each time. Because there’s already a structure in place, new context gets wired into what you’ve already built.
This is where the compounding happens. Each piece of context makes every other piece more valuable because they’re linked and queryable together. You asked about launch blockers three weeks ago. New transcript comes in mentioning a fence integrity issue. The system connects that to the existing risk nodes and surfaces it.
Querying Your Knowledge
Once you have context in the system, you just ask questions in plain English. “What are our biggest blockers?” “How does this new transcript relate to existing risks?” “Create a 1-page summary of what customers care about most.”
The system searches across your knowledge graph, follows the links between nodes, and synthesizes an answer grounded in your actual data. Every claim traces back to a source file. You can click through from insight to source document to original quote.
For more targeted searches, start narrow: keyword search across your files (seconds), sample a few results, then let the AI add meaning across them. Start precise, then widen.
Skills: Teaching the System to Repeat What You’ve Done
Skills are markdown files that encode a specific workflow. You solve a problem once (how to write copy in your brand voice, how to analyze a competitor, how to prep for a 1:1) and save it as a skill. Now the system knows how to do it every time.
The AI loads the skill summary first, and only pulls in the deeper reference material when it needs it. This keeps the context window efficient instead of loading everything at once.
Pushing to GitHub
When you’re happy with changes, Claude Code can manage the Git commands for you. It stages your changes, writes a commit message, and pushes to your remote repository. If you’ve never used Git before, you can literally have the AI teach you and run the commands on your behalf.
This is your version control. Save a snapshot, make changes, roll back if you don’t like them. For teams, this is also your collaboration layer: pull requests, reviews, approvals.
Known Limitations:
Context Windows Are Finite
You only have so much space. If you load every document at once, the AI has less room to actually work, and what it does produce gets worse. This is why front matter, synthesis docs, and skills exist. They’re all strategies for managing a finite budget of attention.
On the $20/month plan, you’ll hit rate limits during heavy building sessions. That’s normal. It just means Claude did a lot of work for you. Warn your team up front so nobody panics.
The Bottleneck Is Grounding, Not Data
The bottleneck is whether your claims connect to evidence, not how much data you have. Having 3,000 transcripts means nothing if your positioning doc was never validated against the patterns your system extracted. Before ingesting more raw material, make sure what you already have is properly linked and cited.
Maintenance Is Real
Systems that don’t get tended go stale. Your context OS still has the same ICP brief from 6 months ago when your whole motion changed. The system looks full but the content is dead weight. That’s fossilization.
The good news: even when things go stale, the raw evidence and patterns usually survive. It’s the narrative layer (your positioning docs, your messaging framework) that drifts. You can always rebuild from the patterns up. The foundation cracks, but the bricks are still good.
Data and Context don’t like to Mix. Format Switching Is Hard
The more you switch between plain English and structured data (Clay tables, CSV exports, relational databases) the harder the problem gets. Each format switch adds complexity. For CRM data, MCP servers give you read access inside the context window, but persisting that data into your OS requires automation.
This is where you get into legit data engineering and building out pipelines using tooling like python/pandas and beyond (if you get into this just ask Claude code to guide you to best practices)
Future Iterations
Three years from now, every company is going to have a general company brain. It’s going to look something like this: a decentralized, living source of truth with AI working against it and people managing it.
The next phase is automation. Instead of manually ingesting transcripts, you set up a context worker: Fireflies says “transcript is done,” fires to a Cloudflare Worker, the worker classifies it per your rule set, and pushes it to GitHub automatically. Here’s an example of a live working Context OS for reference.
But don’t build this on day one. Get the static system right first, get the structure dialed, then automate ingestion.
The good thing about starting now: everything is markdown, so it’s always portable. All these tools (Claude Code, Gemini CLI, OpenAI Codex) are converging on the same patterns. The concepts you learn now apply to whatever comes next. There’s no way this is a bad return on investment.
FAQ:
These are questions real people asked at live workshops. Not hypotheticals.
“Does this connect to HubSpot / Salesforce?” HubSpot has its own MCP server. You can add it to Claude Code and get instant read access. But that data lives inside the context window and isn’t persisted into your OS. To save CRM data permanently, you need automation that converts it to markdown (the context worker pattern from the Future Iterations section).
“How do you handle hallucinations?” One context window working against a structured knowledge base produces virtually no hallucinations. Five context windows without a chain to work against, and it starts making things up. The more you want to do with it, the more you have to ground it. And the attribution chain means every claim cites a source you can trace back to the original transcript.
“How does this work with a team?” You need one person who’s the caretaker and manager of the system. Everyone else works against their work. Adding people is orders of magnitude harder, not twice as hard. The solution is Git. Pull requests, reviews, approvals. Someone wants to change the ICP doc? They create a PR. The system owner reviews. Same model developers have used for 20 years.
“Is this different from RAG?” RAG needs a database, embeddings, infrastructure. This is just files with structure. For under a few hundred docs, wiki-links and front matter are more powerful because the agent follows relationships, not similarity scores.
“Can I use Obsidian / Cursor / Gemini instead of VS Code + Claude Code?” Obsidian works. Similar file-system-native model with wiki-links. Cursor works great, it’s what many people use. Gemini CLI and OpenAI Codex are converging on the same patterns. The principle: your AI needs to navigate files directly. Anything that hides the file system from the AI (like Notion) makes this harder.
“Does everyone on my team need a Claude Pro license?” Depends on your operating model. If one person maintains the system and others just read the artifacts (the ICP brief, the objection doc, the onboarding guide), only the maintainer needs Claude Pro. If everyone is querying the system directly, everyone needs access.
“What goes in and what doesn’t?” Your judgment. This is the taste problem. Not more = better. Start with a cutoff point and curate intentionally. Old transcripts from a dead motion make the system worse, not better.
“What if I break it?” It’s files. You can see everything. Open the folder, read the markdown. If something is wrong, you read it and fix it in plain English. Git means you can roll back any change. You literally cannot permanently break it.
“Should I start now or wait for something better?” No bad time. Everything is markdown, so it’s always usable and portable. The concepts you learn now apply to whatever comes next.
Happy building!
An Important Side Note: What would you do if you got Blood Cancer? Who would you call?
This year I am helping raise money for Blood Cancer United. Feel free to click away now, or if you’ve got 30 seconds I’d love to tell you why.
My long time girlfriend Emma was asked to be a part of their Visionaries of the Year Program. Emma has been long involved with Blood Cancer United (previously the Leukemia Lymphoma Society). After the passing of her childhood family friend Meghan a few years ago, Emma got involved, and being in NYC she started attending their yearly fundraising and remembrance event.
If blood cancer has ever touched you or anyone you love’s life, you know the pain, uncertainty and fear it create - that reminder that we don’t have infinite time. I have been fortunate that I’ve only be indirectly impacted (so why I am writing about this? And why are you reading it?)
I won’t pretend that I knew Meghan well, sadly I only met her once, but every year I’ve gone with Emma to the yearly Blood Cancer United Light the Night event here in NYC. And every year I walk away from feeling closer to the feeling of feeling alive.
It yanks me to ground, reminding me of what matters with an immediacy that is both comforting and a reminder of mortality that I think most of us would rather not feel on a frequent basis, but that feeling is what reminds me that I am so very alive.
Every year it reminds me how insanely lucky I am just to be alive and healthy, and for so many that is not the case. Uncertainty around their diagnosis, the outcome, the reality of having to face the end; they are things I would not want anyone to face and certainly never face alone.
So when I see what the impact Blood Cancer United has had for all the survivors who come to tell their stories, many with tears in their eyes, all the families who go and write a name on the remembrance wall, all of them wiping away tears, it has become important to me.
But I’ll be honest, I was hesitant to leverage this, relatively small but meaningful, platform I’ve built since it wouldn’t be directly relevant to my niche, but then I took a step back for a second. What’s the point of building my own thing if I cannot (occasionally and hopefully tastefully) use it to champion important topics that matter to me?
So that’s the ask, if you’ve gotten some value from something I’ve put out and/or have some connection and/or can empathize with that hardship, just take a look :) here
It goes to a good cause: 80% of all blood cancer treatments approved by the FDA since 2017 were funded in part of in entirety by Blood Cancer United and just last year alone they granted more than $3.5m in financial assistance to patients and their families suffering from Blood Cancer.
I’ll be mentioning this fundraiser here and there through the rest of April, as the sprint ends in May, but it’ll always be combo’d with something relevant and valuable to our little AI and GTM niche.
(one of Meghan’s drawings. She was an animator at DreamWorks. It was her childhood dream and s
he did it in her early 20’s. She passed when she was 26.)
Goddamn great way to end it
here for it bro!!