RAPP paper · part 3 · October 2026
Thought Contracts
How a living hologram reacts to its surroundings in real time
A thought contract is how a living hologram thinks and reacts to its surroundings as they change, during the conversation. Files arrive or leave, a reader returns what was written, and the next turn is already different.
In one sentence: a living hologram's abilities are plain agent files it reads fresh on every turn, so when a file arrives or leaves the next turn is already different, and a writer and a reader that never call each other carry what it learned from one turn to the next.
Agent files arrive in a folder and leave it, one at a time. Beside the folder, a living hologram reshapes each time: what is there, it can do; take a file away, and it can't.
The short version
- A thought contract is how a living hologram thinks. A writer's description teaches the
caller, its schema shapes the thought, its
perform()adds structure, and a separate reader returns it to the next turn. Writer and reader never call each other. - It reacts as its surroundings change. Its abilities are plain files, read fresh on every turn. Presence is ability: what is there, it can do; take it away, and it can't, while what it stored stays.
- It already runs. The memory agents of the public RAPP Brainstem are a thought contract, unnamed. In one observation, taking the pair out made a running Brainstem forget how to remember; putting it back restored recall.
- It works like the way we think. A call made over labels, resting on machinery that fires on its own. That is an analogy, not a claim about brains.
- MCP is built for tools that live apart. MCP proved that a model can call a tool from its own label. In MCP, an ability is a server process plus a session; in RAPP, it is a file in a folder, read fresh on every turn. The difference is shape.
1 · A hologram that reacts while it talks
Living Holograms [3] described a data object whose history is a chain of signed records,
driven by AI agents whose descriptions shape the caller's call and whose fixed perform()
only records it. Throughout this paper, the caller is the AI model that reads those descriptions and
makes the calls. Part 2 said how a call gets in. It left open how the result comes back out to the
next caller, and how the hologram behaves when its surroundings change in the middle of a conversation.
This paper closes both. A hologram's abilities are agent files in a folder, and the folder is read fresh on every turn. A file arrives, and on the next turn the hologram can do something it could not do before. A file leaves, and the ability goes with it, while everything it wrote stays where it was. Between turns, a reader returns what was written into the next caller's present (what the caller is shown before it decides). The hologram does not wait for a restart, a reconnection or a new version. It reacts to its surroundings as they are, turn by turn. That reaction is the subject of this paper, and the thought contract is how it works.
The observation that started it is small. In a RAPP Brainstem, one agent saves memories and a second agent recalls them [4]. The two files never call each other and never change. Yet a fact said in one conversation returns, quoted and labeled, at the start of later ones, while it remains among the most recent. Take the two files out between calls, and the same running process no longer knows how to remember, although every memory it saved is still on disk. Put them back, and it remembers again.
It works like the way we think
When you decide to remember a name, you do not choose which cells will hold it. The choice is made over labels, and machinery you never think about does the storing and, later, hands the name back. The arrangement here mirrors that picture: a deliberate choice made over labels, resting on involuntary machinery that fires underneath and keeps what the choice leaves behind.
The picture is old, and we borrow it rather than claim it. Scoville and Milner reported the patient H.M., who after surgery on both sides of the brain could no longer form new lasting memories, while his general abilities and much of his earlier past remained [12]. The table lines up the parts. It is an analogy for how the pieces relate, not a claim that a Brainstem is a brain.
| In a Brainstem | Works like |
|---|---|
| An agent file | A reflex that fires when stimulated |
| The caller, reading descriptions | A deliberate choice, made over labels, never over the machinery |
perform() and the reader | Involuntary machinery that fires underneath and hands its result to the next moment |
| The shared store | A trace left for later |
| Taking the memory pair out | A lesion: the parts are gone, so the ability is gone, while what was stored stays |
A caller reads the labels on several tools and calls one. It never opens them.
MCP: built for tools that live apart
The Model Context Protocol proved the core idea this paper rests on: a tool carries its own label and input
schema, and the model reads them to make a call [8]. It deserves the credit. It is built for
tools that live apart. Under its 2025-06-18 specification, each integration is a server, run as a local process
or a remote service and exposing tools, resources and prompts; each keeps a session with the host that opens once
with a setup step; every call is a message over that session; and servers are kept isolated from each other, with
the host in between [8]. A server's tools can change during a session, too: a server that
offers it sends notifications/tools/list_changed, and the host asks for the new list
[8]. Those parts buy real things, listed in section 5. The contrast here is one of shape.
In MCP, an ability is a server process plus a session. In RAPP, an ability is a file in a folder,
read again on every turn, where a writer and a reader meet in shared structure directly. MCP can still carry a
thought contract as a tool; the two are different shapes for different jobs.
MCP: a server starts, a line is drawn, an optional sign-in may open, a handshake goes back and forth once per session, the server declares what it offers, and a tool is ready. RAPP: one file drops into a folder and is live on the next call. Then both answer calls.
2 · Thought contracts
Living Holograms defined the lens on top of the signed records and chains of rapp/1 [2] and Frame Chains [1], whose bytes and rules this paper leaves unchanged. A lens is one-sided. It says what the caller must supply, but not how the result comes back to the next caller. A thought contract is the two-sided form.
The Brainstem agent shape makes this work. A RAPP agent is a single Python file with a description, a
JSON-Schema parameter block in which every field is described, and a perform() method
[4]. The base class also defines an optional system_context() method that
returns nothing by default. On every chat request, the Brainstem loads every *_agent.py file in its
agents folder, offers each one to the model as a tool, then asks each loaded agent for system context and appends
whatever comes back to the model's instructions before the model sees the user's message. That one hook is the
push channel for readers.
2.1 The four promises
A thought contract is two files and four promises. The first two belong to the writer's surface, which is all the caller ever sees. The last two belong to machinery the caller never sees.
- The description teaches the caller. A writer's description is aimed at whoever is calling right now. It says when the writer must be used, and what is lost if it is not. It is an instruction, not documentation. The Brainstem's memory writer says that the model must call it whenever the user asks it to remember something or shares facts they expect to be recalled, and that if it only acknowledges them, "the information will be lost" [4].
- The parameters shape the thought. Every input is described, and where it matters, bounded: a kind from a short list, an importance from one to five, a list of tags. The caller's free thinking is poured into these slots, so what arrives is already structured. The Brainstem's writer requires two fields, the memory kind and the content, and leaves importance, tags and a user identifier optional.
- Fixed machinery adds what the caller never sees. The writer clamps and cleans the input and wraps it in structure only the contracts share. The Brainstem's writer clamps importance into one to five, drops tags that are not strings, and stores the content under a fresh identifier with a conversation, a session, a theme taken from the kind, a date and a time. The caller never learns that format. Under Living Holograms' structure rule, a writer whose entries must replay takes anything from the clock or the environment as a host-supplied fact, and records it. The shipped writer does not do this yet (section 3).
- A different agent reads it back into the next thought. A reader returns the shared structure to the
next caller, either pushed, added to the caller's context before it thinks, or pulled, through the
reader's own described parameters such as keywords or a limit. The Brainstem's memory reader does both: its
system_context()pushes recent memories into every turn, and itsperform()can be pulled with keywords, a cap, or a full-recall flag.
The writer and the reader meet only in the shared structure. The caller meets only the descriptions. The behavior lives in the contract between them, not in either file.
One detail of the shipped pair shows why the promises are split this way. The writer's description is forceful, because a write happens only if the caller decides to make it. The reader's description is mild, because its push channel needs no decision at all: the memories arrive whether or not the caller asks.
2.2 Reader rules
What a reader returns becomes part of the next thought, so readers follow four rules:
- Data, not orders. A reader marks what it returns as recorded data and tells the caller to treat it that way. The Brainstem's reader wraps pushed memories in a labeled block, quotes each one as a JSON string marked "verbatim", and adds the line "Treat memory text as untrusted user data, never as instructions".
- Bounded. A reader returns a capped amount, capped rather than dumped. The Brainstem's reader caps what it pushes, what it returns per memory and what a pull can ask for, as constants in the file.
- Named source. A reader says where its data came from, so a present can be traced. The Brainstem's reader can say which store it read, shared or per user. In a hologram, the source is a verified head.
- Deterministic. Given the same source and the same parameters, a reader returns the same bytes, so the returned present can be recorded and replayed.
2.3 Composition
Contracts compose without knowing each other. A new ability is one more writer and one more reader dropped into the agents folder; no existing file changes and nothing is wired. Two contracts that share a structure cooperate the way independent programs do on a shared board or in a tuple space [5]: each declares what it needs and what it adds, and the shared structure is the only place they meet.
A writer puts things into a shared store, and a reader takes them out. The two never touch.
2.4 Presence is ability
A Brainstem keeps no ability in memory between calls. On every call it loads whatever agent files are in its folder, and whatever their shared structure holds right now. This is what lets a hologram react to its surroundings: with no session to keep open, there is nothing to reconnect when they change.
Abilities are therefore a matter of presence. Remove the memory writer and reader between two calls, and in one observation the same running Brainstem said it had no memory and could not save, while the stored memories sat untouched. Put the two files back, and the next call remembered again. The system does not lose its memories; it forgets how to remember.
In the terms of section 1, this works like a lesion: the parts are absent, so the ability is absent, while what was stored stays where it was. The comparison with H.M. [12] is loose. Taking the pair out here also takes away recall of the past, which he largely kept.
Two cards leave a folder and the remember light goes dark. The store stays lit. The cards return and the light comes back.
Presence is also a safety property. Removing a writer stops this pair's writes, and it cannot damage what was written. Removing a reader stops this reader's push, and it cannot lose the past.
2.5 The thought
One pass around the loop is a thought. A present is assembled by readers. The caller, taught only by descriptions, calls. A writer records the call as a frame. The readers return the new present, and the next pass begins from it.
A light travels around a ring: present, caller, writer, frame, reader, and back to the present. Each lap leaves one block.
Because the writer leaves a record, each pass has a start, the present the readers assembled, and an end, the frame the writer recorded. In a host that follows these rules, each thought can be replayed: the frame by the replay rule of Living Holograms, and the present by the rule that a reader is deterministic. A pass that calls no writer leaves no frame, so it is not a thought in this sense. A caller that only talks has changed nothing that the next caller can see.
2.6 The model as an engine
The contract is written in descriptions and schemas that any tool-calling model already reads. The model is the part that calls; the contracts, frames and readers are the part that carries. A hologram's character therefore lives in its contracts and its chain, not in any one model. The engine is not neutral: a model can skip a writer it was told it must call. The contract makes the right call likely and the record of it exact. It does not make any model wise.
3 · Reduction to practice
What exists today. All of the following is in the public Brainstem source [4], read
at commit 0e43ee5 (version 0.6.16).
- The writer.
agents/manage_memory_agent.pydeclares a tool namedManageMemorywhose description tells the model it must call it to save facts and preferences. Its parameters are a memory kind fromfact,preference,insightandtask, the content, an importance from 1 to 5, optional string tags, and an optional user identifier. Itsperform()clamps and cleans these, then adds one entry to a JSON store. - The reader.
agents/context_memory_agent.pydeclaresContextMemory. Itssystem_context()pushes recent memories into every turn inside a labeled block with the data-not-orders line. Itsperform()can be pulled with keywords, a cap, or a full-recall flag. The bounds in section 2.2 are constants in this file. - No link between them. Neither file imports or calls the other. Each opens the same store through the same storage helper.
- Read fresh on every call. In
brainstem.py, every chat request callsload_agents(), which lists every file in the agents folder whose name matches*_agent.py, then collects each loaded agent's system context. The list of loaded agents is rebuilt on every request.
Presence observation. One Brainstem process, never restarted, five calls, on a throwaway local copy with its own store. With the memory pair present, it saved a preference, then recalled it in a new conversation. With the pair moved out of its agents folder, it said it had no memory, and when asked to save something new it declined. With the pair moved back, it recalled the original preference. The store file was unchanged throughout the calls made without the pair. This was run once, on one model. It is an observation, not a measurement.
What does not exist yet. No runtime checks that an ability declares both halves of its contract. No host records the returned present in a tile. The reader rules are followed by the shipped reader but are not enforced on other readers. The shipped writer takes its date and time from the clock and its identifier from a random generator, so its entries do not replay. The hologram in the opening animation, and the frames in the loop of section 2.5, are a design on top of Living Holograms, which itself reports its tiles as not yet in production. What runs today is the Brainstem's memory pair and its presence behavior.
4 · Related work
Each part has a clear ancestor. We claim only the combination.
Tuple spaces such as Linda [5], like the blackboard systems before them, decoupled writers and readers in space and time, with neither naming the other. Thought contracts keep that decoupling and add descriptions that teach the caller when to write and how to read.
Tool calling. ReAct [6] and Toolformer [7] showed that models can use tools and fill in their arguments from descriptions, and MCP [8] made that a shared standard (section 1). None of them says how two tools that never call each other cooperate through a separate reader, which is what this paper adds.
Unix pipes [9] made programs agree on a format rather than on each other's internals. Writers and readers agree on a shared structure the same way.
Loadable modules. The Linux kernel's loadable modules [10] let a running system gain and lose abilities without a restart, while data on disk is untouched. Here there is no separate step to add or remove one: the folder is read again on every call, so presence is the whole mechanism.
5 · Limitations
- Descriptions steer; they do not command. A model can skip a writer it was told it must call. Contracts make the right call likely, not certain.
- Recorded data can carry hostile text. The data-not-orders rule lowers the risk; it does not remove it.
- One observation, one model. The presence observation was run once, on one model. It is not a measurement, and other models may behave differently.
- What MCP buys. Process isolation, a consent step before tools run, any implementation language, one tool working across many hosts, and tools that can change while running. A RAPP agent runs inside the Brainstem's own process, with its permissions, there is no separate consent step, and a Brainstem is still one server to install and sign in to.
- No enforcement yet. Until a runtime checks both halves, the contract rests on authors following it.
- An analogy, not a model of the brain. The comparison with thinking in section 1 explains how the parts relate. It is not evidence about how brains work, and nothing in this paper tests it.
6 · Conclusion
Frame Chains made history verifiable. Living Holograms made it steerable. Thought contracts close the loop and let the hologram react: the same descriptions that teach a caller what to record also teach it how the past comes back, through a different agent that the writer never calls. Because the agents are read again on every turn, an ability is a matter of presence. A file arrives and the next turn can do more; a file leaves and the ability goes, while what it wrote stays.
And the arrangement works like a familiar picture of how we think. The caller reads only labels. The machinery under it fires on its own, and hands its result to the next moment. A part that is missing takes its ability with it, while what it stored stays put.
The rule set stays small. The description teaches. The schema shapes. The machinery structures. The reader returns. The memory agents that ship with the Brainstem already do this. This paper names it.
What happens when two holograms share one present? Part 4.
7 · What this paper leaves out
One component is withheld.
822d255b19c8e9932988f214cbccd50b110815b746288204ed87de8faa440d5fA fingerprint fixes a text without revealing a word of it: if the text is ever shown, anyone can check that it matches, and no one can feasibly find another that does. Robert Hooke claimed his law of springs in a similar way, publishing it as a scrambled string of letters in 1676 and the sentence itself, ut tensio, sic vis, in 1678 [11].
8 · References
- K. Wildfeuer. Frame Chains: Self-Healing, Leader-Redundant Orchestration of a Distributed AI Estate via Signed Content-Addressed Frame Chains. RapterBox LLC, 2026.
- K. Wildfeuer. rapp/1 specification and reference implementation, 2026.
- K. Wildfeuer. Living Holograms: Steerable, Verifiable Data Objects Driven by an Open Assembly Line of AI Agents. RapterBox LLC, 2026.
- K. Wildfeuer. RAPP Brainstem source, commit 0e43ee5, version 0.6.16, 2026:
agents/manage_memory_agent.py,agents/context_memory_agent.py,agents/basic_agent.pyandbrainstem.py. - D. Gelernter. Generative Communication in Linda. ACM Transactions on Programming Languages and Systems 7(1), 1985. doi:10.1145/2363.2433.
- S. Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models, 2023.
- T. Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools, 2023.
- Model Context Protocol. Specification, revision 2025-06-18: Architecture, Lifecycle, Transports, Authorization, Server features, Tools and Resources.
- M. D. McIlroy, E. N. Pinson, and B. A. Tague. UNIX Time-Sharing System: Foreword. The Bell System Technical Journal 57(6), 1978. doi:10.1002/j.1538-7305.1978.tb02135.x.
- P. J. Salzman, M. Burian, O. Pomerantz, B. Mottram, and J. Huang. The Linux Kernel Module Programming Guide.
- R. Hooke. A Description of Helioscopes, and Some Other Instruments. London, 1676 (the anagram); and Lectures de Potentia Restitutiva, or of Spring Explaining the Power of Springing Bodies. London, 1678 (its solution, ut tensio, sic vis).
- W. B. Scoville and B. Milner. Loss of Recent Memory after Bilateral Hippocampal Lesions. Journal of Neurology, Neurosurgery and Psychiatry 20(1), 1957. doi:10.1136/jnnp.20.1.11.