Volt

The deciding trait is that the session never stops to catch its breath. Compaction happens between turns instead of interrupting you, so the long afternoon where you and an agent slowly build something does not get punctuated by a wait while it summarises itself. If that pause has ever broken your concentration, this is the fix.

The new part is the memory engine and the rest is inherited, so nothing about the surrounding tool will surprise you. Pick it if your sessions run long. Pick a mainstream agent if you would rather not be early.

It is a fork, and forks of active projects age. Session management has been replaced wholesale in something that ships releases of its own, so every upstream change is now a merge decision for whoever maintains this, and the divergence only grows. The label on the tin says research preview, which is the maintainer telling you the same thing more politely.

The engine itself is careful work. The risk is not in the memory, it is in the four-fifths of the tool that came from somewhere else and keeps moving without asking. Pin a version and expect to stay on it.

1. Retrieval is the claim and the structure is stated: summary nodes in a high-fanout directed acyclic graph, with any earlier message reachable regardless of how many compactions have intervened. A graph with high fanout keeps path lengths short, which is the property that makes deep history cheap to reach rather than merely present.

2. There is a paper, which puts this ahead of most of the board. 3. What the paper does not appear to carry into the product is a measurement: no figure is offered for retrieval accuracy, and an architecture that guarantees a message is reachable says nothing about whether it is found.

The product is a demonstration and the asset is the engine. Voltropy is not really shipping a terminal tool here; it is showing a component to the companies that would rather buy one than build it, and 290 stars is not the metric that decides whether that works.

Moat: the engine, if the claims hold and if it is hard to reimplement. Likely path: licensing the memory layer, or an acquihire by a vendor whose agent forgets things. Likely acquirer: any of the large coding-agent vendors, all of whom have this exact problem. Position: watch the company more closely than the tool.

Every message and every tool result is written verbatim to an immutable store. Read that sentence as a retention policy and it says: everything anyone types, kept forever, on sixty laptops, with no deletion path described anywhere in the row. That is a conversation with legal, not with finance, and it is the first one we would have.

The rest is the usual: no console, no identity integration, nothing that runs in a pipeline, and a source install that assumes a runtime my endpoint team does not manage. Not yet: I need a documented deletion story before an engine designed never to forget goes near customer code.

MIT, and the two operator tools are the reason I would install this. LLM-Map and Agentic-Map take a JSONL file and push the loop into the engine, one item at a time across a worker pool, and the second one spawns a whole sub-agent per row with an optional read-only flag. That is a batch primitive I have written badly by hand more than once.

The read-only flag is the detail that shows someone has run this in anger. What is missing is an MCP client, so the sub-agents get whatever tools the tool already had and nothing I run myself.