CONTEXT · AGENTS · OPEN SOURCE
rlm-agent: what happens when context lives outside the prompt
A functional review of the persistent kernel and context lake: what works, where information can be lost and what still needs checking in real editors.
Share this read
A useful question, before any promise.
Can an agent query a repository without loading all of it into context? Nicolás Ramos’s rlm-agent explores that direction with a persistent Python kernel and a context store accessible through code. We wanted to examine its concrete mechanisms, without treating the savings figures behind the discussion as verified.
What we reviewed — and under which conditions
The 11 September 2026 report documents tests at commit 5178d62. They exercised the kernel protocol, persistence and context-lake operations, as well as adapter classes. The test lab was external and separate from DARXI: macOS arm64, Python 3.13.15 and Bun 1.4.0; Node.js 24.20.0 was used only in the Pi harness.
There were no LLM calls or tests inside OpenCode, Pi or Hermes. Adapters were loaded with minimal substitutes for editor interfaces. The network restriction applied to Python and Node did not restrict Bun; no test needed the network.
What did work
- The kernel booted, kept state across requests and returned errors explicitly.
- Basic store/get operations preserved the tested content in the kernel, Hermes and Pi implementations, including multiline Unicode.
- The project’s own suite passed 25/25 checks. That result does not cover every integration scenario.
Three findings worth examining
Concurrent writes and deletion
In three reproductions, forget lost 24, 27 and 35 of 200 entries appended by other processes. Controls without forget lost 0, 0 and 0.
The test shows the mechanism; it does not estimate its frequency in real sessions.
A cache that misses another write
The Hermes ContextLake class kept a stale view. A subsequent forget removed an entry written by another process.
Observed at class level; instance lifetime inside Hermes still needs verification.
Storing did not mean appending
On Bun 1.4.0, the Bun.write call used by the OpenCode adapter left only the latest lake entry in the reproductions.
This does not establish the impact on real OpenCode: that depends on its runtime. Other versions were not tested.
EDITORIAL INTERPRETATION
What we take from this review
Moving information outside the prompt changes access to context, but also makes persistence, concurrency and process boundaries important. Our editorial interpretation: before evaluating savings, establish what information can be retrieved and under which conditions. This is neither an adoption recommendation nor a validation of the DARXI product.
What this work does not establish
- It does not reproduce the advertised token savings or latency figures. This is not a benchmark.
- It does not validate security, snapshot/restore, recursion, installers or full editor integration.
- A single reviewer designed the tests and wrote the report. Two code paths do not amount to two independent reviewers.
- Results describe the tested commit and environment, not the current state of the repository.
Credits and sources
Nicolás Ramos authored the repository under review, not this article, and did not review our findings. DARXI publishes this editorial adaptation of the external report. It implies no partnership, author endorsement or submitted pull request.
Repository author: Nicolás Ramos
LinkedIn ↗ · GitHub ↗
Code at the reviewed version ↗
Documentary basis: External Functional Review v2, §§1–6 and §§9–11; Spanish translation of the same report. Secondary observations and reproduction instructions are in the PDFs.
Original reports
The PDFs retain their original content and presentation, without added branding. These are two languages of one review; the Spanish edition keeps script output in English.
SHA-256
5f14de35f416bdf04a22a68b7a1e4441dc0bb4be6a43c3b12b7c5f4e55cc13aeSHA-256
727e549baadd76b52e2197d2d7370260b2426caf665a6f525f9c89ef78612e0a