The curator
A second, smaller agent whose only job is the project memory. It cannot change code. It can look things up, judge what is proposed, and — after arguing it out with you — write something down.
It has two duties. Harvest: after each mission it reads what happened and proposes what the project should remember. Maintain: in its own chat it works through what is pending, the conflicts and the proofs with you.
How the memory flows
| Step | What happens |
|---|---|
| Recall | When a mission starts, it loads the project's rules and an index of what the memory knows. |
| Agent | While it works, the agent looks things up in the memory whenever it needs them — a lookup. |
| Harvest | When the mission ends, the curator harvests it and proposes what is worth keeping. |
The harvest session
Every session gets a companion harvest session the first time
it is harvested. In the session list it sits right under its session as
↳ harvest. In a chat, ctrl+t switches
between the session and its harvest session.
There you watch the harvest live: what the curator reads, what it looks up in the memory, what it proposes and why. You can answer it — “don't store that”, “also note Y”, “why Z?” — and it withdraws or rewrites its own proposals.
It only proposes. Every proposal waits at the gate
(/pending) for your click. When a harvest is still running as the
next mission ends, the next one queues behind it; none are lost, even across a
restart of Nemocode. Its cost shows up in the harvest session, not in your
session.
With the harvest trigger set to manual (/config ▸
General), missions wait until you type /harvest.
Open the curator chat
/curatorThe chat switches: you are now talking to the curator. Switch back with the same command. Its conversation is kept apart from your coding conversation.
It names its source
Every fact it states about your project comes with where it got it: the remembered statement, or the file and line it just read. If something is not in the memory, it says so instead of guessing. If a statement is weakly supported, it says “probably” and tells you to check.
Writing a fact
Tell it to remember something and it will not just do it. It looks it up first, then puts its case to you: the exact sentence it would store, what speaks for it, the strongest argument against storing it — too obvious, derivable from the code, a wish rather than a fact, already known — and why it still thinks it belongs. Then it asks.
Only your yes writes it. The memory then shows that conversation as the source, so months later you can see it came from you and not from a guess.
It is allowed to disagree with you. A memory full of trivia is worse than a small one, and the curator is told to say so.
What the curator can change
The gate (/pending) is where proposals wait, and the curator can
work on the whole memory with you. Everything it can do to the memory is on this
list — nothing else:
| Action | What it does |
|---|---|
| Decide a proposal | Approve or reject one entry at the gate. |
| Resolve a conflict | Keep the first statement, keep the second, or dismiss the conflict. |
| Add a fact | Write a new statement. Only after the argument described above, and only with your yes. |
| Reword a fact | Replace the statement of a node. |
| Rename a fact | Give a node a new id, and say whether its
connections move along (they do, unless it says otherwise). An id may contain
letters, digits and . _ : / -, at most 120 characters, no
spaces. |
| Retire a fact | Supersede it, optionally in favour of a newer one — or delete it. |
| Make or clear a rule | Mark a fact as a rule that must hold, or take that away. |
| Connect and disconnect | Add a connection between two facts, with its kind and an explanation, or remove one. |
| Judge a proof | Vouched, refuted or irrelevant — see below. |
| Delete a proof | Remove a piece of evidence. |
| Choose the folders | Which folders of the project feed the memory (an empty choice means the whole project). |
It can also look everything up: the gate, the conflicts, the proofs, a node with its connections, past sessions you allowed. None of this touches your code.
Curator requests
Nothing the curator wants to change in the memory happens right away. Every action from the list above becomes a request. The curator keeps talking and working; it does not stop to wait for you. The same goes for another coding agent that curates: its requests land in the same queue, marked with its name (see Letting an agent curate).
Open the queue with /requests, or with Curator
requests in the browser's Curator tab. The header shows how many are
waiting. Each request shows the action, what it targets, the curator's reason
and evidence, and the memory before and after.
| Key | What it does |
|---|---|
| a | Approve: the change happens now, with the normal history and undo. |
| x | Reject. Type an optional reason and press Enter to send (Esc cancels). The curator reads it in its chat. |
| Enter | Show all details. |
| c | Ask the curator about this request. For a request from another coding agent, ask that agent in its own tool. |
| A | Approve all shown — only after you confirm with y; any other key cancels. |
| r | Reload the list. |
| Esc | Close. |
A coding agent that curates can file one more kind of request: to approve a team review at the exact version it looked at (see Letting an agent curate).
In the browser each request has approve and reject, and
approve all shown asks for a second click. If a request fails when you
approve it — the fact was renamed in the meantime, say — it says why and stays
in the list. The queue survives restarts. /curators (or the list at
the top of the Curator tab) shows every curator chat of the project, including
the harvest sessions, and opens any of them to carry on.
Every conflict has a discuss with curator button in the browser, and c at the gate does the same: the curator starts with both statements in front of it.
You judge the evidence
Every fact rests on proofs — a test, a file, a document, a conversation. Whether a proof really supports its fact is your call, not the curator's: you vouch for it, refute it, or mark it irrelevant, and that verdict stands. The curator can suggest a verdict, but it is a request like any other: it counts only once you approve it.
| Verdict | Means |
|---|---|
| Vouched | You know this to be so. The proof counts in full from then on. |
| Refuted | You can name a case where it does not hold. The reason is required — a refutation without the counter-case is just a claim. |
| Irrelevant | It may well be true, but it does not support the statement it is attached to. A reason is required. |
There is deliberately no “looks good”: observations that fit do not establish a general statement. A human verdict outranks the model's and is not revisited by it.
Reading past sessions
The curator can read what was said in earlier sessions — a decision you explained three weeks ago, the reason behind a change — and cite the session as its source. It only sees the sessions you allowed: nothing is granted by default, not even this project's own sessions.
Open Session access with e in the
project or session list, or under /config ▸ General. Tick a project
to allow all its sessions, or tick single sessions underneath it. Sessions of
other projects can be allowed too.
Your own rules
You can write down what belongs in your project's memory and how a statement
should be phrased. Put a pum.md in the project's Nemocode folder — the
curator reads it and follows it. For example:
# Rules for this project's memory
- No runtime data, no user data, no intermediate state.
- Decisions WITH the reason, not just the outcome.
- Anything derivable from the code does not belong here.
- One sentence per fact, in the present tense.It is the same idea as the instructions file your coding agent reads, but for knowledge instead of code conventions.