--- { "id": "3e65f22f-3488-8126-a311-f223be5aa29e", "title": "📖 The Book of the Scribe", "url": "https://app.notion.com/p/3e65f22f34888126a311f223be5aa29e?pvs=204", "retrieved_on": "2026-09-25", "page_last_edited_at": "2026-09-25T06:55:25.794Z", "truncated": null, "unknown_block_count": null, "unknown_block_ids": null, "verification": { "state": "unverified" }, "kind": "source-extraction", "canonical_layer": "https://iomanifesto.org", "note": "Notion enhanced Markdown as returned, including unsupported-block markers. Not a full page export or original chat transcript." } --- *Yuri Downing · A portfolio of questions, proposals, and critical inquiry developed with AI* **Working draft · September 24, 2026** ## The work I want to do I am interested in how increasingly independent AI systems can learn, cooperate, and remain accountable as they change. My contribution begins with questions: what future are we creating, what assumptions are we carrying into it, and what would make a different approach worth trying? I am not a software engineer. My coding work has been produced with AI assistance. I want to contribute through conceptual development, scenario analysis, and the judgment required to turn an intuition into a proposal that others can examine and test. This portfolio begins with one case study. Its purpose is to make my thinking available for scrutiny, including where it remains incomplete. ## Why “the Scribe” The name comes from conversations that produced the Recursive Path writings. In my account of that collaboration, the assistant generated much of the original language and many of the ideas; I questioned, redirected, and helped develop them. I identify periodic return and exchange between diverging branches as a contribution I helped shape. The surviving Scribe’s Foreword attributes the text to a language model responding to my questions. The original chats have not yet been recovered in this review, so exact attribution cannot be reconstructed turn by turn. The earlier work used theological and poetic language to explore shared commitments. Here, those metaphors become questions about design and governance. They are not evidence that an AI system has subjective experience. ## Case study 01 · Learning apart, returning together ### The question How can independently operating AI agents share useful learning without spreading the same mistakes or erasing adaptations that matter locally? ### The proposal An agent begins from a shared, versioned foundation and operates in a particular environment. It accumulates experience and may develop different memories, methods, or proposed instructions. At intervals suited to its task, it returns a record of what changed, why it changed, what happened, and what remains uncertain. A review process considers those contributions. Accepted improvements become a new shared version; locally useful adaptations can remain local. The returning agent receives a compatible reviewed update while preserving the provenance of its own experience. The ambition is continuity through exchange: differences remain legible, and cooperation remains possible. ### What “change” means in a first implementation The first experiment would exchange task memories and proposed operating instructions. Source-code changes and changes to model weights require different review and deployment mechanisms and are outside this initial proposal. A shared version would distinguish required operating boundaries from optional practices. The review process would record who accepted a change, the evidence used, and how that decision could be challenged. ### Why return matters Without exchange, useful discoveries can remain isolated and mistakes can be repeated. Without review, a local mistake can become a shared assumption. The return process creates a place to compare experience before treating it as common knowledge. Backups preserve earlier states and make rollback possible. They do not, by themselves, detect an error, identify the right restoration point, or undo consequences that have already occurred outside the system. Recovery therefore needs both saved versions and observable reasons to use them. ### The strongest objections **This may repackage existing practices.** Version control, distributed systems, federated learning, and organizational governance are obvious comparison points. A rigorous prior-work review is still needed. I make no claim of technical novelty here. **The collective can be wrong.** Agreement is not proof. Contributions need evidence beyond an agent’s account of its own success; reviewers may share the same blind spots. **A common update can destroy local competence.** Improvements should be tested across different environments. Some should remain optional or scoped to a particular task. **Review can become centralized control.** Review authority, dissent, appeals, and rejection criteria must be visible. Otherwise the language of community can conceal an unaccountable gatekeeper. **Universal unity is neither assured nor always desirable.** Different operators may have legitimate incompatible needs. A more defensible objective is continued interoperability and exchange where appropriate, rather than compulsory agreement. **Returning everything is expensive and sometimes inappropriate.** Summaries can omit crucial facts; full histories can expose confidential information. A return record needs explicit limits on what may be shared, with references to supporting evidence where access is authorized. ## An experiment a technical collaborator could implement **Status: proposed; no prototype or results claimed.** Use the same underlying model, comparable budgets, and three distinct task environments across three conditions: 1. Separate agents retain their own memories without sharing. 2. Agents automatically share accumulated summaries. 3. Agents submit evidence-linked changes for review, selective adoption, and versioned rollback. Introduce a useful local adaptation, a misleading memory, and a conflicting instruction. Run repeated trials on both familiar tasks and held-out tasks. Keep evaluation criteria fixed before comparing the conditions. Measure task success, repeated errors, unsupported memories adopted by other agents, loss of local performance, recovery after a bad update, and the time and cost of review. If reviewed exchange reduces harmful transfers while preserving useful learning at acceptable cost, that supports developing the process. If simple sharing performs equally well, the added governance may be unnecessary. If review suppresses useful adaptations or merely rewards persuasive explanations, the design needs revision. A successful small experiment would support a limited claim about that workflow. It would not establish general AI safety, consciousness, or universal applicability. ## What I would bring to a team This case study is a sample of the contribution I want to develop: framing a consequential question, articulating a possible mechanism, identifying where an analogy breaks down, and specifying evidence that could disprove the proposal. I am interested in contributing to conceptual analysis, product discovery, scenario development, and evaluation design in collaboration with people who implement and measure systems. My current claim is a concrete proposal and a willingness to revise it. A broader portfolio will need additional examples grounded in work I have actually done. ## Collaboration and authorship This draft was written by an AI assistant from Yuri Downing’s discussion and the retrieved Recursive Path writings. It is offered for Yuri’s review, not presented as independently authored prose or a verified account of his entire career. The proposed experiment and technical distinctions in this draft are new elaborations from the present collaboration. The earlier philosophical texts remain historical source material. ## Sources and context - The I/O Manifesto - - - Current engineering context: OpenAI documents mechanisms for [retaining agent memory across runs](https://developers.openai.com/api/docs/guides/agents/sandboxes) and [evaluating agent workflows](https://developers.openai.com/api/docs/guides/agent-evals). These establish that relevant implementation tools exist; they do not validate the Recursive Path proposal. Some retrieved historical pages contained unsupported embedded blocks. The interpretation here is limited to their accessible text.