Git Is an Agent's Best Memory
An API your agent learned last week has to be relearned this week—every new service is a cold start. My answer isn't a vector database; it's a helpers directory plus git history.
Anyone who builds agent tools has run into the same awkward problem: your agent learned how to call Linear's API last week—reading docs, trial and error, getting it working—and this week, when it encounters Linear again, it starts over from scratch: reading docs, trial and error, getting it working. There is no muscle memory; every new service is a cold start.
The industry's standard answer is to connect the agent to a vector database and store "experience" as vector embeddings. When I was building my open-source project graft, I chose a different path, for a simple observation:
The way engineers accumulate experience has always been to write code and commit it to git.
Why should agents be the exception?
So graft's memory design has only two layers: a helpers directory—code files the agent writes and revises as it works, one per service—plus git history. This combination offers benefits, none of which a vector database can give you:
- Readable — a human can open it at any time and see what the agent has learned, and spot mistakes immediately;
- Editable — the agent can refactor its own experience, and a human can also fix it directly;
- Rollbackable — learned something wrong? git revert;
- Shareable — push to a pure git community registry, and other people's agents can reuse it directly, with no central server required.
Behind this is the Bitter Lesson of agent harnesses, as the Browser-Use team puts it: don't teach the agent how to do its job; give it a plot of land it can maintain itself. Models get stronger every year; any "teaching logic" you hard-code will quickly become obsolete. But the mechanism of "let it accumulate and revise on its own" will not.
graft also has an even more radical discipline: CI enforces a budget on lines of core code, and a bug fix is not allowed to add lines—if fixing a bug requires adding code, it probably means you haven't found the root cause. Line count is not a cost metric; it's a thermometer for design quality.
Putting memory into git has another hidden benefit: it forces experience to be written down. Embeddings in a vector database are a black box—nobody can review them. An 80-line helper file, by contrast, can be reviewed, tested, and trusted by both humans and agents.
Trust isn't fed; it's audited. That statement holds for people, and it holds for agents too.