Prime Intellect is one of my favourite companies of this era.
I remember when they released one of their first products, a publicly available RL environment. Their mission was something close to “AI can be built by everyone.” I don't remember the exact sentence, and I don't want to pretend I do, but I remember loving the idea. There is no doubt in my mind that Prime Intellect will become the Oracle of this generation of technology companies.
Until yesterday, I admired Prime Intellect more as a company than as a user of its products. Their work was cool, although most of it was made for a small group of people who already knew why it mattered. Then they released Prime Agent.
I have no words to explain how much I love it.
Programmatic tool calling is heaven to me. I have wanted to build agents this way for a long time and couldn't find the right shape for it. Prime Agent gives the model a persistent IPython environment. The model writes code to inspect its context, call tools, use subagents, and keep working. It doesn't have to wait for somebody to keep stuffing a new tool definition into its prompt every time it needs to do something.
Prime Intellect found the right way to do it. Alex Zhang, an MIT PhD student and one of the funniest trolls on my Twitter feed, came up with the idea and called it Recursive Language Models. An RLM can treat its context as data inside a Python REPL, inspect pieces of it, call other models when it needs them, and bring the useful parts back. Prime Agent turns that research idea into something I can download and use.
I think it is time we accept that, at least for coding, we may have reached the point where the next foundational model will not feel like a giant jump. Models will get better at hallucinations, tool calling, and long-running tasks. Every serious lab will eventually have a good model. Having the model will stop being enough.
Now we get the war I actually care about: who can build the best agent around it? Who can give a model memory, tools, other models, and enough freedom to keep working without turning the whole thing into a brittle pile of prompts? Public models have reached the door. The next fight is over what we build on the other side of it.
The story stops here
A model takes tokens and predicts more tokens. By itself it can't open a repository, run tests, remember yesterday, wait for a job, or send another model off to investigate something. The harness supplies those abilities and decides what goes into the context, which tools are available, how results come back, what survives compaction, and when the model gets another turn.
Claude Code and Codex are both harnesses. Every coding agent is a model inside somebody else's decisions about context, tools, permissions, memory, and the loop that keeps calling it. A bad harness can waste a great model. It can dump pages of old terminal output into the context, hide the file the model needs, erase an important decision during compaction, or spend half the prompt describing tools.
Prime Agent's main decision is to give the model a persistent IPython process and use Python as the control surface. The model can leave data in variables, inspect a large input in pieces, transform it with normal code, and call subagents from the same place. It can split a repository or a research question across fresh contexts and collect the answers without dragging all the source material through its prompt.
Long prompts cost more and become harder for the model to use. Putting two hundred thousand tokens in a prompt does not mean the model will find the right ten lines. An RLM keeps the large object in Python, searches or splits it there, and prints only the pieces it needs into the prompt.
Five hundred support conversations
Give an agent five hundred customer-support conversations and ask why people cancel. A normal agent reads them in batches. By conversation three hundred, the complaint in conversation seventeen is still there, but it is easy to miss.
With an RLM, the folder stays outside the conversation. Python can list the files, search for recurring terms, divide them into groups, and send each group to a fresh agent. The main agent reads ten reports. If one looks strange, it opens the original conversations and checks.
Ordinary tool calls go through the host one at a time. The model emits a JSON call, the host runs it, the result goes into the conversation, and the model gets another turn. Prime Agent lets the model write a program that branches, loops, checks return values, and keeps temporary output in Python. I have wanted agents to work this way for a long time.
Take ten tests and retry only the failures. Ordinary tool calling needs a model turn for every test: request, output, another model turn, repeat. In Prime Agent, the model writes the loop once, runs all ten tests, retries the failed names, and prints the final list. Only that list has to enter the model's context.
The continual harness
The continual harness is the riskier part. Prime Agent can update some of the
instructions around itself while a job is still running. It stores prompt notes,
memories, skill descriptions, and reusable subagent specs. After a real failure,
/refine can propose a small change to that state. The system prompt
remains fixed, and every proposed change gets a reason, a snapshot, and a rollback
path.
Save every observation and the memory becomes a landfill. Let the model silently rewrite its system prompt and one stupid lesson can contaminate every later task. Prime handles harness learning like a code change: leave the core alone, review the patch, record the reason, and make rollback easy.
Pokémon explains the idea better than coding does
The Continual Harness paper started with agents playing Pokémon. Humans watched the failures and improved the surrounding software: clearer instructions, battle and puzzle specialists, useful memories, and scripts for repeated actions. With that help the system finished Pokémon Blue, Yellow Legacy on hard mode, and Crystal.
Eventually the agent began writing some of those improvements itself. It built pathfinding tools, developed battle strategies, and saved a truth table for a switch puzzle it would otherwise solve from scratch each time. The researchers made that behaviour into a loop: play, inspect the failure, change the relevant instruction or tool, and continue from the current save.
The game kept going from the same save. A coding agent can't restart a six-hour migration whenever it learns a better way to inspect the database; whatever it learns has to help before the job ends.
Prime Agent also includes the dull infrastructure required for long jobs. A daemon keeps agents alive after the terminal closes. Goals survive turns. Heartbeats and schedules wake agents back up. Compaction prevents a large conversation from ending the session. Subagents can stay alive, exchange messages, and report later. Skills are Python packages the model can run directly.
The software underneath
None of that requires a new model. The persistent REPL is a process. A subagent is another model call with its own context. Memory is data on disk. A daemon keeps processes alive. Snapshots and rollback have existed forever. Prime built an interface that lets the model drive all of them from one Python environment.
The benchmark results
Prime tested three setups: a normal model, an RLM, and an RLM with instructions on how to use the extra machinery. They ran fifty attempts per setup across research, math, long-context reading, and exact copying. The RLM usually scored better. Math was the clear exception, and DeepDive only improved after Prime supplied a strategy.
Every RLM setup ran slower. Some child agents produced piles of text and burned tokens. In other runs the main agent wrote code it didn't need and took the scenic route to an easy answer.
They also tested their own INTELLECT-3. It used roughly as many tokens as GPT-5-mini for less reward, and on the math task it could barely use the RLM setup at all. I respect Prime for publishing that. INTELLECT-3 had access to the same machinery and mostly misused it on math.
Prime wants to teach this behaviour through reinforcement learning. I think that is the right approach. Handwritten instructions will only get longer and more brittle. Prime Agent already shows how much apparent model capability comes from the harness.
I had sketched a similar architecture a few months earlier, built on Bun and TypeScript, with a more aggressive rule: the model gets one tool. I left it as a document because I thought the idea was stupid. Prime Agent is the first reason I have had to reopen it. Now I want to build the thing and find out where I was wrong.
One tool called execute
Most harnesses grow a new tool for every capability: shell, file reading, editing, search, web access, messages. Each one adds another schema the model must choose and fill out. Then it waits for the host, reads the serialized result, and chooses again.
My design hides that whole menu behind one tool called execute.
Execute runs TypeScript in a persistent evaluator. Shell is Bun.$, Pi's
existing tools live under tools.*, and a subagent is a function that
returns a handle. The model uses those pieces in a program.
Variables survive between turns. The model can keep a subagent handle, inspect a result, loop over files, call several tools at once, and return to the same evaluator later. Loops and branching stay in the program, which saves a long sequence of chat turns.
I call it a single-tool Pi. Pi still runs the agent loop and supplies the capabilities. Bun supplies TypeScript, the shell, and promises.
Why TypeScript and Bun?
I chose TypeScript because Pi is already written in it. Its tools already look
like JavaScript functions, Bun runs TypeScript directly, and Bun.$ makes
shell commands easy to compose. Keeping the evaluator in the same language avoids
building another integration layer.
Promises make subagents much nicer. A subagent can return a handle immediately and continue in the background. The parent can start two investigations, work on something else, and inspect either result later. One slow child no longer blocks the entire agent.
The model already knows how to write loops, conditions, functions, exceptions, promises, and arrays. Forcing the same logic through isolated JSON tool calls adds ceremony and throws away a language it already speaks.
Intermediate output can stay there too. A search across two hundred files may produce two hundred results. The evaluator can filter them, keep the useful objects in memory, and print five lines back into the conversation.
The parts that can go horribly wrong
execute would be extremely powerful. It could run shell commands,
edit files, use the network, and start agents, so each function under
tools.* still needs the original permission checks. TypeScript around a
dangerous action changes nothing about the danger.
Persistent state preserves mistakes. Bad variables survive. Dead agent handles stay in memory. The model can write an infinite loop, print a gigabyte, or start too many children. The evaluator needs timeouts, output limits, cancellation, snapshots, and a way to wipe the state and start clean. Prime Agent convinces me the interface is worth trying. I still have to build the safety mechanisms.
Prime uses IPython for the same idea. I use Bun because Pi is already TypeScript.
When I call Prime Agent "not that big of a deal," I mean it as praise. You don't need a new foundational model or a GPU cluster to build it. A small team can make a model much more useful with ordinary software and very good judgement. I love that.
What I would use
All four systems can make an AI work on code; they give it very different amounts of control.
| System | How it works | Benefits | Downsides |
|---|---|---|---|
| Claude Code/Codex | The model chooses from named tools for files, search, edits, and shell commands. | Available now. Each tool has its own permission boundary, so approvals are easy to understand. | Every step needs another model turn. Large tool results go straight into the conversation and can bury useful context. |
| Prime Agent | The model writes Python in a persistent IPython process. That code can inspect data, call tools, and launch subagents. | It can filter large inputs outside the prompt, run subagents in parallel, and keep state across long jobs. | Often slower and more expensive. The model can waste time writing code or launching children it did not need. |
| Single-tool Pi | The model would see one execute tool and write TypeScript inside a persistent Bun evaluator. |
Loops, concurrency, shell commands, and subagents stay in one program. | I haven't built it yet. A persistent, all-powerful evaluator is difficult to secure and clean up after. |
| Anode | The model can use named tools or call the same tools from a persistent Python process. | It supports either style, works across model providers, keeps background jobs alive, and records what happened. | More code, more state, and two ways to do the same job. Real users haven't tested it yet. |
Claude Code and Codex
Claude Code can push noisy work into separate agent conversations. Those agents can now create their own agents, up to a depth limit, and each can have a smaller set of tools. That makes sense. A test runner needs the repository, the shell, and a clear job. Giving it every tool in the main agent only creates more chances to screw up.
Codex is
experimenting with something close to execute. In code mode, the
model calls tools from JavaScript, while the usual safety hooks still run for every
call inside the script. The feature is off by default and unfinished, but Codex is
already moving tool calls into code.
Anode
Anode already has both interfaces. The model can call named tools directly or open a persistent Python environment where those tools appear as functions. Python does not bypass approval. Every request returns to Anode's Go code, gets checked, runs, and leaves a receipt.
Anode stores its agents in a small local database: which agent created each child, their messages, results, saved files, and cost. Background work continues after the terminal closes. After a crash, Anode reads its journal and refuses to repeat an unfinished action silently. Once an agent can edit a repository, crash recovery has to tell me whether an unfinished action already ran.
Ask the model what feels bad
One of my favourite things I did while building Anode was stupidly simple. I started it with the smartest model I could find and asked the model about Anode.
How do you feel inside this harness?
What makes you worse?
Which tools are annoying to use?
If you could change one part of this system, what would you change?
A trace shows me what the model did. Asking the model gives me guesses about why. It might say two tool descriptions looked identical, a result hid the field it needed, or the context was so full it lost the task. That is a ridiculously useful bug report.
I don't accept the explanation blindly. Models invent stories about their own behaviour too. I treat the answers as suspicions, check the traces, change one thing, and rerun the task. Sometimes the model asks for more tools when fewer would help. Sometimes it notices a tiny friction point I stopped seeing because I built it.
Today I would use Claude Code or Codex for ordinary coding work. Prime Agent makes more sense when the task is huge or the parent agent has to coordinate many children. I still have no idea whether my single-tool Pi will be simpler. Anode supports both styles, which gives it more range and a lot more complexity.
I shelved the single-tool design because I thought it was dumb. Prime then shipped a working version of the underlying approach. Fine. I have to build mine now and find out where it breaks.
The model will stop being enough
Model companies will keep releasing better models. For coding, I expect the visible jumps to get smaller. The larger gains will come from the software around the model: what it remembers, how it searches, how it runs code and other agents, and whether it can work for six hours without filling its own context with garbage.
Claude Code and Codex showed how useful a model becomes with a terminal and good file tools. Prime Agent gives the model a programming environment and control over its context. My single-tool Pi pushes the same idea further by putting every capability behind that environment. Anode is my attempt to make the whole thing safe enough for a real computer.
Which interface wins is anybody's guess. Having the best model will stop being enough. Prime Intellect finally has a product I want to keep using.