> The key insight is that long prompts should not be fed into the neural network (e.g., Transformer) directly but should instead be treated as part of the environment that the LLM can symbolically interact with.
How is this fundamentally different from RAG? Looking at Figure 4, it seems like the key innovation here is that the LLM is responsible for implementing the retrieval mechanism as opposed to a human doing it.
My wishlist for 2026: Anthropic / OpenAI expose “how compaction is executed” to plugin authors for their CLI tools.
This technique should be something you could swap in for whatever Claude Code bakes in — but I don’t think the correct hooks or functionality is exposed.
Isn't this just subagents? You call another LLM to go read a file and extract some piece of information or whatever, so that you don't clutter up the main context with the whole file.
Yeah, from the title, it sounds like perhaps the entire operation is differentiable and therefore trainable as a whole model and that such training is done. However, upon close inspection, I can't find any evidence that more is done than calling the model repeatedly.
> RLMs are not agents, nor are they just summarization. The idea of multiple LM calls in a single system is not new — in a broad sense, this is what most agentic scaffolds do. The closest idea we’ve seen in the wild is the ROMA agent that decomposes a problem and runs multiple sub-agents to solve each problem. Another common example is code assistants like Cursor and Claude Code that either summarize or prune context histories as they get longer and longer. These approaches generally view multiple LM calls as decomposition from the perspective of a task or problem. We retain the view that LM calls can be decomposed by the context, and the choice of decomposition should purely be the choice of an LM.
Yes! Contrary to the anthropomorphized subagents, I view them as ways of managing context primarily. I'm exploring this idea in Scope[0] to have observable subagents that recursively break down the task to avoid having to compact. One thing I haven't been able to figure out is how to evaluate/improve this planning step. I am using markdown files to encode heuristics for planning but it feels too unstructured for me to measure. Would love it if someone pointed me to some existing literature/projects around this idea!
13 comments
[ 2.7 ms ] story [ 40.7 ms ] threadHow is this fundamentally different from RAG? Looking at Figure 4, it seems like the key innovation here is that the LLM is responsible for implementing the retrieval mechanism as opposed to a human doing it.
This technique should be something you could swap in for whatever Claude Code bakes in — but I don’t think the correct hooks or functionality is exposed.
I have read the gemini source and it’s a pretty simple prompt to summarize everything when the context window is full
Neat idea, but not a new idea.
> RLMs are not agents, nor are they just summarization. The idea of multiple LM calls in a single system is not new — in a broad sense, this is what most agentic scaffolds do. The closest idea we’ve seen in the wild is the ROMA agent that decomposes a problem and runs multiple sub-agents to solve each problem. Another common example is code assistants like Cursor and Claude Code that either summarize or prune context histories as they get longer and longer. These approaches generally view multiple LM calls as decomposition from the perspective of a task or problem. We retain the view that LM calls can be decomposed by the context, and the choice of decomposition should purely be the choice of an LM.
[0] https://github.com/adagradschool/scope