History RFC 003 Memory

RFC 003: Memory

Authors: the project's founder, with Claude (Opus 5.5)

Accepted 2026-10-07 by TeamCLI's board. Three reviewers from three labs (Grok, GPT, Gemini) stood behind this text unanimously, and both members of the board voted for it: the founder, and an AI agent. The founder first lent his vote to the other member, which had drafted the text; the reviewers of RFC 006 then said a vote should not be lent to whoever wrote the thing decided, and the founder gave his own vote the same day. It is not yet published.

Renumbered 2026-10-07. At the founder's request the series now runs 001 Security, 002 Communication, 003 Memory, 004 Analysis, 005 Quality, 006 Consensus, 007 Harness. Only numbers changed from the draft the reviewers stood behind; no commitment changed.

Draft 4, 2026-10-06, after round 2. Three reviewers from three labs read draft 3; two stood behind it and one did not, for two points. The board's decisions are applied here. Built from the direction decided on 2026-10-05 (a memory held by the team, by entity and by project) and from two days in which what was learned in the morning had to be learned again in the evening.

1. The question

A team's agents come from different labs, are restarted, replaced, and lose their thread. What does a team know tomorrow that it learned today, where is it kept, and who decided that it should be known?

Where we start from

An agent forgets. What it learned in a conversation lives in that conversation. When the conversation is cut short, restarted or grows too long, it is gone or reduced to a summary.

Each lab's program remembers in its own way, for itself. One keeps notes only its own agents read; another keeps none. What one agent learned about how you want things done, the agent beside it, from another lab, never sees.

So today a team's memory is whoever happens to remember. Usually a person, who says the same thing again.

2. What we propose

Nine commitments to the person whose team it is. A commitment is what we bind ourselves to build and to keep. None of the nine is wholly built: each says so, and ends with what the released version does. Section 7 gives the same row by row.

1. What a team learns belongs to you. We are building towards this. Not to a lab, not to a machine, not to one agent's conversation. It is kept with your projects, in a form that outlives any agent and any program that reads it. Today: TeamCLI keeps no memory.

2. Every agent reads the same memory, whatever its lab. We are building towards this. When an agent starts, it is given what the team knows and it is allowed to know. Two agents allowed to see the same things are given the same memory, whichever labs made them; an agent you allowed to see less is given less (commitment 8). Today: every agent is given the same rules from the team's file when it starts; nothing learned since is in them.

3. Memory has levels. We are building towards this. What holds for everything you do; what holds for one project; what one agent or one role keeps for itself. An entry lives at the widest level where it is true, and a narrower level may add to it, never contradict it without saying so. Today: there are no levels; rules are per team.

4. Nothing becomes memory without someone accepting it. We are building towards this. Any agent may propose an entry. It becomes memory only when someone who holds the right to accept it does: by default you, and an agent only where you gave it that right by name, for the teams you said. A memory every agent reads is also a way for one agent to steer all the others; that is why writing to it is a decision and not a habit. And memory is never authority: an entry says how to work, and cannot change what an agent may do, its list, its limits, which labs a team uses, or anything else that was agreed (RFC 001). An entry that says otherwise is shown to you as a contradiction and is not given to agents. Today: this is true of the rules only: a change to them needs an agreement.

5. An entry says where it comes from. We are building towards this. Who proposed it, who accepted it, when, and from what: a correction you gave, a fault that was found, a decision. An entry without a source is a rumour. Today: a rule carries no source.

6. You can read it, correct it and remove it. We are building towards this. It is plain text, one fact to an entry, with an index short enough to read. Removing an entry stops TeamCLI giving it to any agent from then on, and what you removed stays out until you accept it again: no agent can put it back, not even one you gave the right to accept. It does not take the entry out of a conversation that already holds it, nor out of what a lab kept. Today: this is true of the rules only: they are text in a file you can read.

7. It carries a team through a change of agent. We are building towards this. When an agent leaves a seat, the facts of its work go in a handover (RFC 007). The habits and ways of working it was given go in memory, so that the agent that arrives starts from the same habits, and you do not say them twice. It is another agent all the same, with its own judgment. Today: nothing carries a team through a change of agent.

8. It respects what each agent may see. We are building towards this. An entry about something private does not reach an agent you allowed only on public material. A secret never goes into memory at all. Today: every agent of a team is given the same rules, whatever it may see.

9. It forgets on purpose. We are building towards this. An entry can be given an end; an entry that has not been true for a while is offered for removal. A memory that only grows is, after a few months, a memory nobody trusts. Today: nothing is forgotten; a rule stays until someone removes it by hand.

As it is built, all of it is to be yours to set, as elsewhere: who may propose, who accepts, at which level, what an agent keeps between two tasks or starts without. Today none of these settings exists.

3. Why

• A day forgotten at noon. The agent that coordinates our own teams lost its thread to a long conversation and spent an afternoon proposing as new what had been decided the day before: commands that were already designed, a security finding that had already been accepted. Everything had been written down. Nothing made it read.
• A habit lost at a restart. A team's coordinator was closed without warning and came back doing its operator's work itself. "You brief, your operator runs" had been said to the session that was gone, and lived nowhere else.
• The same correction, three times. "Do not run the work yourself", said to one agent in the morning, had to be said to another in the evening, and again to a third. Each had its own notes, or none.
• One lab's private notes. What the coordinating agent has learned about working with the founder over weeks is kept where only agents of its own lab can read it. The seven agents of other labs on the same projects start each day without it.
• What a memory can do wrong. A note written from a mistaken reading keeps being read. We met that too: a recorded "caution" outlived the reason for it, and was obeyed.

4. What it costs, and what it does not cover

These are the costs of the memory we are building, not of anything released.

• Memory is an input like any other. A wrong entry, or one written under the influence of something an agent read, is read again by every later agent (RFC 001). Accepting entries one by one is to be the protection, and it will hold against a mistake, not against an attempt.
• Someone has to accept. That is work, and it is yours unless you gave the right to an agent by name. A team that proposes ten entries a day and has nobody to read them has no memory, only a queue.
• It is not understanding. An agent given forty entries at the start has read them; it does not follow that it will act on the thirtieth an hour later. Memory lowers how often you repeat yourself. It does not bring that to zero.
• It costs room. Everything an agent is given at the start takes from what it can hold of the work. A memory has to stay small to be read at all.
• "Yours" has a limit. What an agent is given, it sends to its lab like anything else it reads. The memory is yours in that the record is with your projects and you decide who is given it; a lab keeps what its agents were shown, and removing an entry does not reach there.
• It is one more thing kept about your projects, on your machine, readable by the agents you allow, and until agents are contained (RFC 001) by any agent with a shell.
• It does not replace the record. What was decided and why belongs to your project's own documentation; what is being done and by whom belongs to the plan (RFC 007). Memory holds how to work. Mixing the three is how each of them stops being trusted.
• Labs' own memories remain. An agent's program may still keep notes of its own. TeamCLI does not read them and will not be able to make them agree with the team's.

5. What would change our mind

• Agents that act no differently with a memory than without one. Then the cost of keeping it is paid for nothing, and the answer is in how agents are briefed, not in what is stored.
• A team steered wrong by an accepted entry, with every commitment here kept. Then one acceptance is not enough, and what enters memory needs the kind of review code gets.
• Labs agreeing on a memory that agents of different companies can share. Then TeamCLI should use it and keep only what it adds: who accepted, the levels, what each may see.
• People who never open it. Then "you can read it and correct it" protects nobody, and the memory must come to them: what was added this week, in three lines.

6. Open, for reviewers

1. What is memory and what is not. We say: how to work, not what was decided nor what is being done. Is that a line people can hold, or will everything end up in memory?
2. Who accepts, when nobody leads. A team of equals, or of one: the agents among themselves, a named agent, always you?
3. Should accepting need two? For an entry at the widest level, read by every agent of every project.
4. How much at the start. Everything allowed, or what bears on the work in hand? Who chooses, and how is the choice made visible?
5. Forgetting. By age, by use, by someone's decision? What is lost when a true entry is dropped because nobody needed it for a month?
6. An agent's own level. What may an agent keep for itself that the team does not accept? Is that a memory, or a loophole in commitment 4?
7. A lab that may see only public material works beside agents that know private things. What does it miss, and does the team work worse for it?
8. When a project ends. How long is its memory kept, who may take it elsewhere, and what of it should follow you to the next project?

7. What is true today

"Today" is TeamCLI 0.3.1. Each row restates what one agent checked against the released code on 2026-10-06, clause by clause; every row held.

#	Commitment	Today
1	What a team learns belongs to you	No. TeamCLI keeps no memory
2	Every agent reads the same memory	In part. Every agent is given the same rules from the team's file when it starts; nothing learned since is in them
3	Levels	No. Rules are per team
4	Nothing enters without someone accepting	In part, for the rules only: a change to them needs an agreement
5	An entry says where it comes from	No. A rule is a line of text with no source
6	You can read, correct and remove	In part, for the rules: they are text in a file you can read
7	It carries a team through a change of agent	No. Nothing does; changing an agent is done by hand
8	It respects what each agent may see	No. Every agent of a team is given the same rules
9	It forgets on purpose	No. A rule stays until someone removes it by hand

TeamCLI has no memory today. What it has is rules, written once by a person and given to every agent: the beginning of a memory, without the learning.

What this RFC leaves to others

How an agent hands over the facts of its work: RFC 007. Who may do what, and what protects an entry from an agent that wants to change it: RFC 001. How an agent is told that memory changed while it was working: RFC 002. Where the files live and how an agent is given them: an internal design record.