HAM (Hierarchical Agent Memory)
For a while this year I was deep on a side project called HAM, Hierarchical Agent Memory. It was a memory system for AI coding agents, and the whole thing came out of one small annoyance.
The annoyance
Every time you start a session with a coding agent, it re-reads everything. Your whole project structure. Conventions it already knew. Decisions you'd already made. A single bloated CLAUDE.md could eat close to half the context window before the agent wrote a single line of code.
That bothered me on three levels at once: it was slow, it cost money, and it burned energy for context the agent didn't even need. So I built a fix.
The one good idea
HAM had exactly one idea, and I still think it's a good one: scope, don't dump.
Instead of one giant context file at the root, you put small CLAUDE.md files at each directory level. Global conventions live in root. API patterns live in the API folder. Component rules live with the components. When the agent touches a directory, it reads root plus that directory's file — two or three small files instead of the entire project.
project-root/
├── CLAUDE.md # global: stack, conventions (tiny)
├── src/
│ ├── api/CLAUDE.md # auth, rate limits, endpoint patterns
│ ├── components/CLAUDE.md
│ └── db/CLAUDE.md
└── .memory/
├── decisions.md # architecture decisions + rationale
└── patterns.md
The numbers from my own testing held up surprisingly well:
Before HAM | After HAM | |
|---|---|---|
Context per prompt | 4,000–12,000 tokens | 800–2,400 tokens |
50-prompt session | 200K–600K tokens | 40K–120K tokens |
Context used at start | up to 47% | under 10% |
Roughly an 80% reduction in the cases I cared about. You said go ham and it auto-detected your stack and generated the scoped files for you. There was a little dashboard, a savings report, even a carbon estimate, because the sustainability angle was half of why I started.
What I learned
A few things stuck with me:
The fix for "too much context" is almost never "more clever compression." It's locality. Put the information next to the thing it describes and most of the problem disappears.
A self-maintaining system is the only kind people actually keep. The moment memory needs manual upkeep, it goes stale and gets ignored. The parts of HAM that worked were the parts that updated themselves.
Scope is a discipline, not a feature. The hard part was never the code — it was deciding what belonged where.
Why I'm putting it down
I feel like the labs will solve this problem or a player with more engineering resources.
I'm not pretending it failed. It did the thing I built it to do. I just don't have the energy to carry it forward, and I'd rather say that plainly than let it quietly rot with a fake "exciting roadmap ahead."
It's still there
HAM is MIT-licensed and still up on GitHub. If the idea is useful to you, take it, fork it, gut it for parts. That's what it's for.
Fewer tokens. Greener AI. It was a good little idea, and I'm glad I built it.