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 percent on ARC-AGI-3, beating the human expert baseline of 95.4 percent. That is 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 is the only way to know what is really going on.
I went in with a few questions. Here is 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 would 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 is 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, and they are still there.
Most agents treat the context as the state. Prime Agent does not. 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 is not the context. The state is what is living in the IPython kernel. That is 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, which makes it powerful but also fragile in a way the marketing does not mention.
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 is 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 is the recursion.
It is clever. But it is not magic. Any framework that lets you pipe one model call into another has the same shape. What is unusual here is that the wiring is ordinary Python instead of a config file, which means the agent can rewrite its own orchestration without asking a human to edit a YAML file.
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 is already running in the background. It is not changing some abstract set of model weights. It is 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 is running, so it does not lose what it learned.
It is a neat way around the stateless-agent problem. But it is still Python code being updated over time, and a long-running interpreter is exactly the kind of thing that breaks in production if nobody is watching it.
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 do not 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 is not intelligence, and a benchmark score is not the same as capability.
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 is 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 cannot tell the two apart.
Prime Agent dropped just a few days ago. This is my first pass through the code. The IPython-as-state choice is the part I would watch most closely, because it trades inspectability for elegance, and that trade is not free.
The marketing will keep saying AGI. The code says something more modest and more useful: a clever way to keep state and orchestration in one place, where the agent can rewrite both at runtime. That is worth studying even if the headline is wrong, because the underlying idea will show up in other frameworks soon.
I will keep digging and post more if I find anything interesting.
