You could definitely build a coding agent that way, and it sounds like you've done it. We store the conversation history because:
1. In our use of coding agents, we find that there are often things referenced earlier in the conversation (API keys, endpoint addresses, feedback to the agent, etc.) that it's useful to have persist.
2. This is a general-purpose LLM memory system, which we've just used here to build a coding agent. But it is also designed for personal assistants, legal LLMs, etc.
By construction, individual summaries are not typically large enough to overload the context window when expanded.
The reason that the volume is potentially arbitrarily large is that one sub-agent can call lcm_expand multiple times - either vertically or horizontally. But that's a process that occurs gradually as the tool is used repeatedly.
This has not been a problem in our testing, but if it were a problem it would be easy to prevent sub-agents from invoking lcm_expand once their context buffer has reached a specified threshold.
We don't have any other materials yet, but let's see if this lands for you. I can run you through a couple simpler versions of the system, why they don't work, and how that informs our ultimate design.
The most basic part of the system is "two layers". Layer 1 is the "ground truth" of the conversation - the whole text the user sees. Layer 2 is what the model sees, i.e., the active context window.
In a perfect world, those would be the same thing. But, as you know, context lengths aren't long enough for that, so we can't fit everything from Layer 1 into Layer 2.
So instead we keep a "pointer" to the appropriate part of Layer 1 in Layer 2. That pointer takes the form of a summary. But it's not a summary designed to contain all information. It's more like a "label" that makes sure the model knows where to look.
The naive version of the system would allow the main model to expand Layer 2 summaries by importing all of the underlying data from Layer 1. But this doesn't work well, because then you just end up re-filling the Layer 2 context window.
So instead you let the main model clone itself, the clone expands the summary in its context (and can do this for multiple summaries, transforming each into the original uncompressed text), and then the clone returns whatever information the main thread requires.
Where this system would not fully match the capabilities of RLMs is that, by writing a script that calls itself e.g. thousands of times, an RLM has the ability to make many more recursive tool calls than can fit in a context window. So we fix that using operator-level recursion, i.e., we give the LLM a tool, map, that executes arbitrary recursion, without the LLM having to write a custom script to accomplish that.
Our system uses sub-agents as a core part of its architecture.
That terminology can be confusing, because in other cases (and sometimes in our own architecture, like when executing thousands of operations via MAP) a sub-agent may be a smaller model given less complex individual tasks.
But the core mechanism we use for simulating unlimited context is to allow the main model to spin up instances of itself (sub-agents) with the previously summarized portion of the context expanded into its full, uncompressed state.
Expanding summaries into full text in sub-agents rather than the main thread is a critical part of our architecture, because it prevents the main context window from filling up.
Yes, that is actually the next thing we are shipping!
We have heard from a ton of OpenClaw users that the biggest barrier to them getting everything they want out of their agents is that memory is not a solved problem.
LCM could be a great solution to that. Stay tuned -- will ship it ASAP.
Hi, I'm Clint, one of the co-authors of this paper.
I'd like to quickly summarize what is different about our approach and why it matters.
Our work was inspired by brilliant research done at MIT CSAIL on "Recursive Language Models" (RLMs). One of the controversies has been whether these models are just a formalization of what agents like Claude Code already do vs. whether they bring new capabilities to the table.
By outperforming Claude on the major long-context benchmark, we provide a strong signal that something fundamentally new is happening. (In other words, it's not "just Claude Code" because it demonstrably outperforms Claude Code in the long-context regime.)
Where our contribution, LCM, differs from RLMs is how we handle recursion. RLMs use "symbolic recursion" -- i.e., they have an LLM write a script to recursively call itself in order to manipulate the context, which is stored in a REPL. This provides maximum flexibility... but it often goes wrong, since the LLM may write imperfect scripts.
LCM attempts to decompose the recursion from RLMs into deterministic primitives so that the control flow can be managed by an engine rather than left to the whims of the LLM. In practice, this means we replace bespoke scripts with two mechanisms:
(1) A DAG-based context management system that works like paged virtual memory, except for managing conversations and files;
and
(2) Operator-level recursion, like "Map" for LLMs, which lets one tool call process thousands of tasks.
An analogy we draw in the paper is the evolution from GO-TO statements (of Dijkstra's "Considered Harmful" fame) to structured programming. RLMs are maximally expressive, but all of that power comes with the risk of things going awry. We have built a more mechanistic system, which can provide stronger guarantees when deployed in production with today's models.
Happy to answer any questions! Thanks for taking a look at the paper!
Thanks for the questions. I'll make sure to expand the FAQ when I get a chance.
1. The USD that you can use to unlock USDf (forked dollars/digital gold) is limited to deposits at commercial banks and credit unions. The public does not have access to electronic base money, so it's not included.
2. The quantity of USDf you can unlock is based on your historic bank balances, as verified during a defined window in the past. New credit money created after that point in time doesn't affect those past balances. To the extent that the owners of new USD wish to acquire weight for them, they'd need to purchase USDf, increasing its value. That is sort of the whole point: if governments keep inflating their money, the "forked" version with guaranteed scarcity will gradually increase in value.
3. USDf will trade at a different value than USD. At first, a much lower value. The idea is for them to be employed in a hybrid unit of account, USDw, where 1 USDw = 1 USD + 1 USDf.
A crypto-weighted dollar (i.e., USDw) will trade at a premium over a USD, since it is a USD + cryptographic weight. Think of it like a stablecoin that also comes with Bitcoin-like inflation protection. However, it's also possible to use USDf as an independent asset, and that will be convenient in use cases where transferring USD on existing payment rails isn't practical.
There's two nuances I would respectfully suggest that you're overlooking.
First, KRNC is designed to be employed as a supplement to USD. Most transactions would be executed with both USD and a corresponding blockchain asset. Technically, this is a digital analogue of the "symetallic standard", in which base money is comprised of both gold and silver in a specified ratio. The point is risk diversification: if fiat money implodes, or if crypto fails, you aren't wiped out.
Second, the concept of "intrinsic value" is misleading/confused when it comes to money. Things that trade at their consumption/production value are not monetized. Treating something as money involves attaching symbolic value to it: accepting it as proof of goods or services rendered in the past, and as a token that can be used to acquire goods or services in the future. Even gold would lose most of its value if it were suddenly priced based only on demand for use in industrial applications.
Money has always been valuable because everyone else treats it as money, whatever it is. It's a Schelling point that enables abstracted barter. Nothing less, nothing more.
That is precisely the problem we're trying to solve: allowing the public to take advantage of blockchain-based digital scarcity without anyone being forced to invest in speculative assets.
I'm actually trying to convince people that, if we accept the premise that blockchain technology can create digital gold (as the market has, to the tune of hundreds of billions of dollars) then we should harness that digital gold to protect the value of the money that everyone already owns, rather than setting the world on fire by launching new currencies that function like pyramid schemes.
I have no dog in the fight, and wish "enormity" had never developed a normative undertone, but I strongly disagree that said usage is anything close to archaic.
If you Google "enormity," the dictionary definitions it displays before the results are:
1.the great or extreme scale, seriousness, or extent of something perceived as bad or morally wrong.
"a thorough search disclosed the full enormity of the crime"
2.
a grave crime or sin.
"the enormities of the regime"
Merriam-Webster claims this is not the exclusive usage, and that enormity can mean "immensity" without normative implications when the size is unexpected. But the very example it cites, from Steinbeck, involves the "enormity" of a situation in which a fire was started.
That said, I agree that "enormousness" is an awkward word, which I do not use. I'm left to ponder the enormity of my own pedantry.
I've been waiting for Scott Aaronson to put all of this into perspective since the first leaks about Google's quantum supremacy started appearing in popular media.
He has exceeded my expectations with this post, which cuts through all the hype to communicate exactly what the results of this experiment mean for the field. It's worth reading and sharing.
Lead author here. This paper does a few things that HN may consider interesting.
1. It formalizes new security vulnerabilities in Bitcoin and other cryptocurrencies. Notably, it shows that all of these protocols repeat a simple statistical error that was introduced to the literature in the early 2000s.
2. It demonstrates how "honest majority" axioms can be replaced with a more rigorous formal method, which incorporates techniques from game theory and microeconomics to prove security from first principles.
3. It applies biological models to trust-minimized networking. By replacing handicap-authenticated signaling with cue-authenticated signaling, it obtains an exponential improvement in security and performance.
4. It proposes a cryptographic twist on the gold standard, which can deliver all the advantages of cryptocurrencies (inflation protection, smart contracts) without forcing society to abandon the existing monetary system.
In a sense, it's an alternate form of Proof-of-Stake. As Section 8.4 explains, the conventional wisdom is that Proof-of-Stake's flaw is that it's circular. We've proved that actually it's not circular enough, i.e., the stakes it assigns are different than the stakes in society's existing monetary game.
Proof-of-Balance allows "stakes" (what we call "weight") to be issued in proportion to monetary balances. Once those stakes are in users' hands, the protocol can run using the algorithms designed for PoS, including all of their reward and governance mechanisms.
It turns out that to fully unleash the power of those algorithms, you need a verifiably secure stake-distribution mechanism. That's what we've invented. (It's harder than it sounds, of course...)
1. In our use of coding agents, we find that there are often things referenced earlier in the conversation (API keys, endpoint addresses, feedback to the agent, etc.) that it's useful to have persist.
2. This is a general-purpose LLM memory system, which we've just used here to build a coding agent. But it is also designed for personal assistants, legal LLMs, etc.