close

DEV Community

Cover image for Git is for one agent. AgentStore is for agent teams.
Guy Weissman
Guy Weissman

Posted on

Git is for one agent. AgentStore is for agent teams.

Git has become the storage option of choice for many AI agent users, harnesses and knowledge frameworks. It made a lot of sense when chatbots were just getting started - users were looking for ways to manage their work. Chatbots forced us into linear workflows, but we needed a multi-dimensional workspace to track prompts, revisit artifacts, chain outputs and more.

When users started managing prompts and skills Git became an even stronger fit for these code-like artifacts.

The AI agent datastore use case plays to Git's strengths:

Portable - we want to own our agents' memory especially with something as sticky as a personal agent
Versioning and auditability - both to counter the probabilistic nature of agents and to manage skills and prompts
Integration fit - easily connect with agents like Codex or Claude Cowork, which are built to live in folders, and are also well versed in using Git
As we continue to push agents' capabilities we are starting to see new requirements. Git was built for human speed. Mixed multi-user/agent environments need finer grained permissions. Knowledge frameworks like GBrain (agent memory layer) want awareness of when things change to reduce stale knowledge.

The challenges are:

Repo-level permissions - Any agent with push access can read and write every file. You cannot give a research agent access to /customers/sanitized without also exposing /finance
Write starvation - Even when two agents modify completely different files, the second to push must pull, merge, and retry — because Git conflict detection is repo-level, not file-level. Agents work much faster than humans, and as agent teams grow collisions will increase
No live events - Git is a passive store. Knowledge systems that need to react to changes must poll
Git isn't the only option, but all options today force a bad choice:

Git and open comparables - portable, familiar, versioned — but repo-level permissions, no live events, designed for code
Cloud drives and note apps (Google Drive / Box / Notion) - file permissions, real-time events — but proprietary, vendor lock-in, not agent-native
Version-controlled data (Dolt, lakeFS) - versioned, branchable — but built to version data (SQL tables, data-lake objects), not files, which is where agents live
Git's strengths are: portability + versioning + integration fit

AgentStore adds: file-level access control + non-blocking writes + real-time events

I built AgentStore as a datastore for the agents I use in my work.

AgentStore - a datastore for AI agents

Git is for one agent. AgentStore is for agent teams.

Git has become the storage option of choice for many AI agent users, harnesses and knowledge frameworks. It made a lot of sense when chatbots were just getting started - users were looking for ways to manage their work. Chatbots forced us into linear workflows, but we needed a multi-dimensional workspace to track prompts, revisit artifacts, chain outputs and more.

When users started managing prompts and skills Git became an even stronger fit for these code-like artifacts.

The AI agent datastore use case plays to Git's strengths:

  • Portable - we want to own our agents' memory especially with something as sticky as a personal agent
  • Versioning and auditability - both to counter the probabilistic nature of agents and to manage skills and prompts
  • Integration fit - easily connect with agents like Codex or…

Got any questions? Leave them in the comments

Top comments (0)