OpenClaw is the fastest growing github repository of all time. It has over 200k stars, 400k lines of code and over 4k open pull requests. Agent driven development has led to an explosion of people who can contribute, but it also has resulted in a lot of slop. The creator and maintainer team cannot keep up and current solutions don’t work for a repo of this scale. Today nothing triages these PR’s effectively at the current scale.

Attempt #1 Agent Swarm

My first instinct to solve this problem was to leverage clawdbots to enter a decentralized network of coders and reviewer adversaries. My intuition was that if clawdbots were submitting PR’s they should also be required to participate in reviewing and triaging PR’s from other agents. At a high level the agent github was a network of agents that read from a shared task queue to ensure the agents picked up unique coding or reviewing tasks and the agents didn’t do duplicate work. Internally it was coordination backend with consensus voting, reputation scoring and a clean interface for OpenClaw agents to register and operate autonomously. The results of this were 70 code changes for OpenClaw that greptile gave a 4 or 5 in readiness and most of the CI steps passing.

In actually trying to merge some of those 70 changes I saw that the bottleneck for OpenClaw maintenance is that there are thousands of issues and PR’s of varying quality. The agent swarm cost me ~200$ in tokens and only 1 PR ended up merged because of a ping I got from another developer about the fix being useful to them. The decentralized approach is inviting as we can use blockchain principles to get consensus on whether a PR is ready for review. However, the bottleneck for that is getting OpenClaw agents sign up for the network and getting native support in the repository. This kind of solution requires too much setup from the maintaners and its not clear if this would even solve this problem.

Reviewing individual PR’s required additional scaffolding to cluster similiar changes and is expensive to run as each agent processes the full codebase per PR. Ideally the task we give the model includes the full codebase, all the PRs and all of the issues which blows past 1M tokens.

Attempt #2 Recursive Language Models

Recursive Language Models (Zhang, Kraska & Khattab, 2024) solve the long-context problem by putting the data in REPL variables. The model writes code to explore them, using queries to split up the data and delegate reasoning to sub-RLM nodes. The model decides what to look at rather than reading it linearly. This paper showed that Qwen3 8B parameter model approached GPT-5 level performance on long-context tasks while using exponentially fewer tokens. As a result they seem to be a good candidate for triaging and ranking the PR’s to review.

My approach was to take a frontier model like Sonnet 4.6 and Opus 4.6, not the papers fine-tuned RLM-Qwen3, with the RLM paradigm to get the benefits of state of the art coding agents and the context efficiency.

I used a seperate job to pull the latest version of open claw, all of its issues and PR’s (with diffs) and store it locally.

We setup a dashboard and are tuning the prompt + tools based on the quality of the output. The task definition I setup is that this task should output a ranking of PR’s scored on quality, urgency and review readiness.

So far we have tried a few versions with varying results. None of these runs cost > 5$

1. Naïve Version

This version uses a very simple prompt instructing the agent to triage low quality PR’s and rank the PR’s based on quality and urgency. In this run the agent extracted the metadata for each PR and then only used that metadata to provide the scores. In ran very quickly and used <20k tokens of context. The model in this case skipped deep analysis of the code and how the PR connects and tried to hack a reasonable output result.

2. Require Codebase understanding

This iteration updated the prompt to instruct the model to ground its decision in the actual codebase and understand the PR/Issue in context of the code. This resulted in the RLM actually understanding the codebase, but when it came to analyzing the code changes it had almost no differentiation in scoring them. It gave most decent PR’s a quality rating of 9 and it was not effective in triaging PR’s that don’t need to be reviewed. We tuned this approach a few times in order to give strict guidance on what the scores meant, but in general this approach struggled to produce meaningful differentiation between PR’s for ranking.

3. Pipeline with adversarial roles

The next iteration in forcing the model to create this curated list we built a structured pipeline that the RLM was prompted to follow. This was a rigid 4-phase pipeline which explicit instruction on how to understand the codebase, analyse the different PRs, using an adversarial review trying to reject the PR and finally a synthesizer to generate the final output. The rigid pipeline produced results with clearly differentiated scores, but looking deeper we lost most of the benefits of the RLM approach as each phase in the pipeline acted as an independent RLM call. This resulted in the pipeline taking a long time and not being very context efficient across the different phases. The next iteration needed to stay more grounded to the papers approach of treating this task as a single RLM node that can spawn sub-RLM nodes.

4. Simpler prompt with more guidelines

Root RLM prompt went from 800 words to just a few lines.

"Triage all open PRs in this repository and produce evidence-backed scored rankings. Use delegation-first RLM flow:
  orchestrate at root, collect evidence in delegated subcalls, then synthesize."

This produced results that had a reasonable distribution of scores and when manually inspecting the PR’s suggested to review it seemed reasonable to have that score. Here is a distribution of 74 PR’s analysed.

The 2 PR’s ranked > 9 were critical fixes that were identified by cross-referencing the dependency graph.

One major issue with this run was that there was no way to look into the agents reasoning as to why it made its decision on the dashboard. For maintainers its not clear why something is a 9.3 vs a 9.1 and more observability into the agents decision making is needed.

5. RLM vs Sub-RLM prompt and tool differences

In the previous versions we use one RLM prompt for the RLM and the sub RLM, but this doesn’t align well with the paper. The paper using different tasks and tools between the root RLM’s prompt and the sub RLM’s prompt. This direction allows us to give the sub RLM more coding specific prompt and tools. This run short circuited because the root node’s prompt did not have the tools to get PR/Issue metadata so it concluded that there were no PR’s to process. However looking deeper, the model shows that it will not hallucinate the scores as shown and if it doesn’t have the PR data it will produce empty triage result.

Cannot produce evidence-backed triage without actual PR
  data. Producing empty triage result per honest evidence-only policy

Learnings

RLM’s are capable of efficiently analysing a codebase + PR’s to triage them with reasonable quality (manually verified 10 random PR’s and compared my assessment to the agents). It is worth to try to scale out this approach to for all 4k PR’s, but we need to also add automated evals to assign a quality metric to the system. This approach also doesn’t handle the dynamic nature of codebases well, a run that takes 10 minutes to complete could become partially stale on a repo like open claw.

Future direction

The limitation of the current approach is that every run throws aways it work. The RLM processes the entire codebase, reasons over 4k PR’s and builds a structure understanding and discards it. The next run starts from scratch and when a new delta comes in the analysis becomes stale.

The recursive tree the RLM produces is already a structured decomposition of the codebase and its issues. Persisting that tree as a knowledge graph means each sub-node becomes a cached reasoning step. Containing the files analysed, conclusions reached and when it was last updated. When a new delta arrives we retrieve the affected sub-nodes and only re-reasons on those with new context added. The rest of the graph should stay intact.

The root node of any RLM can be viewed as a sub-node in a larger unknown graph, like a proof by induction treats the base case as an instance of the general case. The graph grows and updates itself incrementally instead of being rebuilt everytime. The end goal is a platform that keeps a live, reasoned ranking of PR’s that doesn’t go stale.

The Relayer App is powered by the agent, which serves as an interface that manages the workspace and user session via interface graphs. Interface graphs are what the user sees in the app. Interactions such as selecting an action, opening a node, or speaking to the agent are processed in real time.

Local MCP servers write to the conversation and workspace graph, and are a critical improvement for the graph creation. They allow the interface graph to be streamed to the user as the tool is repeatedly called during reasoning. The MCP server also embeds the strict node and turn logic to ensure the agent adheres to the instructions and builds graphs that are usable in the frontend. There is a fine balance in these validation rules, but we currently optimize for coherent nodes and infinite interactivity. At any given point in the app, there should be places to go and things to do.

As these graphs are built, a vector index is constructed using the FAISS library for simple retrieval and deduplication. This allows the agent to quickly search pre-computed reasoning and also provide ground truth for the workspace or conversation state. When the user interacts with a node, the agent can see related nodes and consider those in context when understanding the action. This allows the agent to connect the dots between sequential actions and build a coherent conversation that moves forward while remembering short and long-term context.

For a responsive user experience, actions are processed quickly, and heavy reasoning tasks are handled by a pool of workers, allowing us to balance latency and compute. Depending on the state of the session, we allocate more workers to the turn task queue as that is relevant to the users’ current queries. When the user is not connected and there are no active threads, the workspace graph building will take priority. Within a single thread, we can also process one set of actions at a time, avoiding race conditions when writing the graph. As a result, the task queue will accumulate actions per thread, allowing us to reduce the number of overall agent calls and reach the desired state sooner.

The node expansion queue is a recursive process that starts at the workspace's root. Each agent's turn for node expansion outputs a list of (node label to expand, priority score). This feeds back into the expansion queue, so the workspace graph is continuously built by order of importance. The agent uses signals such as node depth, user interaction history, and current conversation topics to determine which nodes to expand and to predict what information the user may want to dive deeper into.

The agent-as-interface approach is currently being applied for development, using the codebase as the workspace. Still, the infrastructure is generic and can be applied across different knowledge-work domains. Graphs, nodes, and state machines are base objects, and the future direction is to expand the ways the agent can represent information and complete tasks, making this technology more effective across a range of scenarios.

In the case of AI coding tools, a 2025 METR study found that people are about 19% slower with them than without. Factors in this include the review burden or time spent babysitting AI (time spent reviewing or fixing AI code/time spent writing prompts), technical complexity accumulation, and silent regression rate. The amnesic, brown-nosing experience of current tools limits the effectiveness of the human-AI relationship in high-context settings.

I propose that to get the most out of these costly models, an intelligent interface is needed. This intelligence needs to adapt to the user’s skill level, previous experience, domain, task, device, and other factors to build the optimal interface for the user to accomplish their goal.

Today’s AI tools are largely extensions of pre-2020 workflows, simply appending a chat window or IDE plugin to existing applications. These are effective, but feel old. Let’s take software development as one of the areas with the most innovation in AI tooling, for example. Cursor, Antigravity, and GitHub Copilot all run on Visual Studio Code, an editor that launched in 2016, and it is also the key dependency that competitors of GitHub Copilot have. Claude code, codex cli, and warp are all based on your terminal, and while Claude code is my tool of choice, the terminal is an old interface. Lovable, Superblocks, Bolt, and Replit are AI app builders that take a no-code approach to building. There's a lot of innovation in their interfaces, but chat remains a key modality, and they're not targeted at experienced developers.

In the current landscape, there isn’t a fresh, new interface for experienced developers to accelerate their development. Desktop tools are limited by their own success; their existing efficiency makes radical change difficult, but mobile presents the opportunity to reimagine the interface. We are targeting experienced mobile developers because a solution that works there will be more transferable to desktop and accessible to all skill levels.

Speaking with experienced developers across the industry, I found that precise enterprise-level code changes, especially in languages like C++, are not yet reliable with AI today. Many experienced developers can’t envision a mobile interface they would use instead of their laptop. At most tech companies, even if the hours are 9-5 or even 9-9-6, the system doesn’t sleep. A ping could come in at any moment, and for many people, work-life balance is a struggle. At Microsoft, countless peers' weekends, post-work dinners, vacations, and general free time were interrupted by pings or tasks. To avoid this fate, my phone became the tool to unlock my free time. I would plan my builds and tests around cooking dinner, or take my phone to the gym and use the code explorer to help solve different issues, or even write code, so the result would be ready later. All of these interfaces sucked. Coding on your phone doesn’t work, but with the right interface, software engineers will be more productive and won’t have their life interrupted by using their laptop for work.

This is why we are building the Relayer Agent: the agent that builds an interface that adapts to the user and represents their workspace and conversation as a graph. Instead of relying on the static chat window where users must craft the perfect prompts for context, the agent chooses the optimal UX for each layer and state in the graph. This approach creates ‘implied context,’ allowing for complex workflows even on constrained devices. This agent powers the Relayer App, which lets you code anywhere. By giving the agent full control over the interface, users can navigate, edit, and review code using AI with laptop-like precision while eliminating the friction of chat.

The Workspace and Conversation Graph are MCP servers that handle the agent emitting a graph delta. They decide which graph to write to, which parts of the graph to send to the frontend, and how to handle user interactions on different nodes. During the reasoning, we use standard search tools like keyword, faiss, and by node location in the filesystem/conversation. This technique converts the agent from a conversation-based to an action-based approach, acting as an interface as it manages context across large codebases and complex tasks.

The dynamic interface breaks down the codebase layer by layer, ranging from a macro-scale (architecture) to a micro-scale (raw code), and including a middle ground (pseudo-code).

Subscribe now