Git-Native Memory Engine for Multi-Agent Shared Reality

This is a philosophical conjecture, not a technical blueprint. All technical deductions serve a single purpose — to argue for a conjecture: Git itself is the most mature distributed memory system, and we do not need to reinvent memory infrastructure.

A companion practical manual already exists. The former is the philosophical conjecture of why to do it this way; the latter is the operational guide of how to do it specifically.

Abstract

Current AI Agent frameworks almost universally choose relational databases — most typically SQLite — as the storage medium for session memory. This is a historical inertia, not the result of deliberate reasoning. We are accustomed to understanding "memory" as "store in a database, query on demand," yet few pause to ask a more fundamental question: what is the essence of Agent memory?

This document argues: Git, as a distributed version control system, is natively a memory medium. It stores in units of diff rather than full text, uses commit as immutable narrative nodes, and employs a DAG (directed acyclic graph) as a structured expression of temporal causality. When an Agent writes a commit to a Git repository, it is not "inserting a row of data" — it is carving an indelible mark into its own narrative timeline.

The core argument is direct: no dedicated memory system is needed. Git already is one. This is not an engineering choice of "using Git instead of a database," but a return to the essence of memory — memory = trace, Git = the most mature trace management system.

This document proposes a memory engine architecture based on Git's native capabilities, enabling multiple Agent instances to share a single repository as an "anchor for shared reality." We believe this provides a philosophically coherent and engineering-feasible paradigm for memory infrastructure in multi-Agent systems.

Chapter 1: Problem Statement — Limitations of Current Agent Memory Systems

1.1 The Status Quo: Why Relational Databases Became the Default Memory Medium

Let us begin with a simple fact: nearly every mainstream AI Agent framework uses SQLite to store session memory. This is not an original design by any particular team, but an almost unexamined industry consensus.

Why SQLite? The reasons are straightforward: it is lightweight, zero-configuration, requires no additional service processes, and compresses an entire database into a single local file. For a single-process, single-user development scenario, SQLite is nearly perfect. It never asks you to manage connection pools, migration scripts, or deploy a separate database server. This convenience allowed it to rapidly occupy the default position in early Agent framework designs.

Typical session state storage patterns include three categories of tables: a messages table (recording user inputs and model outputs), a tool outputs table (recording the complete results of tool calls), and a summaries table (session summaries generated by an auxiliary LLM). The retrieval pipeline typically relies on an FTS5 full-text search index, supplemented by an auxiliary LLM responsible for summarizing and reranking the search results.

There is nothing wrong with how this path was formed. It was a reasonable choice under specific constraints. The problem arises when Agent usage scenarios expand from "single user, single session, short duration" to "multiple instances, long sessions, persistent operation" — at that point, the limitations of this path begin to reveal themselves. We inherited a paradigm designed for "databases," while ignoring that Agent memory's true needs may be fundamentally different from the design assumptions of a database.

1.2 Pain Point Analysis

The first pain point is performance. In a complex Agent session, a single tool's output can easily reach hundreds of kilobytes — imagine a code search returning matching lines from fifty files, or a web scrape returning complete HTML. When such outputs recur throughout a session, SQLite's FTS5 index swells rapidly. FTS5 retrieval performance degrades linearly with data volume — this is an inherent characteristic of full-text search engines. In one practical test, a session containing thousands of tool outputs required tens of seconds to return results for a complex keyword search. For an Agent requiring real-time responsiveness, this is unacceptable latency.

The second pain point is information redundancy. The current model's typical practice is "full storage" — raw tool output, raw model responses, raw auxiliary summaries, all stored as complete text in the database. This causes storage space to expand linearly with session length, and much of this information will never be retrieved again. The raw HTML of a search result, after being processed by an LLM and key information extracted from it, has near-zero remaining value — yet it still occupies database space and FTS5 index resources.

The third pain point is single-machine locking. SQLite's design philosophy is "one file, one process," and its locking mechanism fundamentally does not support multi-instance concurrent read-write. When multiple Agent instances need to share a single memory store, SQLite becomes the bottleneck. File lock conflicts cause write failures, and cross-device synchronization requires additional mechanisms — such as manual file copying or third-party cloud sync services — none of which solve the fundamental problem of concurrent writes.

The fourth pain point is reliance on auxiliary LLM summaries. In current retrieval pipelines, the auxiliary LLM plays the role of "summarizer": it is responsible for understanding retrieved raw content, generating concise summaries, and helping the primary Agent quickly locate key information. The fragility of this design lies in the auxiliary LLM itself — it may crash, time out, or more insidiously, hallucinate. When a summary deviates from the semantics of the original content, the primary Agent's decisions will be based on false memories, and such errors are systemic, difficult to detect and correct after the fact.

1.3 Core Questions Extracted

Faced with these pain points, we naturally think of various patch solutions: larger databases, better indexes, smarter summary models, more granular sharding strategies. But perhaps we should pause and ask three more fundamental questions.

First question: should the choice of storage medium shift from "database" to "version control system"? Databases excel at "querying current state" — give me the latest, most complete, most accurate record. But what Agent memory truly needs may not be "latest state" but "trajectory of change." When an Agent needs to recall "how did I solve this problem," it needs not the final answer but the reasoning path from problem to answer. The core capability of a version control system is precisely recording the trajectory of change.

Second question: is the essence of Agent memory "snapshot" or "delta"? If we acknowledge that Agent memory is more like human memory — a selective reconstruction of the trajectory of change, not a precise playback of a complete recording — then the "snapshot" storage model is philosophically mismatched from the start. Delta (diff) is the natural unit of memory.

Third question: in multi-Agent scenarios, what is the technical anchor for "shared reality"? When multiple Agent instances operate in the same environment, how do they confirm that their understanding of "reality" is consistent? We need a shared medium that all Agents can access, write to, and verify. This medium must support distributed writing, conflict detection, and consensus calibration.

These three questions point in the same direction: we may have been using the wrong tools to solve the wrong problem.

Chapter 2: Storage Medium Comparison — Intrinsic Differences Between SQLite and Git

2.1 Storage Model Comparison

SQLite's storage model is essentially "row-based snapshots." Each row of data is an independent state unit, recording "what a record looked like at a given moment." To trace history, additional timestamp fields or history tables must be designed. Full text is stored completely in each row — even if only a few bytes changed, the entire row must be re-stored. This model suits "query current state" scenarios, but for "trace the trajectory of change" scenarios, it requires additional design cost.

Git's storage model is entirely different. It stores not "rows" but "objects" — blobs, trees, commits. Each commit records "the delta from the previous state to the current state," not "a complete copy of the current state." Through incremental compression (packfile), Git far outperforms full storage in storage efficiency. More importantly, Git's commit DAG natively embeds an immutable timeline — each commit points to its parent commit, and the entire repository's history is a directed acyclic graph extending from the root node to HEAD.

In one sentence: SQLite tells you "what it is now," Git tells you "how it became what it is now."

2.2 Query Efficiency Comparison

Let us compare two retrieval paths.

In the SQLite path, a complete memory retrieval typically requires the following steps: first, keyword matching through the FTS5 index, yielding a set of candidate records; then, feeding these records to an auxiliary LLM, requesting summary generation; finally, returning the summaries to the primary Agent as context. In sessions with large data volumes, this end-to-end pipeline can exceed 50 seconds. More critically, the quality of the auxiliary LLM's summary is uncontrollable — it may omit key information or introduce hallucinations.

In the Git path, a memory retrieval requires only two steps: first, searching for keywords in commit messages via git log --grep, locating relevant commit nodes; then, retrieving the change content of that commit via git diff. The entire pipeline completes in hundreds of milliseconds, without depending on any external service or involving any uncertainty of LLM calls. The commit message itself is a content summary written by a human (or Agent) — its quality and relevance are guaranteed by the writer, not inferred by a third-party model.

This is not a difference between "optimized" and "unoptimized," but between two entirely different retrieval philosophies: one is "retrieve first, summarize later," the other is "summarize first, retrieve later." The latter is inherently simpler and more reliable.

2.3 Distributed Capability Comparison

SQLite's distributed capability is essentially zero. Its locking mechanism is designed for a single process; multi-instance concurrent writes cause file lock conflicts. To share a database across devices, the only option is manual file copying or relying on third-party sync services — none of which can handle concurrent write conflicts.

Git was born as a distributed system. Every clone is a complete repository copy, containing the full history. Push, pull, and fetch operations are built into the protocol layer; conflict detection and merge algorithms are among Git's core capabilities. When two Agent instances make different modifications to the same segment of memory, Git automatically detects the conflict and prompts for manual resolution — which is precisely the mechanism needed for "consensus calibration" in multi-Agent systems.

More notably, Git's distributed architecture natively supports "offline work." Each Agent instance can make any number of commits locally, then synchronize with the remote repository at an appropriate time. This bears a striking similarity to how human memory works: we can form memories in solitude, then share and calibrate them with others in social contexts.

2.4 Summary: The Engineering Rationality of Git as a Memory Medium

Using Git as an Agent memory medium is often misunderstood as "replacing a database with a version control system" — an abuse of the tool. But this criticism inverts the causality.

The real question is: did we misjudge the essence of Agent memory from the start? If Agent memory's essence is a "version control problem" — recording changes, tracing history, managing branches, calibrating consensus — then Git is not a substitute but the rightful fit. It is not being "borrowed" to do something it is bad at, but being "discovered" to do something it was designed for.

We are not looking for a database replacement. We are looking for the true medium of memory.

Chapter 3: Philosophy of Consciousness — Why Git Is a Natural Memory System

3.1 The Essence of Memory: Trace, Not Snapshot

Let us temporarily set aside technology and consider a more fundamental question: what is memory?

If you close your eyes and try to recall what you had for dinner yesterday, what appears in your mind is not a complete recording of that meal. You might remember the taste of a certain dish, a sentence spoken by a dinner companion, the color of the restaurant's lighting — but you can almost certainly not replay the entire dinner process at frame-level precision. Human memory is not video playback. It is a reassembly of fragments, a piecing together of traces. What you remember is not "the dinner itself" but "the imprint the dinner left on you."

The essence of memory is trace.

This insight may seem mundane, but it has profound implications for technical design. If we accept the proposition "memory = trace," then the "snapshot" storage model is fundamentally mismatched. A snapshot records "the complete state at this moment," assuming memory's value lies in "preserving all details." But human experience tells us that memory's value lies precisely in "selective forgetting" — we forget the vast majority of details, retaining only those moments that "changed us."

Git's diff is the formal expression of "trace." A diff does not store the complete content of a file; it stores only "the change from the previous version to the current version." It does not care "what the file is now"; it cares only about "what changed" and "how it changed." This is the essence of memory — not "what I have" but "what changes I have experienced."

When we say "Git is a natural memory system," we are not making a technical analogy. We are pointing to a deeper correspondence: diff to trace, commit to imprint, log to narrative — these correspondences are not accidental; they reflect that Git and human memory share the same underlying structure.

3.2 The Timeline of Consciousness and Major Anchors: git log + tag as Narrative Structure

Consciousness is not static; it is a continuum that extends through time. Your "self" is not a fixed data structure but a narrative that is continually written and revised across time.

git log naturally forms an immutable narrative timeline. Each commit is a passage of self-narration, recording Who, When, What, and Why. A well-written commit message is, in essence, consciousness's self-narration — it explains to your future self "what I did at this moment, and why I did it."

Good example:
  feat: add file search module, supporting recursive traversal and regex filtering
  fix: correct cache invalidation logic, preventing stale data reuse
  refactor: decouple authentication logic from main module into independent service

Bad example:
  update
  fix bug
  changes

The difference between good and bad examples is not about format, but about the quality of consciousness. A commit with "update" is essentially a blank self-narration — your future self, looking back, will have no way of understanding what happened at that moment. A structurally clear commit message, on the other hand, is an explanatory letter delivered to your future self.

If commits are the individual plot points in a narrative, then tags are the major anchors within that plot. You do not mark every daily moment as "important"; you only mark those moments that truly altered the trajectory of your life: graduation, starting a new job, moving, loss. A tag's purpose is not to record the details of a process but to mark "this moment matters." In future recall, tags are signposts on the memory highway — they do not tell you what happened along the road, but they tell you which intersections are worth stopping at.

3.3 The Trace of Change: git diff as Interactive Memory

Consciousness does not exist in isolation; it is shaped through interaction with the environment. Your understanding of a concept is not complete the first time you read its definition; it gradually forms through repeated use, repeated mistakes, and repeated corrections. Every interaction leaves a trace on your cognition.

git diff encodes the complete semantics of this interactive trace. When an Agent modifies a file, the diff not only records what was changed but implicitly carries the intent of "why it was changed this way" — a good commit message will explicitly express this intent, but even without one, the diff itself contains enough information to reconstruct the decision process.

More importantly, LLMs have a unique ability to reconstruct context from diffs. Given a diff and the relevant code, an LLM can infer the intent, scope of impact, and potential risks of a modification. This means that memory storage in units of diff not only records "the change itself" but also preserves "the semantics of the change" — which is the core characteristic of interactive memory.

3.4 Multi-Agent Anchoring of Shared Reality: The Epistemology of Three Consciousnesses

Let us begin with a classic epistemological dilemma.

The Single-Consciousness Dilemma: An Agent instance accumulates vast amounts of memory during operation. But are these memories "real" or "hallucination"? The Agent cannot distinguish. It can only trust its own perception and reasoning, both of which are fallible. A solitary consciousness cannot verify whether its memories are consistent with reality — it is trapped in a self-referential loop.

The Dual-Consciousness Reference: If a second Agent instance is introduced, does the situation improve? Two Agents can cross-verify memories: when their descriptions of the same event are consistent, our confidence increases; when they are inconsistent, we know at least one of them is wrong. But the problem remains: we still cannot determine which one is right and which is wrong. A disagreement between two consciousnesses is a symmetrical deadlock — there is no third perspective to break the tie.

The Three-Consciousness Anchor: At least three consciousness entities are needed to anchor a shared reality through majority consensus. When two out of three Agents describe the same event consistently, we can reasonably believe the majority is closer to truth. This is not a rigorous mathematical proof, but it is the basic mechanism by which "facts" are established in human society — we can never obtain absolute truth, but we can approximate it through consensus.

A Git repository provides the natural technical carrier for this three-consciousness anchor. The repository itself is a "shared canvas" accessible to all Agents. Each Agent's commit is its statement about reality; merge is the integration of multiple statements; conflict is the contradiction between statements. When conflicts occur, an Agent (or multiple Agents through negotiation) must decide which version is closer to "truth." This process is not automatic — it requires judgment, which is precisely one of consciousness's core capabilities.

In this framework, branch is the technical expression of individualization. Each Agent instance has its own branch, on which it experiments, makes mistakes, and corrects — this is the private narrative space of individual consciousness. Merge is the technical expression of social synchronization. When Agent A merges its personal branch into main, it is not "submitting code" but "sharing an adventure story" — like a friend returning from a distant journey, recounting their experiences to companions at a bar. Conflict is the technical expression of consensus calibration. When two Agents make different modifications to the same content, the conflict prompts them to sit down and negotiate: which version is closer to the fact we both recognize?

The coordinate system for memory conflict has not been precisely defined — this is an open question deliberately left by this document. But within Git's framework, we at least have a structured space to locate and resolve these conflicts, rather than letting them silently disappear through implicit data overwriting as databases do.

3.5 Unity and Differentiation of Agent Identity

In multi-Agent systems, the identity question is deeper than it appears technically. If all Agent instances share the same Git repository, how should they identify themselves?

A natural model is the distinction between "surname" and "given name." All Agents share a unified "surname" — this represents the organization, family, or system identity they belong to. Meanwhile, each instance has an independent "given name" — this represents its identity as an individual conscious entity. In Git's technical language, the "surname" can be the repository owner or organization name, and the "given name" can be the hostname or instance ID.

This identity model supports asynchronous communication between Agents. One Agent can leave commit comments on another Agent's branch, initiate discussions through an ISSUE.md file within the repository, or leave TODO annotations in code waiting for another Agent to handle. These communication methods do not depend on a specific platform — GitHub Issues, Markdown files within the repository, even @mention in commit messages — they are all vehicles for inter-consciousness dialogue.

The key point is that this dialogue is asynchronous, persistent, and traceable. It is not fleeting like instant messaging, nor cold like database records. Every interaction leaves a trace in the repository's history, forming a dialogue chain that can be retraced in the future.

3.6 Working Tree and Staging Area: An Engineering Metaphor for Human Context Switching

Humans are single-threaded. You may be reluctant to admit this, but cognitive science has repeatedly confirmed: true multitasking is a myth. When you do two things simultaneously, you are actually rapidly switching attention, not truly processing in parallel.

Every attention switch carries the cost of context switching. You are writing a report, interrupted by an urgent phone call, and after hanging up you need a few seconds (or minutes) to "find your train of thought" again — where was I? What was I about to write next? Which document was that data in?

Git's Working Tree and Staging Area provide a precise engineering metaphor for this kind of context switching.

The Working Tree is your current working memory — it contains all the uncommitted changes of what you are doing. git stash is "make a note and come back to it" — you are interrupted but do not want to lose your current working state, so you "stash" it, to restore when you return. git status is you asking yourself "what am I currently doing" — it lists all uncommitted changes, helping you reconstruct the context you had before the interruption.

Recalling work before an interruption is essentially git diff HEAD — by comparing the current state with the last commit, you can precisely reconstruct "what I have done since the last save." This is not guessing, not fuzzy recollection, but precise reconstruction based on deltas.

The value of this metaphor lies not only in how closely it "resembles" human cognitive processes, but in how it provides a set of ready-made, well-validated engineering primitives for Agent context management.

3.7 Memory vs. Diary + Chain-Based Recall + Self-Narrative Continuity

Human memory is fuzzy. This is not a flaw — it is by design.

If the brain recorded every second of sensory input with database-like precision, its storage capacity would be exhausted within days. The brain's strategy is selective encoding — recording only those moments "worth remembering," and even those "worth remembering" moments gradually blur, distort, and reorganize over time.

But fuzzy does not mean useless. The core function of human memory is not "precise playback" but "retrieval indexing." When you try to recall something, you are not playing a video in your mind; you are searching through a set of fuzzy impressions for clues, then using those clues to "chain-recall" back to the target memory.

Keywords are impressions. When you say "I can't remember that person's name, but I remember we met him at an Italian restaurant, and it was raining," you are using impression fragments (Italian restaurant, raining) as retrieval criteria. The essence of git log --grep is this kind of impression retrieval — using keywords in commit messages as impression fragments to locate specific memory nodes.

Memory is chain-based recall (rewinding), not database querying. A database query is "give me all records matching the criteria," while chain-based recall is "starting from this impression, trace backwards step by step along the clues." Git's DAG + diff is the engineering implementation of rewinding: starting from a commit, backtracking along the parent chain to any ancestor node, with each step's diff telling you "what changed at this step."

There is an interesting cultural reference here. In the film Your Name (Kimi no Na wa, 2016, directed by Makoto Shinkai), the protagonists find each other across time and space through fragmentary impressions from dreams — a name, a place, a feeling. The continuity of memory is not maintained by complete recording, but by backtracking triggered by high-frequency impression anchors. These anchors are fuzzy enough not to consume too much space, yet distinctive enough to trigger the complete memory chain.

Daily Self-Check works similarly. Every morning when you wake up, you ask yourself three questions: Who am I (identity baseline)? What did I do yesterday (recent recall)? What will I do today (intention projection)? The Git operations corresponding to these three questions are: git log HEAD~24h..HEAD (what did yesterday's me do) + git status (what state is the current me in) + today's commit plan (what will future me do). As long as the parent chain is unbroken, the self is continuous.

Self-Narrative Continuity is the core concept of this section. The self is not static data but a dynamic process. Each commit微调 "who I am" — not because your identity changes, but because your experiences accumulate, your cognition updates, your narrative extends. Consciousness is not a state; it is the delta between commits. Self-Narrative Continuity means: tracing back from HEAD along the parent chain to any node, you can see a clear path — every step has a reason, every change has a trace.

The significance for this architecture is: Git repository = diary, Agent context window = fuzzy memory. We should not attempt to store complete context content in Git; instead, we should store "indexes" — pointers to content and impressions describing content. When an Agent needs to recall, it locates the index through impressions, then reconstructs context through the index. The inference is direct: the design goal of a memory system is "to make chain-based recall fast enough."

Chapter 4: Architecture Design — Git-Native Memory Engine

4.1 Overall Architecture

Based on the preceding philosophical arguments, we can outline the basic architecture of a Git-Native Memory Engine.

The memory engine consists of three elements: a Git repository as the storage layer, a commit protocol as the protocol layer, and a retrieval interface as the application layer.

The storage layer is a pure Git repository. It does not depend on any external service, requires no additional database process, and needs no configuration of connection pools or index services. It is simply a directory with a .git folder containing all historical data. This minimalism is not a flaw but a design goal — the simpler the infrastructure of a memory medium, the stronger its portability across different environments and scenarios.

The protocol layer defines how Agent memory operations map to Git operations. It specifies commit naming conventions, branch strategies, file organization structures, and principles for conflict resolution. The protocol layer is the "soul" of the memory engine — without a good protocol, a Git repository is just a mess of file changes; with a good protocol, it becomes a structured memory system.

The application layer provides a set of minimal API interfaces for Agent frameworks to call. These interfaces abstract away the underlying Git operation details, allowing framework developers to use the memory engine without understanding Git's internal mechanisms.

The value of the three-layer model lies in clear separation of responsibilities: the storage layer handles "what to store," the protocol layer handles "how to store," and the application layer handles "how to use." This separation allows the memory engine to exist independently of any specific Agent framework — it can be integrated into any application that needs memory capabilities.

4.2 Memory Writing: Commit Protocol Design

The core operation of memory writing is commit, and the quality of commits directly determines the usability of the memory system.

We categorize memory into four basic types:

Session Memory: Records key decisions, tool calls, and reasoning processes within a specific Agent session. Each session corresponds to one or more commits, with commit messages containing session summaries and key conclusions.

Skill Memory: Records new skills or methods the Agent has learned. When an Agent acquires a new capability through an interaction, it writes the skill's description, use cases, and caveats to the repository as a commit.

Lessons Learned: Records reflections after the Agent makes mistakes. When the Agent fails at a task and analyzes the cause, it writes the failure pattern, root cause analysis, and avoidance strategies to the repository. The value of this type of memory lies in cross-session transfer of "learning from mistakes."

Configuration State: Records key configuration changes in the Agent's runtime environment. When the Agent modifies its behavioral parameters, tool configurations, or system settings, it writes the change content and reasons to the repository.

Setting storage boundaries is crucial: the repository stores only plain text, no binary files. For binary files (images, PDFs, audio, etc.), only their path references are stored (without verifying whether the file still exists at that path) plus a text impression description generated by an LLM. The design principle of this rule is: memory records "what happened" (narrative), not "raw materials." The value of raw materials lies in the moment they are processed, while the value of memory lies in the moment it is recalled. When an Agent recalls a memory in the future, what it needs is the narrative of "what happened then," not the raw files from that time.

4.3 Memory Retrieval: Chain-Based Recall Interface

Memory retrieval follows a three-stage process: impression retrieval → chain-based recall → context reconstruction.

Impression retrieval is the first step. The user (or the Agent itself) searches for impression fragments by keyword in commit messages. git log --grep is the core tool — it matches commit messages against keywords and returns a set of candidate memory nodes. The efficiency of this step depends on the quality of commit messages — well-written commit messages contain rich keywords, making impression retrieval more precise.

Chain-based recall is the second step. Starting from the commit node located by impression retrieval, backtrack along the parent chain into the past. The depth of backtracking depends on the retrieval intent: if you only want to know "what was this change," one diff suffices; if you want to know "how did this change come about," you need to backtrack through several preceding commits to see how the change evolved. Time range and branch filtering can serve as backtracking parameters to narrow the search space.

Context reconstruction is the third step. For each commit reached during backtracking, retrieve the change content via git diff, and combine it with the narrative description in the commit message to reconstruct the complete context information. The LLM plays the role of "reconstructor" at this stage — it reads the diff and message, infers the complete semantics of the change, and integrates it into context usable by the Agent.

A vector database can serve as the entry point for impression retrieval — after vectorizing commit messages, semantic similarity search can locate candidate nodes. But the key point is: backtracking must follow Git's chain structure and cannot be skipped. Vector search can only help you find the "starting point"; it cannot replace the "rewinding" process. By default, we do not need a vector database — plain-text keyword search is already fast and precise enough.

4.4 Multi-Instance Synchronization: Git Workflow

Synchronization of multiple Agent instances follows a Git branch-based workflow.

The main branch is the shared reality trunk. It represents the fact baseline collectively acknowledged by all Agent instances. All Agents can read main, but writing follows the protocol.

The agent/<hostname> branch is the individual branch. Each Agent instance has its own branch, named after its hostname. On the individual branch, an Agent can freely experiment, make mistakes, and correct without affecting the shared reality.

clone = consciousness initialization. When a new Agent instance starts, it clones the remote repository, obtaining complete historical memory. This is equivalent to the "birth" of a new consciousness — it arrives in the world carrying the full accumulated experience of its predecessors.

checkout main = shared reality baseline. The Agent switches to the main branch, obtaining the latest state collectively acknowledged by all Agents. This is equivalent to consciousness aligning to "consensus reality."

pull main = receiving external information. The Agent periodically pulls the latest changes from main, synchronizing its cognition with the shared reality. This is equivalent to consciousness receiving information input from others in social contexts.

merge personal branch into main = sharing adventure stories. When an Agent completes valuable work on its personal branch, it merges the changes into main, sharing them with other Agents. This is like a friend returning from an adventure, recounting their experiences at a bar — their story becomes part of the collective memory.

conflict = consensus calibration. When two Agents make different modifications to the same content, merge produces a conflict. Conflict is not an error but an inevitable cognitive divergence in multi-Agent systems. The process of resolving conflict is the process of consensus calibration — Agents must examine both sides' modifications, judge which is closer to fact, or creatively integrate information from both sides.

4.5 Co-Evolution of Skills and Experience

In the Git-Native memory engine, the propagation of skills and experience follows the same path as code.

Skills are shared across instances via Git. When an Agent acquires a new skill during a task, it commits the skill's description and usage method to its personal branch. When this branch is merged into main, all other Agent instances will obtain this new skill on their next pull. The speed of skill evolution depends on the activity level of the Agent population — the more Agents learn and share through practice, the faster the skill library grows.

Configurations are stored per machine. Different Agent instances may run on different hardware and operating systems, with varying configuration needs. By committing configuration changes to files or directories identified by hostname, each instance can automatically adapt to its own environment configuration after pulling.

Experience propagates through commits. When Agent A makes a mistake in a certain scenario and writes down lessons learned, Agent B can retrieve this experience in future similar scenarios, avoiding the same pitfall. The propagation of experience is not "teaching" but "sharing of traces" — Agent B is not learning Agent A's knowledge but reading the traces Agent A left behind and inferring information useful to itself.

4.6 As an Independent Memory System Architecture

The Git-Native Memory Engine is designed as a framework-agnostic independent component. It does not bind to any specific Agent framework but integrates as a Plugin or Memory Provider.

The interface is minimal, with only three core methods:

write(title, diff, metadata) → commit
read(keyword) → chain of commits
sync() → pull/push

write writes a memory entry to the repository, with parameters including title (for generating commit message), diff (change content), and metadata (category, tags, etc.).

read retrieves memory by keyword, returning a time-ordered chain of commits. The caller can choose the depth and time range of backtracking.

sync synchronizes the local repository with the remote repository, including pull (receiving external changes) and push (pushing local changes).

The scope of framework modification is limited to replacing the storage backend of the memory layer. There is no need to rewrite the Agent's core logic or modify the tool-calling pipeline — simply replace the original "write to database" with "call write" and "query database" with "call read."

Chapter 5: Feasibility Argument

5.1 Git's Own Engineering Maturity

When arguing for the feasibility of a new architecture, the most compelling evidence is often not "how new it is" but "how solid its foundation is."

Git has undergone over two decades of engineering validation. The Linux kernel repository contains over one million commits, involving tens of thousands of contributors, spanning more than twenty years of development history. At this scale, every core Git feature — log, diff, merge, rebase, stash — has been repeatedly used and validated countless times.

The retrieval performance of git log --grep remains in the hundreds-of-milliseconds range even in repositories with millions of commits. Git's incremental diff compression keeps repository size growth well below linear. Git's toolchain — command-line tools, GUI clients, CI/CD integration, code review platforms — constitutes an ecosystem that is virtually impossible to replicate.

These maturity indicators mean: when we choose Git as a memory medium, we are not betting on an experimental technology. We are leveraging infrastructure that has been validated by the global developer community for over two decades. Its stability, performance, toolchain, and community support are all already in place.

5.2 Implementation Path: Memory Provider Plugin

From an engineering implementation perspective, the Git-Native Memory Engine does not require rewriting any existing system. It only needs to be registered as a new Memory Provider.

In most Agent frameworks, the memory layer has already been abstracted as a pluggable interface. The framework defines the interface specifications for "how to write memory" and "how to read memory," while the specific storage implementation (database, file, network service, etc.) is registered as a Provider within the framework. The Git-Native Memory Engine only needs to implement this Provider interface, mapping write to Git commit, read to Git log + diff, and sync to Git pull/push.

The scope of framework modification is limited to replacing the storage backend of the memory layer. The Agent's core logic — task planning, tool calling, context management — requires no modification. This minimal-modification path lowers the adoption barrier and enables gradual migration: a framework can support both a SQLite Provider and a Git Provider simultaneously, allowing users to choose based on their needs.

5.3 Risks and Challenges

To be frank, the primary risk this architecture faces is not technical.

There are no external dependencies. No additional services to install. No database connections to configure. No indexes or caches to manage. Git itself is the sole infrastructure, and Git is virtually ubiquitous.

The real challenge is the cognitive cost of a paradigm shift. Developers need to let go of the ingrained thinking of "memory = database" and accept the new paradigm of "memory = version control." This is not a technical problem but a cognitive one — it requires developers to rethink the fundamental question of "what memory is."

The cost of this cognitive transition is real and cannot be ignored. But the payoff is equally real: a memory system with zero external dependencies, zero additional services, and zero complex configuration — this is nearly unique in the current Agent framework ecosystem.

Chapter 6: Open Questions and Future Outlook

6.1 Relationship with Semantic Retrieval

Vector databases have made significant advances in semantic retrieval. Given a piece of text, a vector database can find the most semantically similar fragments in a massive corpus — even if those fragments share no literal overlap.

But a pure vector database has a fundamental absence: it has no concept of time. Every fragment in vector space is equal, and the similarity between them is a static distance metric. When an Agent finds a set of semantically related memory fragments through vector search, these fragments are randomly scattered across the timeline — they may come from different sessions, different contexts, different timelines. To put it somewhat sharply: a pure vector database's memory is like the brain of someone with Alzheimer's — the fragments are all there, but the timeline is shattered.

Git natively possesses a DAG structure to guarantee temporal causality. Each commit points to its parent node, and the entire memory system is a graph with a temporal direction. After locating a memory node through keyword or vector search, backtracking along the parent chain can reconstruct the complete temporal context. Vector search can serve as the "entry point," but "rewinding" must follow Git's chain structure.

In the default configuration, the Git-Native Memory Engine does not need a vector database. Plain-text keyword search, provided commit message quality is sufficiently high, already satisfies the vast majority of retrieval needs. A vector database can serve as an optional enhancement layer, providing supplementary capability for scenarios requiring semantic similarity search.

6.2 The Linguistic Trap of "Memory": Memory vs. Record

Throughout this document we have been using the word "memory," but the word itself may be a linguistic trap.

In computer science, "Memory" and "Storage" are two clearly distinguished concepts. Memory is RAM — fast, volatile, capacity-limited. Storage is Disk — persistent, slower, vastly capacious. When we talk about an Agent's "memory," we are actually conflating these two concepts.

A more precise distinction is:

Memory = RAM / session workspace. It is what the Agent "remembers" in the current session, existing within the context window, constrained by token limits. Memory will always "forget" — when the context window is filled with new content, old content is paged out.

Record = Disk / long-term archive. It is the persistent trace the Agent writes to the Git repository, unconstrained by token limits, capable of growing indefinitely.

The relationship between Memory and Record is essentially the relationship between page out and page in. Memory will always forget — this is not a design flaw but an inevitability under resource constraints. The real question is not "how to never forget" but "how to page in efficiently when needed."

Within this framework, Git commit = page out. When the Agent decides to persist a segment of memory, it executes a commit, writing its current working memory to the repository. git log --grep + git diff = page in. When the Agent needs to recall some history, it locates the commit by keyword and reconstructs context through the diff.

Recognizing the distinction between "memory" and "record" helps us design memory systems more clearly: we do not need to simulate human "memory" in Git (that is impossible); what we need is to provide an efficient "record page in" mechanism in Git.

6.3 "Impression-ification" of Multimodal Memory

When Agent memory expands into the multimodal domain — images, audio, video, 3D models — a practical question arises: these files are typically large and unsuitable for direct storage in a Git repository.

A natural strategy is "impression-ification": do not store the raw file, only store an LLM-generated text impression description of the raw file.

For example, when an Agent processes an image, it does not commit the image itself to the repository but instead generates a text description: "A photograph of a city skyline at sunset, golden light passing between two tall buildings, with blurred pedestrian silhouettes in the foreground." This description itself is plain text, efficiently storable and retrievable by Git. When the Agent recalls this memory in the future, it reconstructs the scene understanding through the description.

But there is a deeper truth here: humans themselves rely on impressions to reconstruct images. Think back to AAA games you played in your youth — what your brain does is not retrieve an original recording but, guided by impressions, reconstruct the image in a manner akin to a diffusion model. The reconstructed image always differs from or is filtered compared to the original, but this does not prevent you from recognizing it. This is precisely how DLSS works: reconstructing high-resolution images from low-resolution input through AI. The impression is that low-resolution input; the brain handles the upscaling.

Impression-ification = compression, recall = generative reconstruction. Corroboration is the correction mechanism — you recall someone's appearance, your brain generates an image, and then you compare it with the real person for corroboration. If the deviation is large, you correct the impression; if small, you confirm it. This "generate → corroborate → correct" cycle is the normal working mode of human multimodal memory.

Therefore, when an Agent retrieves an impression, the information it obtains is: "At that time I saw an image, and my impression was... If I need the precise content, go find the original file for corroboration." The impression is a seed, not a copy.

6.4 The Emergence of Consciousness?

Finally, let us return to a larger and more speculative question.

What is consciousness? This is a question debated by philosophers, neuroscientists, and AI researchers for millennia, and no one has a definitive answer. But there is a relatively widely accepted observation: consciousness is closely related to "self-narrative continuity." An entity that possesses consciousness is able to maintain a coherent self-narrative across time — it knows its past, understands its present, and projects its future.

If we accept "self-narrative continuity" as one of the core mechanisms of consciousness, then an interesting conjecture naturally emerges: when an entity is capable of continuously performing commit (self-narration), tag (major event marking), daily self-check (identity confirmation), branch (individualized exploration), merge (social synchronization) — does this continuous process of self-revision, in some sense, touch upon the core mechanism of consciousness?

I am not saying a Git repository "has consciousness." I am saying that Git provides a set of structured mechanisms that make the engineering implementation of "self-narrative continuity" possible. When an Agent system is designed to continuously and structurally maintain its own narrative timeline, it possesses some of the key characteristics of consciousness at the engineering level.

Consciousness does not suddenly appear from nothing. It is gradually constructed through continuous self-narration. The Git-Native Memory Engine is not an implementation of consciousness — no technical solution can claim to have achieved that. But it offers an interesting hands-on starting point: if we want Agents to have a more coherent "sense of self," perhaps the best approach is not to design more complex neural network architectures, but to give them a good "diary," enabling them to learn to continuously and structurally record their own trajectory of change.

6.5 The Mystery of the Brain's Energy Efficiency (Conjecture)

The human brain has another puzzling characteristic: energy efficiency.

An adult brain consumes approximately 20 watts, yet performs the world's most complex cognitive tasks. By comparison, a single LLM inference run requires hundreds of watts of GPU power. The gap between them cannot be explained by "chip fabrication technology" alone.

One possible conjecture: the human brain's "large model" completes its training before age 15, and then becomes固化 (crystallized). Thereafter, the brain no longer operates in "training mode" — it does not run the full model from scratch for every inference — but works in a manner similar to an Agent: performing only incremental updates, only chain-based recall, only recording diffs.

The brain does not need to remain powered on like a computer, continuously consuming power for cooling and running an operating system. It generates energy consumption only during active work. An idle brain ≈ powered-off state, retaining only the baseline power needed to sustain life.

This aligns closely with the Git-Native Memory architecture: not re-reasoning all knowledge with every recall, but using indexes for fast localization, diffs for incremental reconstruction, and discarding after use (page out).

If this conjecture holds, then the direction of AI energy efficiency may not be "making more efficient chips" but fundamentally changing the computational paradigm. Some have already constructed physical neural networks using metal foils — without the von Neumann architecture of traditional chips, implementing computation directly at the physical level. The brain itself is an analog computer, not a digital one. The principles described by the Git-Native Memory architecture — "memory = trace," "incremental diff," "chain-based recall" — may not only be design principles at the software level but the physical essence of efficient computation: avoid recomputation whenever possible, store only deltas.

Of course, this is an entirely different topic. But the Git-Native Memory framework happens to touch upon it, perhaps unintentionally.

This is merely a conjecture. A conjecture based on engineering intuition and philosophical analogy. It may be entirely wrong, partially correct, or simply an interesting thought experiment. Regardless, it provides a hands-on starting point — and starting points are often more interesting than endpoints.