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.

Part 3 of Frame Chains → Living Holograms → Thought Contracts.

Kody Wildfeuer · RapterBox LLC · First public disclosure: 2026-10-22

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.

A living hologram reshapes as agent files arrive and leave. What is in the folder, it can do; take a file away, and it can't. The next turn is already different.

The short version

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 BrainstemWorks like
An agent fileA reflex that fires when stimulated
The caller, reading descriptionsA deliberate choice, made over labels, never over the machinery
perform() and the readerInvoluntary machinery that fires underneath and hands its result to the next moment
The shared storeA trace left for later
Taking the memory pair outA lesion: the parts are gone, so the ability is gone, while what was stored stays
Like a deliberate choice, the caller reads only the labels. It never sees what is inside a tool.

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.

Two shapes for one idea. In MCP, an ability is a server process plus a session. In RAPP, it is a file in a folder.

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.

  1. 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].
  2. 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.
  3. 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).
  4. 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 its perform() 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:

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.

The writer and the reader never touch. They share one store, and that is all.

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.

Like a lesion: take the pair out and the light goes dark, but the store stays full. Put it back and it remembers.

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.

Present, caller, writer, frame, reader, and back to the present. Each lap is one thought, and each leaves a record.

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).

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

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.

Sealed description. SHA-256 of the sealed description, held by RapterBox LLC since 22 October 2026:
822d255b19c8e9932988f214cbccd50b110815b746288204ed87de8faa440d5f
A 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

  1. K. Wildfeuer. Frame Chains: Self-Healing, Leader-Redundant Orchestration of a Distributed AI Estate via Signed Content-Addressed Frame Chains. RapterBox LLC, 2026.
  2. K. Wildfeuer. rapp/1 specification and reference implementation, 2026.
  3. K. Wildfeuer. Living Holograms: Steerable, Verifiable Data Objects Driven by an Open Assembly Line of AI Agents. RapterBox LLC, 2026.
  4. 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.py and brainstem.py.
  5. D. Gelernter. Generative Communication in Linda. ACM Transactions on Programming Languages and Systems 7(1), 1985. doi:10.1145/2363.2433.
  6. S. Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models, 2023.
  7. T. Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools, 2023.
  8. Model Context Protocol. Specification, revision 2025-06-18: Architecture, Lifecycle, Transports, Authorization, Server features, Tools and Resources.
  9. 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.
  10. P. J. Salzman, M. Burian, O. Pomerantz, B. Mottram, and J. Huang. The Linux Kernel Module Programming Guide.
  11. 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).
  12. 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.