The hype around Prime Agent is getting ridiculous.
People are calling it the next step toward AGI. Some claim that with Opus 5, it scores 95.5% on ARC-AGI-3, beating the human expert baseline of 95.4%. That’s a big number. But I kept reading the same talking points everywhere—”RLM,” “Continual Harness,” “prompt-as-a-variable.” Nobody seemed to actually know what those meant. They were just repeating the press release.
So I cloned the repo and read the source code. Because that’s the only way to know what’s really going on.
I went in with a few questions. Here’s what I found.
What Does Prime Agent Actually Send to the LLM?
A lot of the coverage made a big deal about Prime Agent’s context being “variables.” I was curious—what does that actually look like in practice?
Turns out, not that special.
Prime Agent sends the LLM the same kind of request you’d see from any other agent. The Context interface looks like this:
text
interface Context {
systemPrompt?: string; // the assembled system prompt
messages: Message[]; // user / assistant / toolResult messages
tools?: Tool[]; // tool definitions with TypeBox schemas
}
The only tool available is IPython. Every request includes a tool definition like this:
text
tools: [{
name: "ipython",
description: "Execute Python scratchpad code and `%%bash` shell cells in a persistent IPython kernel...",
parameters: Type.Object({
code: Type.String({ description: "Python scratchpad code..." })
})
}]
There’s a running joke in the agent community: if you can only pick one tool, make it bash, because you can do everything with shell commands. IPython does the same thing—but with one advantage. Variables persist across calls, just like in a Jupyter notebook. You run one cell, the variables stick around. You run another cell ten minutes later, they’re still there.
Most agents treat the context as the state. Prime Agent doesn’t. It keeps its own internal state in the IPython environment, then calls transformMessages to convert that state into the context before sending it to the LLM.
So the state isn’t the context. The state is what’s living in the IPython kernel. That’s different.
What Is RLM, Really?
The README says:
The Recursive Language Model (RLM) treats context as variables (prompt-as-a-variable) and tools like recursive subagents as function calls inside a persistent REPL.
“Prompt-as-a-variable” is literal. The prompt is just a Python variable. Prime Agent can modify it directly, changing what gets sent to the LLM on the fly.
Here’s the interesting part: recursive subagents as function calls.
In practice, Prime Agent generates Python code like this inside an IPython cell:
text
api_code = await rlm(f"code the {requirements}", name="api-code")
review_code = await rlm(f"review the code {api_code}", name="code-review")
audit = await rlm(f"audit {api_code} + {review_code}", name="audit-reviewer")
Each rlm call spawns a new subagent in a fresh cell. The string you pass can include variables from previous calls. So one subagent’s output feeds into the next one’s prompt. That’s the recursion.
It’s clever. But it’s not magic.
What Is Continual Harness?
Once you understand that IPython is Prime Agent’s only tool, Continual Harness makes sense.
Everything Prime Agent does runs through generated Python in the IPython environment. So “continual improvement” just means modifying the Python code that’s already running in the background. It’s not changing some abstract model weights. It’s rewriting its own code based on history.
Think of it as persistent knowledge that’s baked into the execution environment. The agent can go back, look at what it did earlier, and adjust the code it’s running. That way, it doesn’t forget what it learned.
It’s a neat way to avoid the “stateless agent” problem. But it’s still just Python code being updated over time.
The Bottom Line
Prime Agent’s architecture is fresh. Using IPython as the state store is a creative move. The recursive subagent pattern is elegant.
But I don’t see anything that looks like a breakthrough toward AGI. Not even close.
Here’s the thing: I can see how this architecture improves efficiency. The persistent state reduces redundant work. The recursive subagents can parallelize tasks. But efficiency isn’t intelligence.
My gut feeling is that Opus 5 is doing the heavy lifting here. Prime Agent provides a better scaffold for solving ARC-AGI tasks, but the “smart” part still comes from the underlying model. If you swapped Opus 5 for something weaker, I doubt the agent would magically fix it.
Prime Agent dropped just a few days ago. This is my first pass through the code. I’ll keep digging and post more if I find anything interesting.
