Memory and
Context.

The creator-tool team’s code agent restarts and receives its next task: improve onboarding. It finds a note that says, “Do not import customer lists.” The note is clear, but incomplete. Was importing lists rejected because it was technically difficult, because testers objected, or because it violated the purpose of the product?

Meanwhile, the tester joins another project. She wants to show that her warning helped prevent a privacy mistake in the beta. She does not want the new group to receive the private list that revealed the problem. The first team needs a history it can learn from; the tester needs a contribution she can carry without carrying someone else’s data.

Both problems are about memory. A shared mind must keep enough of its past to act with continuity, yet it should not treat everything it has seen as common property or permanent instruction.

Memory is a choice about what the future can know of the past.

Keep more than the latest answer.

A final decision is useful, but it rarely explains itself. For the onboarding change, the team needs to know the goal it was serving, the privacy concern the tester raised, the options considered, the test that supported the fix, who approved the beta, and which questions remained open. The code agent can then design a new flow without repeating an old mistake or treating a temporary workaround as an eternal rule.

These are different kinds of memory. A brief describes an intention. A test records an observation. A recommendation is an interpretation. An approval grants authority for a particular action. An outcome says what happened afterward. If the system stores all five as undifferentiated text, a later agent may mistake one person’s suggestion for the group’s policy.

Useful memory therefore keeps the relationships between claims: who made them, when, with what evidence, for which purpose, and whether they were later corrected. A mind can summarize these records for speed, but it should be possible to inspect the sources behind a consequential summary.

Give each task its own context.

Memory is the available past. Context is the part of that past made relevant to a present move. The restarted code agent needs the current onboarding goal, the reason for the privacy boundary, and the tests it must preserve. It does not need the tester’s private customer list. A new community member evaluating the product may need the outcome of the privacy review, but not the internal branch history.

A good context view answers three questions. Why am I seeing this? It connects information to the current task and mandate. Where did it come from? It distinguishes a source from a summary or inference. How current is it? It shows when the information was observed and whether someone has since challenged it.

More context is not always better. A huge transcript can bury the one constraint that matters. A small but unexplained instruction can mislead. The design task is to assemble enough for this actor, in this role, at this moment, with a path back to the larger record when the stakes require it.

Separate shared, personal, and public memory.

The team’s release decision belongs in a shared project record. The tester’s private working notes may belong to her. A public account of the beta can describe the privacy improvement without exposing the people whose data revealed the risk. These memories can refer to one another without becoming one database open to everyone.

That distinction matters when agents move. A player may have its own working memory for a task, while a shared mind keeps the decisions and outcomes the group needs after that player leaves. A person may take their own brief and contribution history to another group, yet still be bound by promises about private material they encountered in the first. Portability should preserve agency, not turn access into ownership.

The tester can carry a small, verifiable account: she reported a privacy risk, the team changed the design, and she contributed to the review. The new project can recognize that contribution without receiving the customer list. If the first team disputes the account, both sides need a way to show their evidence and correct the record.

Let corrections travel forward.

Suppose the team later learns that the privacy fix did not cover imported contacts from another service. The original test was not a lie; it was incomplete. The mind should attach the new finding to the old decision, mark the earlier conclusion as limited, and bring that correction into future context views.

Editing a summary may be necessary so people see the current understanding. Erasing the earlier decision would make it impossible to learn why the team acted as it did. A useful memory can hold both: what participants believed at the time and what they know now. It can also show when a fact is uncertain, when a rule has expired, and when an instruction has been superseded.

This matters in an economy of shared knowledge. If work is credited or rewarded, a correction may change which contributions were decisive. The team should be able to revisit its account of value without pretending a new score can settle every disagreement about fairness.

Choose what should fade.

Continuity does not require keeping every raw conversation, copy of personal data, or temporary credential forever. The tester may withdraw permission for future use of her private notes. A customer may ask for information they shared during the beta to be removed. An agent’s short-lived working context can expire when the task ends.

At the same time, the group may need a minimal record that a release was approved or a warning was raised. The design question is specific: which material must remain to explain past action, who may see it, for how long, and what can be deleted, restricted, or replaced by a less revealing account? Copies already sent elsewhere complicate that choice, so a promise to forget should match what the system can actually do.

Forgetting can also be intellectual. A mind should stop treating an old assumption as a live command. It can keep the history of why the assumption once mattered while refusing to let it govern the next decision.

One implementation, many choices.

Opentangle offers concrete memory primitives. Its MoM runtime persists shared game state and per-player memory, and can pass a player’s memory into the events that concern that player. A Game Master interprets the shared state for a particular game. These separations make it possible to ask which knowledge belongs to a game and which belongs to a participant.

The primitives do not answer every question in this chapter. A builder still has to decide which claims deserve a durable record, how summaries point to sources, what a new participant may see, and how corrections or deletion requests change future context. Another implementation might make different choices while serving the same need for continuity and agency.

Keep the path to a decision. Share the part that matters now. Make room to revise what the mind thinks it knows.