Open your repo and try to find a decision

TL;DR: Your instruction files and your vault hold knowledge well. They do not hold decisions, and that is what your agents are missing when they are briefed.

Some of the best founders we talk to have already built the thing. Claude Code with a repository of instruction files, one at the root and smaller ones nested by function. An Obsidian vault for the notes, the customer, the decisions. Skills for copy, research, outreach and specs, some written, some pulled from skills.sh. MCP into Notion and Linear, and a fast structured model such as Jev for the typed calls inside the workflows. A rule that updating the repository is part of every launch. It runs every morning and it's theirs.

We don't want to replace it. We want to say what it holds, what it doesn't, and what happens as you grow.

What it holds

Knowledge, held well: the product, the voice, the conventions, what happened last quarter. Summaries instead of transcripts keep it readable. Per-function ownership keeps it honest. It's real engineering, and the people who build it get the most out of their agents.

It also costs what its builders say it costs. One widely followed version, a Team OS built in Claude Code, reports weeks to build, a thirty-day commitment to get a team onto it, fifteen hundred hours in and still iterating daily, and a permanent fight against context rot, their name for the slow staleness of files nobody re-read. Maintenance is a job, usually the founder's.

What it does not hold

Open the repository and the vault and look for a decision. Not the product description, not the voice, not what happened. Which customer you're betting on this quarter, what price, what position, and what number would tell you any of those was wrong.

Sometimes it's there, as a dated note: "we price per workspace, decided September 2". What the note can't do is say what it rests on in a form an agent can grade, say which other files became wrong when it changed, or stop an agent from reading last quarter's version with the same authority. The agents inherit the sentence and none of the reasoning, and when the price changes, the sentence in the spec is the last thing anyone remembers to update.

That's where context rot comes from. Not that files age. A file has no way to know it depends on another file, so nothing can tell you which ones went stale when something upstream moved.

The fix isn't a better file. It's attaching a threshold, a kill criterion and a read date to the claim, and the claim's dependents to the claim, so the claim can say when it stopped being true and what it took with it.

Ask it where you stand

Try the most important question on your own system. Ask Claude Code, with the vault open, where the company stands and what to bet on next quarter. You'll get a good memo. Read it for four things.

Does it read buying behavior off an operating number, as in "growth is fast, so buyers decide fast"? Our first read is forbidden to. It states the growth as fact, marks the buyer inference provisional, and names the evidence that would settle it.

Does it state as fact the thing it then tells you to test? The first read may not.

Does it mint a cutoff ("under forty percent, pivot") that reads like a measured line? The first read gives every number a provenance: derived with the arithmetic shown, a guardrail you chose, an assumption waiting for a baseline, or marked to verify.

Does it fork everything on one unknown? The first read says you already have a growth engine, names the channel driving it before anything is redesigned, and treats the open question as what sharpens the move rather than what blocks it.

When it's done, the first read opens on six answers: the call; what to do this week, with an owner, a cost and whether it's reversible; what would make the call wrong; what it's standing on, with sources; what is still open; and what is known against what needs verifying. And it's committed, so every later read starts from it instead of from whichever notes were open.

What changes with a record

StratOS is the record the system was missing, built to sit beside what you built, not on top of it. Every output is a position with a threshold, a kill criterion and a read date. Nothing is committed without you, and nothing committed is rewritten, only superseded with the cause.

Context rot gets a structural answer. Every read knows which reads it rests on, so when the first read changes, positioning, pricing and the brief are marked stale with the reason. You don't re-read the files to find out what moved. What is waiting for a verdict sits on the board until you give one.

Your repository and your vault keep doing what they do well. What changes is what the agents are briefed with: the committed positions and the open bets, read over one connection, with a refusal for a decision that was superseded. What that connection serves, and what an agent may write back, is in Why not just ask Claude?

Hand-built systems are built for the person who built them, which is their strength until the second person arrives. With a record, the second person gets a seat. The founding team controls it, everyone else reads and builds from it, and every new reader is a new reader instead of a new sync problem. What accumulates is positions with verdicts, so the positioning read in March knows what the pricing bet in November taught you without anyone writing it into a file.

Keep your operating system. It's good and it's yours. The first thing to add to it is a decisions folder with a threshold, a kill number and a read date on every entry, and a note of what each entry rests on. The record is that folder, kept for you, and read by your agents before they build.