Stop copying your agent's memory. Branch it.

agenticow is "Git for Agent Memory": instead of copying an AI agent's entire vector memory every time you want a private version of it, agenticow branches it — copy-on-write, like Git — so a fork, checkpoint, or rollback costs about half a millisecond and 162 bytes no matter how big the memory is.

Here's the everyday version. Modern AI agents remember things by turning text into long lists of numbers — embeddings — and storing them in a vector database so they can later find "the most similar thing I've seen before." That store is the agent's memory.

The expensive habit: the moment you want a separate version of that memory — one per customer, a throwaway sandbox to test a risky import, a safety checkpoint before a tool call — every normal vector database makes you copy the whole thing. agenticow branches it instead. A branch records only its own edits plus a pointer to its parent — 162 bytes, constant time, independent of base size.

The repo's own analogy: "Git doesn't make developers write better code — it lets thousands of them work concurrently, isolate mistakes, roll back, and merge through CI. agenticow is the same shape for cheap-model fleets." ("COW" = Copy-On-Write — and yes, the name is a pun on the cow.)

Start from the very beginning. An AI agent's memory is just everything it has been given and has learned — your documents, your corrections, what's happened so far. One memory, shared by everyone using it, is fine… until the day you need a second version of it: a private memory for one customer, a safe place to test a risky new batch of documents, or a "save point" you can return to if something goes wrong.

The obvious way to make a second version is to copy the memory. And that's the trap. An agent's memory is big — so copying it is like photocopying an entire filing cabinet just to jot one note on one page, or duplicating a 50 GB video game every single time you want a save point. It's so slow and so wasteful that, in practice, people just don't — and then they live with the consequences of not having separate versions.

Four ways this quietly bites you — and how agenticow fixes each

Wait — how do you even end up here?

It's almost a rite of passage. You ship an agent with one shared memory and it works beautifully. Then real life shows up — usually within the first week or two of anything real:

• A second customer signs up, and their data can't be allowed to mingle with the first one's.
• You want to try a big new import without risking the memory that already works.
• A tool call goes sideways, and you wish you'd kept a restore point from five minutes ago.
• You'd like to run a few experiments at once and keep whichever turns out best.

None of these are exotic — they show up the moment more than one person, or more than one experiment, touches the same agent. For most teams that's not "someday," it's week two. And every single one of them needs the exact same thing underneath: a separate version of the memory. That's the fork in the road — and where the trouble starts.

What people normally do about it — and why it quietly hurts

Every one of those is the same root cause — copying a memory is expensive — and agenticow's answer is the same elegant move every time: don't copy it, branch it. One shared base, a weightless 162-byte overlay per version — and isolation, instant rollback, diff, and merge all come along for free. The thing that was "496 MB and 67 ms — every time" becomes "162 bytes and 0.47 ms, flat."

The repo's thesis: "smarter orchestration, not smarter execution." With cheap models, the win comes from running many isolated attempts and discarding the bad ones — so "'throw it away and try a fresh independent attempt' beats 'make it reflect on its mistake.'"

• Reasoning scaffolds can backfire on cheap models. The README cites a scaffolding ablation (FRAMES benchmark, cheap models deepseek-v4-pro + glm-5.2) where clever reasoning prompts make cheap models do worse, not better.
• So you parallelize instead. Run a thousand cheap, isolated attempts off one shared memory, keep the winners, drop the rest. That only works if spinning up (and throwing away) an isolated memory is nearly free.
• That's exactly what cheap branching unlocks. agenticow is "infrastructure that turns 'run 1,000 cheap agents safely' into a tractable, near-free operation" — it "makes failure free."

Copy-on-write, in plain terms: a branch "records only its own edits plus a pointer to its parent." Nothing is copied up front — the base is shared and read straight through. You only ever store what a branch actually changes.

The Git-shaped operations you get

• branch() / fork() — make an isolated child (162 B, ~0.5 ms).
• delete() — a copy-on-write tombstone that hides ancestor ids without touching the base.
• checkpoint() / rollback() — freeze a restore point, then discard everything since (rollback p50 0.571 ms).
• diff() — returns { added, overridden, deleted }, just like a Git diff.
• promote(target) — "replay this branch's edits into target" (a Git-style merge).
• lineage() / status() — an auditable parent/label/timestamp trail.

"Solved" isn't abstract here — it's a set of measured numbers you can reproduce with npx agenticow bench.

Sofia runs a small SaaS writing-assistant. Every customer's assistant should remember their documents, their style, their corrections — privately. She's not a database engineer; she just needs each customer to have their own memory without it costing a fortune or leaking across accounts.

The "oh, that's what it's for" line: It's the difference between photocopying the entire filing cabinet for every customer, and giving each one a transparent overlay sheet that only records what they changed.

This is the fun part: half a dozen or so real examples of how you actually use this — to make your agent (sorry in advance) udderly more efficient. Open any card for the situation, the exact command, what it does, and a diagram of what happens. (Every one maps to a script in examples/, per examples/README.md.)

One npm package, ESM, Node ≥ 18, one runtime dependency. This is the layout (reconstructed from package.json files + README references) — annotated so you know what each part is for.

Use it in your own JavaScript

Open a base, branch it, and the branch is isolated and instantly queryable. Roll back to wipe a bad ingest without touching the clean memory.

import { open } from 'agenticow';

const base  = open('memory.rvf', { dimension: 1536 });
base.ingest([{ id: 1, vector: embedding }, /* ... */]);

const agent = base.branch('agent-a');        // ~0.5 ms / 162 B, any base size
agent.ingest([{ id: 9001, vector: newMemory }]);

const hits  = agent.query(queryVector, 10);  // -> [{ id, distance, branch }, ...]

const ckpt  = agent.checkpoint('clean');
agent.ingest([{ id: 666, vector: poison }]);
agent.rollback(ckpt.id);                      // poison gone, clean memory intact

1. Install it. Requirements: Node ≥ 18, ESM.
   $ npm install agenticowcopy
2. CLI, no code. Init a store, ingest, branch per user, query the read-through, see the diff:
   $ agenticow init mem.rvf --dim 128 $ agenticow ingest mem.rvf --n 5000 $ agenticow branch mem.rvf --as user-42 $ agenticow query mem.rvf.user-42.rvf --k 10 $ agenticow diff mem.rvf.user-42.rvfcopy
3. Or use the API (import { open } from 'agenticow') — see §09 for the worked snippet. To just watch it run, agenticow demo.

Open the repo on GitHub ↗