At the end of June, Raffaele and I published cowork-os and I wrote “CONTEXT IS GOLD!” in a post. I still mean it. Since then Yempik's company brain has become part of the daily work of people and agents, and writing the Markdown turned out to be the easy part.
The thesis: context is worth something when another person or another agent can find it, tell when and where it holds, correct it and reuse it without the conversation it came from. Format matters little. What matters is who has the final say, whether you can find it again, how long it lasts, who can see it and how it passes from one piece of work to the next. The rules below come from our own mistakes.
Approved doesn't mean true.
When we reread the whole Brain from the start, we found approved, citable records whose own text said “to be validated” or “I haven't verified this”. The status said one thing, the content another. An agent that looks only at the status turns a hypothesis into a decision nobody made. Trust me bro, database edition.
We split the two questions. The first is whether a claim has entered the Brain. The second is how solid it is: hypothesis, proposal, decision taken, verified fact. The rule fits on one line: an approved hypothesis is still a hypothesis, and whoever reuses it says so in the answer too.
When I teach this I put it like this: tell an agent “I am Simone Bova” and it believes you. Tell it “I suppose I am Simone Bova” and it treats it as a hypothesis. The agent can verify almost nothing you give it, so how certain a piece of information is has to be written right next to the information itself.
A handoff is done when the receiving side can read it.
Yempik's sales automations hit the same problem several times. Verified contacts delivered in chat and never saved to the Brain, so the first-contact queue stalled. A routine that relied on files on my laptop, which scheduled cloud runs can't see.
Each time the work was good. I could see it, the machine after me couldn't. We wrote a rule: every piece of data a later step needs lives somewhere that step can read, and every automation states what it reads, what it writes and where. What lands in chat is for the founder, and if the machine needs it too, it has to be written for the machine as well. The test happens from the receiving side, because your session sees things the scheduled run never will.
An empty search should say why it's empty.
We had an agent work on the Brain for a full day of real work. Memory across sessions held up. Search, though, found nothing on ordinary questions that should have led to approved records.
Search itself worked. The step that makes a record findable after approval was failing silently, and no log flagged it. A broken search and a search with no results gave the same answer. Now a check keeps comparing approved records with findable ones, search says when it's behind, and the test that counts walks the whole path, from writing to searching. If your brain keeps a derived copy of its data, sooner or later the two will drift: compare them and make the system say when it doesn't know.
Two conflicting versions need a written relationship.
The same reread turned up two decisions about the reminder for whoever approves records: one said after an hour, the other after a day. Both valid, neither marked superseded.
“Use the latest document” doesn't cut it here. When a record was written, when it starts to apply and when it stops are different facts. Now a closed initiative keeps its end date instead of vanishing, and every answer says which one is current. When two sources contradict each other we keep both and write down how they relate: one refutes the other, one replaces the other, or they cover different cases.
The brain should know where operational truth lives, without copying it.
We wrote a contract between our systems. The Company Brain holds what Yempik must remember. Linear holds what it must do, GitHub what it has built, the CRM who it works with. Chats are not a source of truth. If a piece of information lives in several places, it has one owner and the others point to it.
The most useful line is about finishing work: when a task is done, the Brain changes only if a lasting truth changed. An ordinary fix doesn't become a record. Without that rule the Brain fills up with state that goes stale in a week, and the agent reads it as if it were true today.
A connection is information too. In the Brain's graph you see a connection only if you can see both documents it joins, and a connection proposed by an agent waits for a person before it counts. You can protect the text of two documents and still leak the fact that they're connected.
Before you change models, look at the instructions they receive.
This autumn I noticed that Claude Code filed sources beautifully into my second brain and badly into another memory connected from outside. Same model, same ability to write. What differed was the rulebook in front of the model. In the vault the project rules are always in context and sources get read in full. On the other path the model got the tools and a thinner guide that pushed it to break everything into fragments and never said when the job was finished.
I merged the rules into a single rulebook shared by both paths. The before-and-after measurement is still to do. Two rules came out of that work and I apply them everywhere.
- An ingestion is complete when a future reader can reconstruct the decision, the reasons, the alternatives, the constraints and the open questions.
- Successful writes and clean links prove little. Complete means reading back what you saved, comparing it with the source and stating what's still open.
The strongest objection: it's just notes, the model learns nothing.
A founder friend told me bluntly on a call: whatever the agent “learns” never reaches the model, it's text files with notes. He's right. Something discovered in a session today doesn't make the model more capable tomorrow.
My answer is to say exactly what improves. The evidence the agent has improves, so does its ability to find it again and the way it carries out a process. The model stays the same. When someone promises you “the agent that learns your company”, ask which of these they mean.
There's also the opposite objection: more memory is always better. When I teach, I ask people to read every line of their memory files at least once a week, and I tell them turning memory off is fine if it gets in the way of the work.
What matters is that it's your choice, and above all a conscious one.
From Monday
- Keep whether a record is approved separate from how solid it is, and carry that difference all the way into the agent's answer.
- For every automation, write down what it reads, what it writes and where. Then test it from the environment it will run in.
- Make the system say when an empty answer comes from missing data, and keep comparing the original data with its copies.
- When two sources diverge, write down how they relate. Give closed initiatives an end date.
- Give every kind of information an owner. The brain keeps reasons and connections, live state comes from the system that owns it.
- Before you change models, put the instructions they receive on each path side by side.