Three kinds of context, three write rules, and a project that outlives the session, the harness, the model and the machine
The last article in this series was not about The Curator at all. It was about the website I built for it, and about a claim I still believe: a website is still the home of a digital product, and in the age of agents it is entering a renaissance rather than a decline. Before that, Where Your Context Lives described The Curator becoming a Mac application, with three layers of context sitting in one folder you own. Before that, The Handoff Writes Itself introduced the layer this article is really about, back when it was a few weeks old and mostly still a design.
I am writing this one because in the past week the thing all of those articles were circling has finally become the product rather than a feature inside it. The Curator now has a category line, and it is not a slogan I chose because I liked the sound of it. It is the shortest honest description of what the app does:
The Curator — the context engine. Your brain. Your team’s brain. Your agents’ brain. A local app that turns what you read into a compounding wiki, shares it with a cohort, and holds your projects’ context — foundations, working state and knowledge — so any agent, in any harness, resumes where the last one stopped. Plain markdown, in your own repo.
The version running on my machine as I write this is v3.64.2. The repository sits at 94 stars and 15 forks as of 20 September 2026. Those are small numbers, and I keep saying so, because the people behind them have shaped this product more than any roadmap I wrote.
If this is the first article of the series you have opened, here is the whole thing compressed.
The Curator is a local application you run yourself. You drop in the things you read — PDFs, Markdown and text files: articles, papers, notes, transcripts — and it writes a connected wiki out of them. A page for every person, tool and idea worth one, all linked to each other. The critical property is that a new source updates the pages that already exist instead of adding another copy beside them. Feed it twenty articles about the same field and you do not get twenty summaries; you get a graph that got deeper twenty times.
Everything it writes is plain markdown in a folder you chose. Obsidian opens it and draws the graph. Your own private GitHub repository syncs it. There is no account, no database, no server of mine anywhere in the picture, and you bring your own model API key. The idea did not start with me: it started with a short thought experiment by Andrej Karpathy about using a language model to continuously build and maintain a wiki rather than to search documents on demand. I took that idea and built it in public, and it has been running in public since April.
That was the whole app for the first six months. Researchers, writers, scientists and content creators were the audience I had in mind, and they still are. What changed this summer is that the same machinery turned out to solve a second problem, one I had been solving by hand for two years, and it is the problem almost everyone building seriously with AI runs into within a week.
A language model, on its own, is a chat engine. It answers and then it is finished. What turns it into something that can build an application, refactor a repository, run a research programme or draft a book is everything wrapped around it: tool access, file access, permissions, a terminal, a loop, an interface, and some notion of memory. That wrapper is the agent harness.
Claude Code, Codex, Cursor, Cline, opencode, Antigravity, Gemini CLI, the DeepSeek agent — these are harnesses. New ones appear every month, and I expect every capable model to eventually arrive with one, because the harness is where the value now accumulates. The same model behaves differently in two different harnesses, and a harness can usually run more than one model. I have a dedicated article on this, so I will not repeat it here; what matters for this piece is one sentence.
The harness gives the model its tools and its memory — which means that when you leave the harness, you leave its memory behind.
There is an assumption I want to dismantle before going further, because it is the reason many readers skip anything that mentions coding agents.
In 2026, code is the substrate of digital work rather than a specialist discipline inside it. Design is code — a design system is tokens, and a mockup compiles to a component. Websites are code. Documents, decks, data pipelines, research notebooks, financial models, simulations, teaching material, a whole product website with an assistant grounded in its own documentation: all of it is produced, today, by giving an agent context and letting it write files.
So when I describe a problem that shows up in coding agents, I am not describing a problem for programmers. Building software is the loudest case, not the definition. The definition is this: any task big enough to take more than one sitting, done with an agent harness, is a multi-session task — and multi-session is where context goes to die.
Write a book with an agent. Run a literature review across two hundred papers. Design a brand and then generate a website, a deck, a one-pager and a set of social visuals from it. Build an investment memo across three months of diligence. Every one of those outlives a single LLM session, and every one of them fails in exactly the same way when the session ends.
For two years I have run the same discipline by hand, and I have written about it repeatedly, so I will state it compactly.
A model holds a context window. Everything the session knows lives in it. The advertised number has grown spectacularly — a million tokens is now ordinary where two hundred thousand was generous eighteen months ago — and this has made people believe the problem is solved. It is not, for two reasons.
The first is that usable context is smaller than advertised context. Output quality degrades well before the ceiling: the model starts contradicting a decision it made two hours earlier, quietly regenerating work it already did, or re-asking a question that was answered. I call this context rot, and it is the reason my own rule has nothing to do with the limit. I do not run to the ceiling. Around 80% of the window I stop and hand off.
The second reason is more structural, and no context window size fixes it. A session ends. When you open the next one, the window is empty. It does not matter whether the window holds 200,000 tokens or ten million; the second session starts at zero. And if the next session happens in a different harness, on a different model, or on a different machine, it starts at zero in a place that has never heard of the first one.
The context window is not the constraint. The session boundary is the constraint, and every tool on the market draws that boundary inside its own product.
For two years my answer was manual and it worked. At around 80% of the window I would ask the agent to write an in-depth handoff file: a short recap of what we had been doing, a clear statement of where things stand, what was decided, what was ruled out, and what the next steps are. Markdown, dated, in the repository. The next session began by reading that file, and then everything else followed — the architecture document when the work needed it, the roadmap when the agent risked drifting.
It worked, and it cost me something every single day. The Curator is the automation of that process — as much of it as can honestly be automated, which turns out to be less than I would like, and I will be precise about that later.
Everything below rests on a working method I have described at length in Context Is the Code and in Chapter 01 of my Field Notes. Every project I build, of any kind, runs in three phases:
1. Phase 1 — Research, Design and Foundations. I use AI to produce the foundational documentation: architecture, blueprint, features, UI and UX, security, deployment, scaling. Markdown files, fine-tuned before any building starts.
2. Phase 2 — The Build. Orchestrated agents, working against those documents, with a handoff written before every context ceiling.
3. Phase 3 — Debug, Audit and Deploy. Ideally with a different model than the one that built it, because a model auditing its own work is the weakest audit available.
Each phase needs a different kind of memory, and this is the observation the whole product turns on. Phase 1 produces documents that must be carried word for word and evolve deliberately. Phase 2 produces state that must be replaced, never accumulated, because a blocker resolved on Tuesday must not be resurrected on Wednesday. And running underneath all three is the knowledge you have built up over months and years, which must accumulate, because that is what knowledge does.
Three kinds of context. Three completely different rules about what happens when you write to them. Get that distinction wrong and the store quietly destroys its own value.
This is the most useful table in the product, and the one thing to learn before using any of it.
The verbs matter more than the layers, and two of them are opposites. Ingest sends a file through a model and writes wiki pages out of it — the original is never the product. Add keeps a document exactly as it is — the original is the product. For a year the app had one front door for both, which was wrong, and correcting it is what the foundations tier is.
The rule I ask people to memorise is shorter: state supersedes, knowledge accumulates. A wiki page unions its bullets — every ingest adds and nothing is dropped, which is exactly right for knowledge and exactly wrong for a handoff, because a union merge has no way of saying this is no longer true. So the handoff overwrites. Put something durable into working state and the next save takes it, with no warning, because from the store’s point of view overwriting is precisely what it is for.
And the newest of the three, foundations, has a rule of its own that is not a technicality: no model ever rewrites a canonical document. Nothing lands in that layer without the owner’s approval. An agent may draft one when you commission it, and you approve it in the app’s own editor. The layer is added to, never ingested into.
Project context in The Curator v3.64.2 — one screen, three numbered steps: ① Foundations, ② Working state, ③ Knowledge. The rail on the left lists live projects grouped by the domain each one sits in; this project holds eighteen work-streams, and the capture reading under step ② says what the last thirty days of agent sessions actually did.
Three kinds of context are only useful if there is a ritual simple enough that an agent performs it without being nagged. There is, and it has two moves.
A cold session — any harness, any model, any machine — makes a single call, get_project_context, and receives three things at once: the standing brief, the latest handoff, and the canonical documents it either has never read or has not read since they changed. Not a search. Not a retrieval step the model has to think of. One call, one response, and the agent is now as informed as the session that stopped yesterday.
Since v3.62.0 you also choose which foundations arrive automatically. Mark a document read first and its text reaches every session; everything else arrives as an index the agent opens by name when the work calls for it. A project’s brief can carry a “Read before you…” section saying which document suits which kind of work. This matters more than it sounds: handing an agent every document you own is a way of spending its context window before it has done anything.
Before the session ends — at a context ceiling, at a compaction, at the end of a task — the agent saves the handoff. The save is complete rather than a delta, and it replaces the previous one rather than being appended to it. It is idempotent, which is why the instruction everywhere in my briefs is save early and save often: a save that turns out to be unnecessary costs nothing.
There is a deliberate asymmetry in the failure mode here and it is the reason no enforcement exists. A missed save yields the previous state — stale, never corrupted, and nothing already written is lost. A forced or fabricated save could give you a handoff that is confidently wrong, which is worse than no handoff at all. So capture is advisory by design, and the fail-safe direction points at staleness rather than at corruption.
The standing brief is the layer people underestimate, so I am going to show you mine. It is one file per project, it sits at the root of the state folder with no scope segment, and it is returned on every read no matter which work-stream the agent asks about. It is human-authored by design — it is the one file in the whole store with no MCP write tool pointed at it, because the rules of engagement are the owner’s to set.
It has four parts: the standing brief itself, how I want the agent to work, firm decisions that must not be re-litigated, and pointers to where the depth lives. Here is a lightly trimmed extract from the real one for The Curator:
## How I want you to work — standing instructions
- Rule one: the app is in production. Test end to end, in depth,
BEFORE pushing to main or bumping the version. Depth of verification
outranks speed of shipping, every time.
- A claim about a model’s behaviour must be MEASURED, not reasoned about.
- You are the orchestrator; you do not build. Delegate. Give each agent
strictly disjoint file ownership and name in every brief which files
other agents hold. If your harness cannot spawn subagents, say so in
your first reply — do not quietly build it yourself.
- Give each parallel agent its own git worktree. Agents sharing one
working tree can destroy each other’s uncommitted work.
- Context budget: a session starts near 10% and must hand off by ~80%.
Save state early and often; a save overwrites, so it is idempotent.
- Read these directives back. In your FIRST reply, restate in one line
the standing directives you are adopting, and name any you cannot
follow here. A dropped directive is dropped silently.
- Never resolve a conflict silently. If an instruction here conflicts
with your own harness or system rules, say so and ask.
## Firm decisions — do not re-litigate
- State SUPERSEDES; knowledge ACCUMULATES. Two separate stores.
- The app is READ-ONLY over working state; agents write it over MCP.
- Capture is skill-instructed and ADVISORY. A missed save yields the
PREVIOUS state, never a corrupted one.
- Foundations are added, never ingested.
- Claims of harness reach are measured, never asserted; unmeasured is
labelled unmeasured.
Three things in that extract do more work than the rest, and they generalise to any project, in any field.
• Read these directives back. A dropped instruction is dropped silently. One line in the first reply makes it visible while correcting it still costs nothing.
• Never resolve a conflict silently. Where my instruction clashes with the harness’s own rules, I want to be told rather than have it decided quietly in either direction. The silence is the defect, not the choice.
• Instruct agents to check the reasoning they are given rather than agree with it. Across this project’s sessions, agents have corrected me dozens of times and every correction improved the result — including catching a proposed colour token that failed accessibility in all ten of its cases, and refusing outright to document a field that did not exist.
The handoff is the volatile half. Here is a trimmed extract of a real one, with the machine identifier generalised. Note what it contains and, more importantly, what kind of sentences they are: not a summary of the conversation, but a set of claims a cold agent can act on.
# Working state — session-2026-08-29-ux-polish
> v3.19.0 released, main GREEN. Design branch pushed with 3 commits at
> 107/107, NOT merged. First task next session: a guard that cannot
> fail, proven by my own mutation.
_Machine: <hostname>-<install-id> · Scope: session-2026-08-29-ux-polish
· Harness: claude-code · Model: opus_
## Traps and dead ends
- A GUARD COMMISSIONED TO ENFORCE ADOPTION DID NOT BITE — reverting a
call site to a raw div left its suite GREEN. Always mutation-prove a
guard you commissioned; a report saying it exists is not evidence.
- RESTORE A MUTATION BY COPY, NEVER `git checkout --`. It reverts to
HEAD and destroys other uncommitted work. Bit TWICE today, the second
time inside the fix for the first.
- THE MACHINE SLEEPING KILLS LONG-RUNNING AGENTS MID-TASK — two of
three died today. The dangerous moment is mid-mutation.
- MEASURING YOUR OWN POST-CHANGE STYLESHEET IS NOT MEASURING THE
DEFECT. Reproduce the original state before claiming a fix.
## Next steps
- FIRST TASK, proven necessary rather than suspected: close the
adoption guard that cannot fail. Assert CALL SITES, not the import
line — an import is satisfied by a file that never invokes it.
- SECOND: finish or revert commit 1795065. Five files are unverified.
- BEFORE ANY MERGE: dispatch the live CI job on the branch.
That traps section is the part I would not give up. It is the accumulated cost of a day, written down in the one place the next session will definitely look. Without it, the next agent — very possibly a different model in a different tool — rediscovers each trap at full price. With it, the cost was paid once.
There is a discipline in writing those sentences, and it is worth stating: a handoff is not a diary. Every line is either a decision, an observation with a way to recheck it, a trap with the evidence that proved it, or a next step with the reason it is next. Prose about how the session felt is noise that costs context window on the other side.
Nothing above is a database. This is the entire storage design, and I show it because the moment people see it the product stops being mysterious:
domains/<domain>/
wiki/ the knowledge — entities,
concepts, summaries
state/<project>/
project.md the standing brief — one per
project, human-authored
foundations/ canonical documents, verbatim
<scope>/<machine>/current.md the handoff — overwritten on
every save
<scope>/<machine>/journal.jsonl one line per save, append-only
A scope is one work-stream inside a project; three features of one product are three scopes, and they all share one brief. The <machine> segment is load-bearing rather than cosmetic: it is a hostname slug plus an install id, and it is what makes two computers syncing the same repository safe to merge. Two machines writing the same file is a conflict; two machines writing their own file is a fact.
That is it. Plain files, in a folder you chose, synced through your own private GitHub repository. Any editor opens them. If the app disappeared tomorrow, you would still have everything, and that is not a marketing point — it is the entire architectural argument. Claude Projects, ChatGPT Projects and Cursor rules each hold your accumulated context inside one vendor’s product, and you leave it behind on the day you switch. There is nothing here to leave behind, because the files are the product and the app is a convenience over them.
The app is one way in. It is not the important one.
The important one is My Curator MCP: a standalone local bridge, a small child process your agent tool launches itself. It needs no running app, no network and no credential, and it is how any harness that speaks the Model Context Protocol — Claude Code, Claude Desktop, Cursor, Codex, Antigravity, opencode and the rest — reads and writes the same files. As of v3.64.2 it exposes 24 tools: seventeen that read and seven that write.
The read side is what matters most, and I want to be blunt about why. Writing knowledge through an agent is a convenience. Reading context through one is the product. Seventeen read tools mean an agent can fetch a project’s bootstrap, walk the graph outward from a page, pull backlinks, search across every domain at once, or retrieve the original source a summary was built from — without a single byte leaving your machine.
And since v3.63.0 there is a second local client that is not an MCP client at all: a command, my-curator. my-curator context prints a project’s bootstrap to standard output; my-curator save writes a complete handoff from standard input; my-curator doctor tells you what is actually wired on this machine and writes nothing. It exists because a harness that cannot speak MCP can still run a shell command, and because the store should not require my app to be running in order to be useful.
Both doors write the same path, with the same provenance shape, under the same single-writer rule. The app itself stays deliberately read-only over working state and foundations: a browser write path would make the app a second writer, and the whole sync-safety argument rests on there being exactly one writer per file.
The format is public, too. The on-disk contract — the layout, the machine-name rule and the merge hazard it prevents, the section grammar, the budgets, the manifest schema — is published as a specification in the repository, and a test suite parses that document against the live constants on every run so it cannot quietly drift from the code. A tool that is not The Curator can read and write your working state without this codebase. That is the opposite of a moat, and it is intentional.
Here is where I have to be more honest than a product article usually is.
Storing context was never the difficult part. Reading it back is not difficult either. The hard problem is that state exists only if agents actually save it — and an agent that has an instruction to save is not the same thing as an agent that saves.
So I measured it rather than assuming it. On 10 September 2026, across sixteen headless runs, an agent on one popular harness saved a handoff in 0 of 4 runs from the installed skill alone — with no error, no refusal, nothing on screen to tell you it had not happened. With a short instruction block pasted into the harness’s own entry file, the same harness saved in 3 of 4. Another harness, which loads skills itself, was 4 of 4 either way. On 20 September 2026 a second campaign added the arm the first could not run — with lifecycle hooks installed as well:
In the same mode, the stop hook never fired at all — not once across six headless sessions — and without the hook, five of six save attempts ran a shell command named after the tool instead of calling the tool. That is the sort of finding you only get by running the thing.
Four words describe what a hook can do on any given harness, and the honest answer is a table rather than a promise. Eleven of the fourteen harnesses in the adapter table have some lifecycle hook and they disagree about almost everything; three of them accept a hook that never fires, and one caps its session-end hook at three seconds, which is not long enough to finish a save. As of v3.64.2, exactly one of those fourteen rows carries a real measurement. The other thirteen read not measured, in the product and in the documentation, and they will keep reading that until somebody runs the protocol.
A hook may ask, inject or record. It may never compose a handoff — because a fabricated handoff is worse than a missing one. The whole contract of the store is that what was written was written by whoever it names.
I am aware that publishing a 0-of-4 measurement about my own feature is an unusual marketing decision. It is the only decision available to me. The Agent Skills standard existing does not mean a given host implements it, and a claim of reach that has not been measured is a claim I would eventually have to withdraw in front of someone who trusted it.
Measuring it once in a lab is not enough, because the question is not whether capture works in general. It is whether capture is working on your project, this month.
So the app now carries a reading. The Working state step of Project context opens with one line, computed from a local, content-free log of which tools were called:
CAPTURE
6 sessions in the last 30 days
4 started with the context · 4 saved before stopping ·
2 read and did not save
25 self-test calls excluded
Three deliberate choices sit inside that small block.
• It is in words, never a percentage. “67%” reads as a grade. “2 read and did not save” reads as two sessions you can go and look at. A reading and a judgement are different things, and the app must not dress one as the other.
• It reports and never blocks. A meter that could refuse a session would be the enforcement the fail-safe rule forbids.
• It tells apart three states rather than blurring them: no usage log on this computer yet; a log exists and there was no session for this project in the window; and the real reading. Only the third gets a freshness mark, and that mark is the age of the newest session — never a grade derived from the ratio.
It also states what it cannot see, on the screen rather than only in the documentation. It counts what went through the bridge, so a save made from the shell leaves no line and a session that never opened the bridge is not in the denominator either. The harness name is self-reported by the client and nothing in the app branches on it. Calls made before the release that introduced session ids are reported as legacy lines and never invented into sessions. And pressing Test all 24 tools on the settings screen is excluded outright, because a button press must never report a session that read and saved.
I use this reading on my own projects daily, and it has twice told me something I did not want to know. That is the point of instruments.
The app now opens onto two doors, and neither is a mode you switch into. They are two ways into the same files.
These are not two products and I resisted every suggestion to split them. A book, a thesis or a research programme outlives any one session, which is the day the second audience becomes the first audience’s future. They share one folder, one sync, one backup, one editor and one bridge. Splitting them would mean two of everything and a boundary the user has to manage by hand.
In v3.64.0 the navigation rail became three entries, each answering a different question: Chat is ask, Domains is knowledge, Context is context. Ingest and Shared Brain did not disappear; they moved onto the page of the domain they already describe, which is where they always belonged.
The knowledge half. One domain’s page in v3.64.2 — 767 pages, 161 entities, 553 concepts, 53 summaries and 4 projects — with Ingest as the first numbered section and the page list filtered to the memory pages underneath.
One feature deserves more attention than it usually gets in these articles, because it changes what the wiki is for.
The Curator talks to three providers: Gemini, Anthropic, and OpenRouter — and OpenRouter is an aggregator rather than a vendor, which means one key reaches models from many companies at once. On one measured refresh in late August 2026, the chat model picker went from 3 models to 192 after structural filtering of OpenRouter’s live catalogue. I will not print a standing number, because that catalogue moved by seven records inside five hours on the day it was measured. What is stable is the method, not the count.
The consequence is what matters. Your compounding wiki, your foundational documents, your handoffs and your projects are all reachable, in one chat, by whichever intelligence you want to point at them today. And as new models appear on those providers, they become available to your existing body of work without you moving anything. Your material stays put; the intelligence reading it improves underneath you.
There is a discipline behind which model is offered for what, and it is worth one paragraph because it is unusual. A model may not be offered for a job it has never been measured doing. Chat and wiki-building are two lanes with two admission standards: the build lane — ingest, health scans, compile — admits only models hand-measured against the real ingest prompt, because a bad chat answer costs one visible answer while a bad ingest writes pages into your wiki permanently and you already paid for it. Price is displayed as a fact and never used as a quality gate, and a model measured to be poor stays pickable with its reason on the screen rather than being hidden.
It is a fair question, and it is getting fairer every month, because the labs are building exactly this into their own products. In August 2026 Anthropic unified Claude’s memory across chat and Cowork, and exposed what it retains in settings so you can read, edit or delete it by topic. That is genuinely good work, and it will solve the problem for a large number of people. If everything you do happens inside one product, use it.
Here is what it cannot do, and it is not a criticism — it is a structural fact about who builds it and why. A vendor’s memory lives inside the vendor’s product. It will not carry your project into a different harness, to a different lab’s model, or onto a machine running something else. It cannot, because the commercial reason for building it is to make the product stickier. Nothing wrong with that; it is simply a different objective from mine.
And the objective matters, because of a fact about models that everyone building seriously has now noticed: they are not interchangeable and they are not equally good at everything. Some are better at building, some at auditing, some at long-context reasoning, some at speed. More importantly, the same model can barely audit its own work objectively. I used to do all my auditing with GPT for precisely this reason; today I get excellent audit results from frontier open-weight models — GLM, Qwen, DeepSeek — as well. The best results come from using several, deliberately.
Mixing harnesses used to be prohibitively expensive, and the cost was never the subscription. The cost was context — re-explaining the project every time you crossed a boundary.
That is the cost this layer is meant to remove. As I write, I am building two of my own projects with three harnesses at once — Claude Code, Antigravity and Codex — all reading and writing context through The Curator. The same mechanism should let several people work one project while carrying context between them; that specific case I have not tested, and I will say so rather than imply it works. The technology permits it. Nobody has run it yet.
The setup is short but it is not zero, and pretending otherwise helps nobody.
1. Install. On a Mac, download the app and you are running in a couple of minutes. It is not yet notarised, so macOS will ask you to allow it — that is on my list. On Windows and Linux it runs as a local server you open in your browser: same code, same release, same features, no widget. If you are on either, your own coding agent will install it for you in about a minute.
2. Point it at a folder for your domains, and connect your private GitHub repository for sync. A few minutes.
3. Add an API key. The app runs on models and has to source them from somewhere. There is a free route into it through OpenRouter.
4. Wire the bridge. There is a wizard, but you will paste a block into your harness’s JSON configuration — Claude, Antigravity, Codex, opencode or whichever you use. Your coding agent can do this for you, and my-curator doctor will tell you whether it actually took.
5. Set up the context layer. Choose the folder your foundational documents are mirrored from, and write the standing brief. Your agent can draft the brief; you approve it.
On a Mac there is one more thing I would not now work without: the menu bar widget. It shows the last save, the recent work-streams, a seven-day save pulse and the standing brief’s age, from the menu bar, with the app closed. The app is low-resource and can be quit entirely — the bridge and the widget are enough for a working day, and you can see at a glance which harness saved what, and when. There is also a documentation site and a product website with an assistant that will walk you through setup, which was the subject of the previous article.
A list, because every article in this series has one and it is the section I would read first.
• Hook reach is measured on one harness out of fourteen. Thirteen rows read not measured and say so in the product.
• The Mac app is not notarised yet. You have to allow it to run.
• Local open-weight models cannot yet run the app. The model behind ingest needs roughly a 200k context window, and running that locally is resource-heavy enough that I have not moved there. I want to, and I am not going to ship it before it is genuinely good.
• Multi-person, multi-harness work on one project is untested. The design permits it. Nobody has run it.
• Mirroring foundations from a remote repository still requires a local checkout to start the mirror, although refreshing one works over the network once it exists.
• Capture is advisory and will stay advisory. That is not a gap waiting to be closed; it is the fail-safe direction, chosen deliberately.
And the discipline that produced that list is worth naming, since it applies to anything you build with agents: a false claim in a document is a first-class defect. In this project several documents are read by models rather than by people, which means a wrong sentence in the documentation does not merely misinform a reader — it changes what an agent does. Documentation ships in the same release as the behaviour change, or the release is not finished.
The next release closes loops rather than opening them: a home dashboard, a cross-scope digest so a project with eighteen work-streams can be read at a glance, and the ability to promote a decision out of a handoff into the foundations layer where it will be carried verbatim from then on. After that, the measurement matrix — running the protocol on the thirteen harnesses that currently read not measured, one row at a time.
But the thing I built, I built because I needed it. For two years I ran this process by hand: foundational documents, a standing brief, hundreds of dated handoff files, and the discipline to write one before every ceiling. It worked, and it cost me something every day. The Curator is that process, automated as far as it can honestly be automated.
If there is one sentence to carry out of this article, it is not about my app. It is this: without proper context you cannot get good results from AI. That is not an opinion, it is the single most reliable observation I have from three years of building this way. Everything good downstream depends on context, and nearly everything bad downstream traces back to its absence.
Three layers, one format, one owner. You.
• Context window — the total text a model holds in working memory during one session. Usable context is smaller than the advertised number; quality degrades well before the ceiling.
• Context rot — the gradual decline in output quality as a session fills. The model starts contradicting earlier decisions and quietly regenerating work it already did.
• Agent harness — everything wrapped around a model that lets it operate: tool integrations, memory, permissions, interface. Claude Code, Codex, Cursor, Antigravity and opencode are harnesses; they can run different models, and the same model behaves differently in each.
• MCP (Model Context Protocol) — an open standard that lets an AI client launch a small local program and call its tools. My Curator MCP is one such program, running entirely on your machine.
• State supersedes; knowledge accumulates — the rule separating the wiki from working state. A wiki page grows with every ingest and drops nothing. A handoff is replaced on every save, because a union merge cannot express “this is no longer true”.
• Foundations — a project’s canonical documents, held verbatim and replaced whole. Added, never ingested; no model rewrites them.
• Scope — one work-stream inside a project, and the thing that holds a handoff. Several scopes share one standing brief.
• Handoff — the complete statement of where the work stands, written before a session ends and read by the next one. Overwritten on every save.
• Repository and documentation: github.com/talirezun/the-curator — the README, the user guide, the architecture notes, the working-state design record and the public on-disk specification.
• Product website and setup assistant: mycurator.xyz
• The Second Brain That Grows Smarter and Lives on Your Computer — where the compounding wiki started.
• Building Knowledge Immortality Through the Second Brain Architecture — why structured knowledge is what survives.
• From Graph to Intelligence: The My Curator MCP — the bridge, and why a graph reads differently from a folder.
• The Agent Memory Problem — And Why Your Second Brain Might Be the Answer — the landscape of attempts at agent memory.
• The Shared Brain: When Second Brains Start Thinking Together — with Dražen Kapusta; the collective layer.
• Second Brain to Shared Brain: Building a Neural Network of Your Own Knowledge — seven weeks later, and what held up.
• The Handoff Writes Itself — the agent memory layer, when it shipped.
• Where Your Context Lives — three layers of context in one folder you own.
• Every Product Needs a Home — building a modern product website with agents.
• Context Is the Code: The Complete Three-Phase Process for Building with AI Agents — the method this article assumes.
• The Mixed Fleet — model specialisation, subscription lock-in, and the orchestrating harness that does not exist yet.
• Chapter 01 · Context Engineering
• Chapter 02 · Agent Memory and Second Brains
• Chapter 03 · Coding Agents and Harnesses
• Andrej Karpathy, the LLM-wiki gist — the original spark for the compounding wiki.
• Anthropic, “Claude’s memory works everywhere, and you decide what’s in it”, 25 August 2026 — the unification of memory across Claude chat and Cowork, referenced in “Why not just use your vendor’s memory?” above.
• Context & Memory Continuity for Coding Agents: A Chasing Jarvis Field Manual — Vanguard MBA teaching material, COTRUGLI Business School. The manual version of the manual process this feature automates.
Dr. Tali Režun is a Serial Entrepreneur, Business Developer, and Academic at the forefront of frontier technologies. As Vice Dean of Frontier Technologies at COTRUGLI Business School, he leads AI innovation initiatives and shapes MBA curricula for the next generation of technology leaders. With over 30 years of entrepreneurial experience — founding and scaling ventures including The Curator, Lumina Agents, Moj AI, Block Labs, 4thTech, Immu3, PollinationX — he bridges cutting-edge research in AI and Web3 with practical business transformation.
talirezun.com · x.com/talirezun · linkedin.com/in/talirezun · talirezun.substack.com · github.com/talirezun · fieldnotes.talirezun.com
This article is published for research and educational purposes. The content represents my own experiences, observations and analysis based on hands-on development and daily use of The Curator. I have not been compensated or sponsored by any company, platform or tool mentioned. Every measurement reported here is dated and was taken against a named release; where something has not been measured, I have said so rather than implied a result. Figures that move between releases — star counts, model catalogues, prices — are readings taken at a moment rather than constants.
Originally published on Substack and Medium; a summary is on talirezun.com.
By Dr. Tali Režun · From Lab to Life · Essay · 20 September 2026