When every team member's coding agent follows slightly different project instructions, AI can create a new kind of inconsistency instead of removing it. Engineers may have to stop, compare rules, reconcile conflicting guidance and figure out which version is actually authoritative before they can get back to delivering changes for customers.
The problem gets worse as more people contribute. A useful local improvement can become a team-wide inconsistency unless there is a clear way to review changes, preserve history and decide what becomes shared.
That is where Git became useful for us. Git already gives software teams a familiar way to review changes, compare versions and establish an approved source of truth. Rather than rebuild all of that collaboration logic inside Fabric, we chose to let Git handle version history and reviews while Fabric focuses on getting the right approved context to the agents that need it.
If your team is managing shared coding-agent instructions today, a practical place to start is simple: put one project's shared instructions in a repository, name a reviewer, and decide how approved updates will reach each agent.
At TechFabric, that same problem shaped our exploration of shared memory in Fabric and left us asking what Fabric should own and what we should deliberately leave to Git.
When distribution becomes collaboration
The initial bundle-based approach gave developers access to common instructions. Teams could upload files in bulk and retrieve them through MCP, with history recorded for each bundle.
That model fit a one-way flow, where someone maintained the shared instructions and developers retrieved them.
Its limits mattered once local contributions entered the picture. Individual files had no separate history, since each entry covered a whole bundle. Developers couldn't push local updates back.
A bundle can answer, "Which collection did I download?" It is less suited to answering, "Which rule changed, why did it change, and should my local edit replace it?"
The contribution loop changed the nature of the feature. Supporting shared memory now meant handling local customizations, competing versions, review and merge decisions as well as moving files.
A Prototype of shared memory in Fabric
We put those requirements directly in a native "living-memory" workflow, a shared means of collecting, updating, and using CLI memories. Our initial internal demonstration included content-hash deduplication, detection of divergence between local and server versions, and a process for viewing and approving proposals.
Each part addressed a contribution problem. Deduplication could identify unchanged content. Divergence detection could surface situations where the local and shared copies no longer matched. Proposals could provide a review boundary before local changes became shared instructions.
But the design also made a larger trade-off visible. As the workflow grew, it began reproducing version-control responsibilities, because someone had to compare versions and decide which contributions became authoritative.
The question became whether those responsibilities needed a separate implementation inside Fabric.
Let Git own the collaboration history
The team also evaluated Git as the underlying mechanism for shared memory. Branches, pull requests, history and diffs supplied an existing model for proposing and reviewing changes.
We chose to use a Git repository as the source of truth, with Fabric providing an interface layer rather than replacing Git's collaboration model.
That matters. Git can record and compare versions, and a repository's review workflow can govern which contributions are accepted, so Fabric can focus on connecting shared instructions to the environments and agents that need them.
The discussion also separated a memory repository from application code repositories. Instructions and agent memory could have their own repository, while being made available to coding agents through MCP. That creates a distinct place to maintain shared context without requiring it to live inside every application repository.
A remote connection is not enough
One of the most useful review points concerned the developer's local folder.
Connecting Fabric to a remote repository did not, by itself, preserve the expected Git workflow locally. The local folder needs to be a proper Git repository, created through cloning or initialization, with native local tracking.
This is an important distinction for any tool built around Git. A repository can be a remote storage backend without giving developers the branching, pull/push and diff workflow they expect on their machines.
If the reason to choose Git is to reuse its collaboration model, the local experience needs to preserve that model too. Otherwise, the integration risks recreating a parallel change-management workflow around a Git-shaped storage layer.
Git does not decide what context an agent needs
Moving version history into Git does not remove the need to design synchronization carefully. The work also moved toward updating relevant files rather than refreshing the whole repository, and the integration must decide which files an agent needs and when they get sent to it.
The two jobs are separate.
- Version control establishes which version is authoritative and records how it changed.
- Getting context to the agent makes the relevant files available to an agent and determines when to refresh them.
Git provides a foundation for the first. The CLI/MCP integration addresses the second. Neither a repository connection nor a successful file transfer, on its own, establishes a complete synchronization and review workflow.
Recognizing the responsibility boundary
The choice depends on how your team contributes to shared instructions.
A bundle model can be appropriate for distributing centrally maintained instructions. A native approval workflow can offer a deliberately constrained contribution experience. Git becomes especially relevant when shared instructions need the same collaboration behaviors developers already use for code.
This left us with an authoritative history and review with the repository, and Fabric focuses on making the agreed context useful to agents.
The design work clarified why native local Git behavior matters and why refreshing agent context needs its own rules. Reusing Git keeps those responsibilities visible, and that division is the basis of our Git-backed shared memory design.
Frequently asked questions
Why use Git for shared coding-agent memory?
When developers contribute local changes to shared instructions, they need history, diffs and a way to review competing versions. Git and a repository's review workflow provide an existing foundation for that collaboration.
Does a Git repository replace Fabric's CLI and MCP integration?
Git tracks versions. The CLI and MCP integration determines which instruction files an agent receives and when they refresh. Connecting a repository does not resolve those delivery decisions.
Does agent memory have to live with application code?
The design separates the memory repository from application repositories. Shared instructions can be maintained in their own repository and made available to agents through MCP.
Why not keep the native approval workflow?
As that workflow grew, it started reproducing version-control work. Someone had to compare versions and decide which contribution became authoritative, and Git already supplies branches, pull requests, history and diffs for exactly that.