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” — and nobody seemed to actually know what those meant. They were repeating the press release.
So I cloned the repo and read the source code. 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 that actually looks like in practice.
Turns out, not that special.
It sends the LLM the same kind of request you’d see from any other agent. The Context interface looks like this:
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:
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, 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 a real difference, and it carries a consequence worth naming: the agent’s memory is a process. Kill the kernel and it forgets what was in there — not just the conversation, but the working structures it built along the way. Most frameworks keep state somewhere you can inspect and restart. This one keeps it inside a live interpreter.
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 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, it generates Python code like this inside an IPython cell:
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. Any framework that lets you pipe one model call into another has the same shape. What’s unusual here is that the wiring is ordinary Python instead of a config file — which means the agent can rewrite its own orchestration.
What is Continual Harness?
Once you understand that IPython is Prime Agent’s only tool, Continual Harness makes sense.
Everything Prime Agent does runs as generated Python inside that environment. So “continual improvement” just means modifying Python that’s already running in the background. It isn’t changing some abstract set of model weights. It’s rewriting its own code based on its history.
Think of it as persistent knowledge baked into the execution environment. The agent can look back at what it did earlier and adjust the code it’s running, so it doesn’t lose what it learned.
It’s a neat way around the stateless-agent problem. But it’s still 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.
I can see how this architecture improves efficiency. Persistent state cuts redundant work. Recursive subagents can be parallelized. But efficiency isn’t intelligence.
My gut says Opus 5 is doing the heavy lifting here. Prime Agent provides a better scaffold for ARC-AGI tasks, but the “smart” part still comes from the underlying model. Swap Opus 5 for something weaker and I doubt the agent magically fixes it.
That distinction matters more than the headline number, by the way. It’s the same confusion I ran into looking at where DeepSeek’s harness is pushing agent design. A better harness can make a model look smarter without making it smarter, and a benchmark chart can’t tell the two apart.
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.
