--- title: Tapestry description: A White Paper on Persistent Machine Cognition for Software Engineering created: 2026-09-10 updated: 2026-09-21 authors: ThinkingCap R&D topics: [Tapestry] status: published canonical: https://console.thinkingcap.com/rd/Tapestry/Tapestry-Overview date: 2026-09-10 --- # Tapestry A White Paper on Persistent Machine Cognition for Software Engineering Thinking Cap R&D September 2026 Status: Working White Paper ## Abstract Software engineering is undergoing a strange inversion. For most of the history of software, code was expensive and cognition was cheap. A person could understand a system faster than they could change it. The limiting factor was the labor required to translate intent into implementation. Generative AI is reversing that relationship. Code can now be produced, transformed, reviewed and tested at extraordinary speed. The new scarcity is not typing. It is not syntax. It is not even access to intelligence. The scarce resource is coherent understanding over time. Large language models are powerful but episodic. Repositories are durable but largely non-semantic. Issue trackers record fragments. Documentation drifts. Chat histories disappear into transcripts. Decisions lose their reasons. Agents repeatedly rediscover the same facts. Context is rebuilt, compressed, discarded and rebuilt again. Tapestry is our attempt to solve that problem. Tapestry is a persistent cognition layer for software systems. It observes work, accumulates durable knowledge, preserves the relationship between decisions and evidence, and makes that understanding available to humans and machines across time. It is not another coding agent. It is not a chat history. It is not a vector database wrapped around a repository. It is not an autonomous swarm. Tapestry exists above individual models and below the organization. It is the fabric in which the evolving understanding of a system lives. Its central premise is simple: The repository owns the code. Tapestry owns the cognition. ## 1. Why We Built It Thinking Cap has been building software for more than twenty years. During that time, the mechanics of software development have changed repeatedly. Languages changed. Frameworks changed. Infrastructure changed. Development methodologies changed. Cloud computing changed the unit of deployment. APIs changed the unit of integration. AI is changing something more fundamental: the unit of cognition. A capable engineer can now sit beside a model and produce more software than either could have produced alone. As models improve, the amount of code that can be created by a very small team grows dramatically. That sounds like a software production problem. We think it is actually an understanding problem. When production accelerates, the cost of forgetting accelerates with it. A model entering a repository for the first time does not know why a particular architecture exists. It does not know which ugly-looking code is intentionally ugly. It does not know which migration failed three months ago. It does not know that a particular constraint came from a customer incident, a regulatory obligation or a decision that took three weeks to reach. The code contains some of this history. Git contains some. Tickets contain some. People contain a great deal. But there is no durable computational object that represents what the organization currently understands about the system. Tapestry is intended to become that object. ## 2. The Missing Layer in AI Software Development Most AI development systems are organized around a short-lived interaction: A human provides a task. An agent gathers context. The model reasons. Tools are invoked. Code changes. The session ends. The next session begins largely from scratch. Even systems that provide memory tend to treat memory as an accessory to the conversation. The conversation remains the primary object and memory exists to help reconstruct it. Tapestry reverses this. The fabric is primary. Conversation is only one projection of it. A discussion, implementation, failure, decision, test result, architectural concern or discovery can all become knowledge attached to the system itself. The important thing is not that an AI remembers a chat. The important thing is that the organization retains what was learned. ## 3. Repository Sovereignty and Cognitive Sovereignty Tapestry begins with a strict separation of authority. The repository owns implementation Code is sovereign with respect to what the software actually does. The repository contains the executable truth. Tapestry must never become a competing source of implementation truth. If Tapestry believes one thing and the code demonstrates another, Tapestry is wrong. Tapestry owns accumulated understanding Tapestry records what is believed about the system: architectural decisions constraints dependencies concerns discovered behavior unresolved questions failed approaches implementation intent evidence drift future work relationships between these things This distinction matters because understanding and implementation evolve differently. Code is replaced. Understanding accumulates. A file deleted from Git may still represent an important historical experiment. A constraint discovered during an incident may remain relevant years after the code involved has disappeared. A decision can be superseded while the reason it once made sense remains valuable. Tapestry therefore treats cognition as its own durable substrate. ## 4. The Fabric The core object in Tapestry is the Fabric. The Fabric is not a document. It is not a single knowledge graph. It is not the model's context window. It is the durable collection of knowledge created as the organization works. Individual entries may represent different kinds of understanding: Decision We chose X rather than Y. Constraint This system must behave within boundary Z. Evidence A test, observation, trace, benchmark or artifact supports a claim. Concern Something appears unsafe, inefficient or conceptually weak. Dependency One part of the system relies on another condition remaining true. Open Question Something important is not yet known. Drift Finding Current implementation or understanding has diverged from what was previously believed. Future Work A possibility is intentionally captured without pretending it has been decided. These types are useful, but the deeper principle is that Tapestry should not prematurely freeze understanding into a rigid schema. A conventional knowledge system often begins by defining the ontology. Tapestry begins by preserving the cognition. Structure can be strengthened as repeated patterns reveal what deserves to become structural. ## 5. Projections, Not Documents One of the most important ideas in Tapestry is that many familiar interfaces should be treated as projections of the Fabric. A chat is a projection. A skill map is a projection. A project board is a projection. An architectural brief is a projection. A timeline is a projection. A repository overview is a projection. A "what do we currently believe about this subsystem?" page is a projection. This has a powerful consequence. The organization no longer needs to decide which document is the canonical document containing the truth. The durable knowledge is canonical. Documents are generated views of that knowledge for a particular purpose. This reduces a familiar failure mode in software organizations: creating increasingly elaborate documentation systems that become stale precisely because humans must manually keep them synchronized with reality. ## 6. Focus Is More Important Than Time Traditional collaboration tools are organized primarily by chronology. What happened yesterday? What happened in this meeting? What was the latest message? Chronology is useful, but cognition is rarely organized that way. When an engineer asks about an authentication failure, the useful knowledge may have been created: six months ago during an incident, yesterday during a refactor, three years ago during an architectural migration, and ten minutes ago during a test. The meaningful organizing principle is focus. Focus means the thing currently being reasoned about. A repository. A subsystem. A client. A feature. A capability. A decision. A failure. A concept. The timeline still exists, but time becomes a dimension of the object rather than the primary container for it. This allows Tapestry to answer a more useful question: What does the organization know about this thing? rather than merely: What was said recently? ## 7. Tally: Thinking About Thinking Tapestry is assisted by Tally. If Tapestry is the persistent cognitive substrate, Tally is concerned with the quality of the reasoning entering and moving through it. Tally can examine prompts, context, evidence and outcomes. It can ask whether an agent received the information it needed, whether a reasoning path was effective, whether the wrong context was supplied, or whether a repeated failure reveals a deeper problem in the system's understanding. This matters because simply storing everything would produce a landfill. The goal is not infinite memory. The goal is useful cognition. Over time, Tally can help the system learn which context matters for which kinds of work, how much context is sufficient, which sources are trustworthy, and where reasoning routinely fails. The result is a feedback loop: work produces knowledge → knowledge improves context → improved context improves work → outcomes refine the knowledge. ## 8. Deterministic Software First Tapestry is built on a conviction that becomes more important as models become more capable: Use AI where judgment is required. Use deterministic software everywhere else. A language model is extraordinarily good at interpreting ambiguity. It is an unnecessarily expensive and unreliable way to perform a calculation that ordinary software already knows how to perform exactly. So the first stage in many Tapestry-driven systems is interpretation: What does this person want? Once intent has been understood, the system should decompose the request into deterministic operations wherever possible. A model may determine that a user wants: "Show me everybody who completed this course last quarter, group them by region and explain anything unusual." The interpretation may require language understanding. But date calculation, authorization, querying, aggregation, sorting and report generation need not require a frontier model. The resulting pattern is: language → intent → deterministic operations → selective reasoning → presentation This is fundamentally different from asking one model to perform the entire task inside its context window. ## 9. Models Are Workers, Not the Architecture Tapestry deliberately avoids making a particular model the center of the system. Models improve quickly. Their strengths differ. Their costs differ. Their context windows differ. Their failure modes differ. Therefore Tapestry treats models as replaceable cognitive workers. A difficult architectural question may deserve the strongest available reasoning model. A classification task may not. A large repository read may be delegated to a cheaper model. A deterministic service may make a model unnecessary. Generated boilerplate may be written directly to disk without requiring the expensive reasoning model to consume its own output. This philosophy is increasingly visible in the broader engineering world. Spotify recently described routing bulk reading and predictable code generation away from an expensive reasoning model, including writing generated code directly to disk so the primary model does not need to consume the output. The important lesson is not the particular implementation. It is the architectural idea: reasoning is a resource that should be allocated intentionally. Tapestry takes that idea further. Model routing should eventually be driven by accumulated knowledge about the task, the system, the model and previous outcomes. ## 10. Context Is Infrastructure For years, software organizations invested heavily in runtime infrastructure: databases networks deployment pipelines observability security caching APIs Agentic software introduces another infrastructure problem: context. What should this agent know? Where should the information come from? How fresh must it be? What can be omitted? Which knowledge is relevant to this task? Which assumptions were invalidated yesterday? Which apparent facts came from speculation rather than evidence? The naive answer is to give the model everything. That does not scale. Context consumes money, attention and reasoning capacity. Irrelevant context can actively degrade performance. Tapestry treats context construction as an engineering discipline. The eventual objective is not a giant prompt. It is the smallest sufficient context for the work being performed. ## 11. Evidence Matters More Than Confidence Language models are capable of producing extraordinarily convincing explanations. Convincing is not the same as correct. Tapestry therefore prefers observable evidence to narrative confidence. A claim about the repository should point toward repository evidence. A claim that work advanced should have an observable artifact. A claim that a behavior was fixed should have verification. A conclusion may be uncertain and still useful, provided its uncertainty is visible. This produces an important epistemic distinction: Absence of observable progress does not prove that no thinking occurred. It means the system cannot establish that progress occurred. That distinction shapes how Tapestry supervises agents. The system should ask for evidence rather than pretending it can inspect a model's internal cognition. ## 12. Humans Remain Part of the System Tapestry is not built around replacing humans with autonomous agents. It is built around allowing humans and machines to share a persistent body of understanding. Humans contribute things models often lack: organizational intent taste accountability political understanding lived experience risk judgment strategic prioritization Models contribute: enormous reading capacity synthesis pattern recognition tireless exploration rapid generation the ability to operate many cognitive threads simultaneously Deterministic systems contribute: repeatability enforcement speed precision authority over mutation Tapestry is the layer that allows these three forms of capability to cooperate without pretending they are interchangeable. ## 13. From Tools to Capabilities Traditional software interfaces expose tools. An API might contain 200 operations. A human does not want 200 operations. They want an outcome. This is why Tapestry increasingly thinks in terms of capabilities and jobs rather than interfaces. The user asks for something. The system interprets the desired outcome. It determines what capabilities are required. Those capabilities may invoke: deterministic APIs CLIs workers databases models external systems human review The interface presented to the user can remain simple even as the system underneath becomes more capable. This is also why Tapestry does not regard MCP, APIs or CLIs as competing ideas. They occupy different layers. A human may negotiate intent through a conversational interface. An agent may use MCP to discover capabilities. A machine may submit a job directly through an API or CLI. The substrate underneath can remain deterministic. ## 14. Software That Can Observe Its Own Development The long-term implication of Tapestry is more interesting than persistent memory. Once a system contains: its implementation, the history of important decisions, evidence about outcomes, observed failures, known constraints, unresolved questions, and the reasoning used to change it, the software organization gains the beginnings of a self-observing development system. Not self-aware. Not magical. Simply instrumented at the cognitive layer. Today we instrument CPU, latency, errors and network traffic. Tapestry asks whether we can also instrument: misunderstanding, uncertainty, architectural drift, repeated reasoning failures, missing context, knowledge decay, duplicated investigation, and the effectiveness of interventions. That would allow software development itself to become observable. ## 15. Why This Matters for Small Teams AI dramatically changes the economics of software organizations. A very small number of exceptional people can already produce systems that once required much larger teams. But this creates a paradox. As the number of humans decreases, organizational memory does not become less important. It becomes more important. A ten-person company cannot afford to rediscover what one person already learned. A machine performing hundreds of tasks cannot be allowed to rediscover the same architecture hundreds of times. If software production becomes abundant, continuity of understanding becomes one of the primary sources of leverage. Tapestry is intended to preserve that continuity. ## 16. Tapestry and Thinking Cap Tapestry was born inside Thinking Cap, an education technology company, but its purpose is broader than the LMS. In some ways, the connection is natural. Learning systems have always tried to answer questions such as: What does someone know? What evidence supports that belief? What changed? What intervention caused the change? Can knowledge transfer to a new situation? Where is uncertainty located? Tapestry applies similar questions to software organizations. What does the organization know? Why does it believe it? Where did that knowledge come from? What changed? What evidence demonstrates it? Which assumptions are no longer valid? What should the next agent know before acting? The underlying problem is surprisingly similar. Both are problems of persistent, evidence-grounded change in understanding. ## 17. What Tapestry Is Not The easiest way to misunderstand Tapestry is to map it onto an existing category. It is not a replacement for Git. It is not a replacement for an issue tracker. It is not documentation software. It is not an AI IDE. It is not a multi-agent framework. It is not a chat application. It is not simply RAG. It can interact with all of these things. But its responsibility is different. Its responsibility is to preserve and operationalize the evolving cognition around a system. ## 18. The Direction of Travel Tapestry is still evolving. Some of its most important ideas remain intentionally unfrozen. That is deliberate. We are more interested in discovering the right primitives than rapidly reproducing the familiar architecture of existing AI development tools. The direction, however, is clear. We expect Tapestry to increasingly provide: persistent semantic memory across repositories and projects, focus-based navigation through organizational knowledge, automatically constructed context for agents, reasoning and prompt evaluation through Tally, evidence-backed architectural understanding, detection of drift between belief and implementation, deterministic orchestration wherever AI is unnecessary, model routing based on task requirements, generated projections of the Fabric for different users and purposes, and an increasingly observable feedback loop between intent, reasoning, execution and outcome. ## 19. The Bet The current generation of AI tools is mostly trying to build better agents. We think the more important problem may be building a better environment for intelligence. Models will change. Agents will change. Interfaces will change. The context windows will get larger. The reasoning will get better. The cost will fall. But organizations will still need continuity. They will still need evidence. They will still need deterministic authority. They will still need to understand why their systems became what they are. And they will increasingly need humans and machines to inherit that understanding from one another. That is the bet behind Tapestry. Code is the executable artifact. The Fabric is the accumulated understanding. Tapestry connects the two. ## Notes on the R&D Philosophy Thinking Cap is publishing this work because we believe engineering improves when unfinished ideas are exposed to scrutiny. This is a research and development area, not a catalogue of finished product claims. Some ideas described here are already implemented. Some are actively being tested. Some are architectural directions that may change as we learn. That distinction is intentional. The purpose of an R&D space is not to prove that we already know the answer. It is to show the questions we think are worth pursuing. ## Related Thinking The broader engineering industry is beginning to encounter many of the same pressures that motivated Tapestry. Spotify Engineering has recently written about coding no longer being the primary constraint, about internal platforms becoming useful to both humans and agents, and about routing predictable AI work away from expensive reasoning models. Those examples are interesting to us not because Tapestry is modeled on Spotify's systems, but because independent teams are beginning to identify the same shift: when code becomes cheap, the architecture around reasoning, context, evidence and decision-making becomes the new engineering problem.