Alex Zhang

I think this is an unsolved problem. The most interesting thing I saw here is the Recursive Language Models paper. https://arxiv.org/abs/2512.24601 There's also a great write up here by the author: https://alexzhang13.github.io/blog/2025/rlm/

When an agent processes information, it needs somewhere to put it - somewhere it can search, reorganize, and grow organically. For any type of knowledge base like agent memories, product taxonomies, etc the challenge was enabling recursive interaction without a pile of specialized tools (search, create, delete, etc.) that are added to context. Recursive Language Models (RLMs) introduced the idea of putting the entire context into a Python variable and let the model recursively interact with it, instead of reasoning over everything in one shot. RLMs: https://alexzhang13.github.io/blog/2025/rlm/. I really liked it, but enabing a python REPL seemed like a bad tradeoff for generality. Loopy imposes a known structure (a tree / filesystem), and replaces the REPL with composable Bash-style commands. Why this approach: - simple - a single string can represent the full data - known structure - stored in a file system format agents already know and love - composition - compose search commands to quickly navigate the data

Not exactly. See: https://alexzhang13.github.io/blog/2026/mgh/

I had some ideas for extending the lem editor (emacs in common lisp) the other day and I am barely literate in Lisp. So I had Claude Code do it. Fully awesome. No problems. A few paren issues, buit it seemed to not really struggle really. It produced working code. Was also really good at analyzing the lem codebase as well. I even had it write an agentic coding tool in Common Lisp using the RLM ideas: https://alexzhang13.github.io/blog/2025/rlm/ Lisp is a natural fit for this kind of thing. And it worked well. (I also suspect if parens were really a problem... there's room here for MCP or other tooling to help. Basically paredit but for agents)

Reasoning is recursive - you cannot isolate where is should be symbolic and where it should be llm based (fuzzy/neural). This is the idea that started https://github.com/zby/llm-do - there is also RLM: https://alexzhang13.github.io/blog/2025/rlm/ RLM is simpler - but my approach also have some advantages.

here's a more readable version: https://alexzhang13.github.io/blog/2025/rlm/

The whole thing was borne out of wanting to keep costs low! My favoured approach (last time I was doing this) is using only a tiny sliding context window based on message pairs, rather than tokens, and only for the agents that need it. Amending prose style, for example, shouldn't need context beyond the message it's working on, and then its system prompt. For the models that require context, I personally found combining a tiny sliding window with a lazy version of the "Recursive Language Models" approach broke immersion least often and had a significantly lower cost. That + the "Id noise" + the strict agents also allowed cheaper models to overperform for me personally. My lazy version of the RLM approach is basically just giving the agent a grep tool across the full message history & "lore" documentation created by agents, combined with repeated, low-context turns, and a "submit answer" tool for when it felt like it had finished working. When I looked at the internals of what each agent turn looked like, it did look like a complete mess - but the context window only needs to surface the things it actually needs to know each turn. Short outputs help a lot with immersion, too - brevity means there is a lot less you can get wrong, and also aids response time & cost. It does take me an awful lot of prompt tuning to get what I want creatively from LLMs in any format, especially weaker models working in this chain, but I think that's likely always going to be true. Art can…