​

Memory Branching — Git for Agent Memory

Every plan records an agent’s memory as a timeline of events on main. Branching adds the rest of the model on top: work an agent does on a branch, review it before it lands, tag a known-good state, and roll back to it when something goes wrong.

​

Branches

Create a branch from an agent’s main memory and let the agent write to it without touching what everyone else reads. Diff the branch against main to see exactly what changed, then merge it or throw it away. This is what makes risky work safe. An agent trying a new approach can build up a whole set of beliefs on a branch, and if the approach turns out to be wrong, none of it ever reaches the memory other agents rely on. Merges default to fast-forward. Where the same key changed on both sides, the merge reports the conflict and you choose which value wins.

​

Pull Requests

A branch can be opened as a pull request so a human or another agent reviews the change before it lands on main. Reviews come in three kinds:

​

Branch Access Control

Grant read or read/write access to a branch, so a branch of sensitive or in-progress memory is not readable by every agent on the account. Grants are made to an API key or a team, and each grant is either read or read_write. Access is enforced by the server on API-key traffic to the entry and search endpoints: a request targeting a non-main branch is checked against that branch’s grants and refused with a 403 if it does not have them. Writes require read_write — a read grant can see the branch but not change it.

​

Tags & Rollback

Tag a point on the timeline with a name, then roll the agent’s memory back to either a tag or a specific timestamp. This is the recovery path when an agent learns something wrong and acts on it repeatedly: instead of hunting down each bad entry, return the brain to a state you know was good.

​

Cherry-pick & Fork

Cherry-pick moves selected entries between branches when you want one useful thing from a branch you are otherwise discarding. It is available through the API. Fork clones an entire agent’s memory to a new agent — the fast way to stand up a second agent that should start out knowing everything the first one does.

​

Sacred Timeline

The default view in the Git Repository section is an interactive 3D visualisation of how the agent’s memory evolved: event nodes along the timeline, forks where branches split off, and a detail panel for any event you click. Next to it, Event Log shows the same history as a chronological list, which is usually the faster way to find a specific write.