prime-agent: Prime Agent: The Open-Source Coding Harness That Treats Chat Like a Daemon
Prime Agent is built for long-running work, not one-off prompts. Its recursive sub-agents, continual harness, and persistent IPython kernel turn agentic coding into a background system you can reattach to and refine.
- Prime Agent’s real innovation is a control model that treats the agent as a persistent process, not a disposable chat session.
- Recursive sub-agents turn delegation into a first-class operation, so decomposition becomes part of the system rather than a prompting trick.
- The continual harness lets the agent accumulate operational memory about a project without retraining the underlying model.
- TypeScript orchestrates the loop, while a persistent IPython kernel gives the agent a stateful execution plane for long-horizon work.
Prime Agent is interesting because it changes the unit of interaction. You do not just ask it things and wait for an answer. You attach to it, steer it, let it branch work into sub-agents, then come back later to find the system still alive and still learning.
Not a Chat Window
Most coding assistants behave like a good conversation. Prime Agent behaves like a background service. That difference matters because the hard part of long-horizon work is not generating an answer once. It is preserving context, surviving interruption, and keeping state coherent while the task stretches across many turns.
| Product | Primary metaphor | Session model | Memory model | Sub-agent support | Best fit |
|---|---|---|---|---|---|
| Prime Agent | Background daemon | Persistent and reattachable | Durable harness state plus REPL state | Native recursive delegation | Long-horizon coding and research |
| Claude Code / Codex | Chat session | Turn-based | Mostly conversational context | Limited or external | Interactive coding help |
| Devin / OpenDevin | Autonomous worker | Task-centric runs | Agent state and logs | Framework dependent | Hands-off task execution |
| Cursor-style workflows | Editor assistant | Human-led sessions | Workspace context | Not core to the model | In-editor autocomplete and refactors |
That is why the project’s best framing is not “another coding copilot.” It is a system for supervising work that should not die when the tab closes.
The Recursive Core
Prime Agent’s most interesting move is recursive delegation. The parent agent can spawn child agents as callable units, which means decomposition is not a side effect of prompting. It is an explicit capability of the architecture.
Prime Agent is our open-source, self-improving coding harness built around two abstractions: the Recursive Language Model (RLM) and the Continual Harness.
The point of RLM is not just that the model can think harder. It is that the model can actively manage its own context, break work apart, and call back into itself through a structured loop. That makes the agent feel closer to a program than a prompt.
How the Agent Loop Actually Runs
Under the hood, the loop is a state machine. It transforms context, streams model output, parses tool calls, executes tools, checks whether to keep going, and aborts cleanly when needed. The important thing is that the loop is designed to survive interruption without leaving the system in a broken half-state.
async function runAgentLoop(agent, input, signal) {
const context = transformContext(agent.state, input);
const stream = await streamFn(context, { signal });
for await (const event of stream) {
if (event.type === 'tool_call') {
const result = await executeTool(event.call, { signal });
agent.appendToolResult(result);
}
if (shouldStopAfterTurn(agent.state)) {
break;
}
}
return finalizeTurn(agent.state);
}
That split between orchestration and execution is doing real work. TypeScript owns the control plane. Python, through the persistent kernel, owns the stateful execution plane.
The Continual Harness: Self-Improvement Without Retraining
Prime Agent’s continual harness is the second big idea. Instead of treating prompts, skills, memory, and sub-agents as fixed scaffolding, it exposes them as mutable state. The `/refine` loop then lets the system inspect what worked and update itself with small, evidence-backed changes.
Prime Agent executes model-generated Python and project commands with your user permissions. Its worker and kernel processes improve lifecycle isolation and recovery; they are not a security sandbox.
That matters because most agents reset to zero every session. Prime Agent is trying to learn the quirks of a codebase, a workflow, or a task class over time. It does not update model weights. It updates the harness around the model.
Why the Unified AI Layer Matters
If you support multiple model providers, you eventually need a Rosetta Stone. Prime Agent’s `packages/ai` layer normalizes streaming, model metadata, context windows, and cost accounting so the rest of the stack does not have to care whether the backend is Anthropic, OpenAI, Google, Bedrock, or Mistral.
| Concern | Provider-specific world | Unified AI layer |
|---|---|---|
| Streaming | Different event shapes and delta formats | One consistent event stream |
| Model metadata | Scattered across SDKs | Centralized context and pricing fields |
| Cost tracking | Ad hoc or provider-specific | Unified accounting across input, output, and cache usage |
| Tooling | Each SDK behaves differently | One abstraction for the agent loop |
That abstraction looks boring until it saves you from rebuilding the same adapter five times. In a system like this, boring infrastructure is a feature.
Why TypeScript, Python, and IPython
The language split is practical. TypeScript is the shell around the system: CLI, TUI, orchestration, and event handling. Python, via IPython, is the living workspace where the agent can keep variables, imports, and experiments around between steps.
TypeScript: orchestrate turns, tools, streams, and UI.
Python / IPython: hold state, run experiments, inspect files, compute, and refine.
Together: a control plane plus an execution plane.
That is why Prime Agent feels different from a tool that just shells out to Python. The kernel is not an afterthought. It is part of the agent’s memory architecture.
Prime Agent vs. the Usual Suspects
The key comparison is not feature checkboxes. It is the assumption each product makes about the nature of work. Some tools treat the agent as a conversation. Others treat it as a process.
| Product | Assumption | Strength | Trade-off |
|---|---|---|---|
| Prime Agent | Work is a persistent process | Recursion, durable memory, reattachment | More moving parts |
| Claude Code / Codex | Work is an interactive exchange | Fast, simple, familiar | Session loss is costly |
| Devin / OpenDevin | Work is an autonomous task run | Hands-off execution | Harder to steer in real time |
| Cursor-style workflows | Work is editor-bound collaboration | Great local feedback loop | Less suited to overnight autonomy |
Prime Agent is not trying to win the same game as an editor assistant. It is aimed at the class of problems where the winning move is to keep going after the human has stopped watching.
What This Repo Is Really For
The sweet spot is obvious once you see the architecture. Long-horizon coding. Research. Refactors. Evaluations. Any task where context loss is the failure mode and patience is part of the product. Prime Agent is built for that world, and it is opinionated enough to feel like a genuine alternative to chat-centric tooling.