Prime Agent and UHP

Treat detachment and refinement as durable state changes

The current Prime Agent README says sessions, Python REPL state, schedules and subagents can keep running under the daemon after the terminal detaches. A closed terminal is therefore neither cancellation nor completion. Its worker/kernel separation helps lifecycle recovery but is explicitly not a security sandbox: generated Python and project commands use your permissions.

Your intent	Current documented command	Evidence to inspect
Find existing work	prime-agent agents	Running, idle and saved session state
Reconnect to a running agent	prime-agent attach <agent>	Intended session identity and current work
Inspect shared service health	prime-agent status	Daemon/worker state
Diagnose services	prime-agent doctor	Read the diagnosis before using repair options

These are documented command shapes, not commands run by this guide. The README also provides shutdown, which affects every agent/worker/service; do not use it as if it ended only the visible terminal’s turn.

For continual-harness refinement, capture the before/after supplemental state and the recorded rollback snapshot. /refine can change memories, instructions and reusable agent definitions while leaving the immutable base prompt intact. A useful evaluation asks whether the new lesson is scoped to the intended session and actually applied on the next action, rather than judging only the generated reflection text.

Instruction provenance covers applied-state evidence; profile isolation covers ownership across concurrent work. The newest v0.9.8 model-picker fix below improves discovery but does not verify every subscription route or make generated Python safe to run outside a restricted environment.

Release check — 4 October 2026

The latest stable release observed in the upstream GitHub release API is v0.9.8, published 2026-09-29. The release repairs Codex subscription model discovery and refreshes the model catalogue when the picker opens. A model appearing in a picker is still distinct from an authenticated successful delegated execution.

Evidence scope: the integration details, commands, measurements and development-head references below preserve the 14 Sep 2026 source snapshot. They are not presented as a fresh test of this newer release. For the current UHP protocol, HarnessRouter release and suite coordinates, use the release tracker and conformance guide. Adapter support does not establish upstream-native UHP adoption.

Source snapshot — 14 Sep 2026

Prime Agent is a distinct agent harness, not a UHP implementation. Prime Intellect describes it as a self-improving Recursive Language Model (RLM) harness for coding, research and long-running work. The stable release observed at this cutoff is v0.9.4, published 8 September 2026 at 23:18:05 UTC, with tag target f771dfcedd684d1afff84ca2c6fa95c7a21efbc2.

Checked upstream main is 1fc1adb6e8062bf871a9b59705c1d15468e589f0 at this cutoff. Upstream’s moving beta release points at that commit as v0.9.4-beta.705.1.1fc1adb; the stable and beta/current-main coordinates are deliberately kept separate.

Caution

No native UHP adoption is established. A repository search and reviewed first-party documentation do not expose a UHP endpoint, UHP version declaration or UHP conformance result, and HarnessRouter stable v0.17.1 does not list Prime Agent among its 11 released backends. Prime Agent’s own agent-to-agent messaging is an internal/runtime capability; it is not evidence of support for the A2A protocol.

Why Prime Agent matters to harness architecture

Prime Agent makes two harness concepts unusually explicit:

1. Recursive Language Model (RLM): prompt/context is treated as programmable state and recursive subagents are invoked as functions from a persistent Python environment.
2. Continual Harness: supplemental prompts, memories, skill descriptions and reusable subagent specifications are durable harness state that the agent can refine through small evidence-backed updates instead of treating every session as a fixed prompt plus transient transcript.

The result is a harness that owns much more than a model call. The stable documentation describes:

• a persistent Python REPL as the model-facing control environment;
• file, shell, tool and context operations expressed programmatically;
• real child agents through rlm(...) for parallel or background work;
• /refine for bounded, reviewable updates to supplemental harness state with recorded snapshots and rollback;
• executable Python skills;
• daemon-backed sessions that continue after terminal detachment;
• direct messaging between running Prime Agent sessions and retained subagents;
• compaction, persistent goals, heartbeats, schedules and bounded autonomous mode;
• JSON, RPC and ACP surfaces for external automation and clients.

These are harness/runtime semantics. UHP standardizes a different outer boundary: client → UHP server → configured complete harness. A UHP server could theoretically wrap Prime Agent, but no reviewed first-party source establishes such an adapter today.

Boundary map

Layer	Primary job	Verified Prime Agent relationship
Prime Agent	Long-running model/tool/subagent loop, Python control environment and durable harness state	Native harness surface.
Continual Harness	Online refinement of supplemental prompts, memories, skill descriptions and subagent specifications	Native harness architecture.
RLM	Programmatic context plus recursive/subagent execution in a persistent REPL	Native execution model.
ACP	Editor/client/evaluation harness → agent	First-party stable mode via prime-agent --mode acp.
MCP	Tool-server boundary	Supported inside ACP sessions through client-supplied stdio and HTTP MCP servers.
A2A protocol	Standard agent-to-agent interoperability	Not established. Prime Agent has its own direct agent messaging, which must not be conflated with the A2A standard.
UHP	Client → UHP server → complete configured harness	No native adoption established.
HarnessRouter	UHP reference implementation → backend adapters	Prime Agent is not in stable v0.17.1’s 11 released backends at this cutoff.

First-party ACP mode

Stable v0.9.4 documents ACP mode as a first-party interface:

prime-agent --mode acp

It speaks JSON-RPC 2.0 as newline-delimited JSON over stdin/stdout and supports the core interactive lifecycle used by its implementation: initialize, session/new, session/prompt, session/cancel and session/close.

Prime Agent deliberately limits ACP to one session per connection. Its underlying session is fixed at process startup, so a second session/new is refused rather than pretending two clients have isolated conversation, working-directory and model state. Concurrent prompts are likewise refused, and a client-supplied working directory that conflicts with the real runtime is reported rather than silently applied.

The current official ACP protocol matrix generated 14 September 2026 at 10:43:07 UTC probes 34 registry agents. Prime Agent is not present in that matrix or registry snapshot, so this page treats ACP support as direct first-party implementation evidence rather than registry/direct-probe interoperability evidence.

Stable ACP message identity and cross-harness convergence

Prime Agent PR #1781, merged 25 August 2026 as b5ee2f81, added a stable messageId to ACP assistant thought and visible-message chunks. The v0.9.4 tag is 89 commits downstream of that merge, so this behavior is part of the current stable release rather than an unreleased current-main claim.

The implementation treats message identity as a rendering and replacement boundary:

• assistant message_start allocates prime-agent-assistant-N;
• reasoning (agent_thought_chunk) and visible text (agent_message_chunk) for that same assistant reply share the same identifier;
• message_end closes the identity; and
• the next autonomous assistant reply receives the next identifier rather than being folded into the prior message.

The PR reports 18 focused ACP event-mapping tests plus npm run check. Its regression explicitly verifies that thought and text deltas from one message share one ID and that a later message advances to a different ID.

This matters beyond UI cosmetics. An ACP client may group streamed deltas or replace a root assistant reply by messageId; omitting that boundary can make two autonomous assistant turns collapse into one client-side message even when the underlying text stream is otherwise correct.

Hermes current-main commits 4a1e44dd and a00f832c independently converged on the same invariant on 14 September 2026 after porting the Prime Agent behavior: contiguous reasoning/text chunks for one reply share one message ID and a later reply gets a new one. Hermes then chose UUID4 values for compatibility with its pinned agent-client-protocol==0.9.0 SDK and strict clients. That UUID choice must not be generalized into a current ACP wire rule: the current ACP message-ID RFD defines IDs as agent-generated opaque strings, requires clients not to parse their structure, and focuses interoperability on uniqueness per message plus stability across that message’s chunks.

For harness/client interoperability, the durable rule is therefore stable identity per logical streamed message, not a particular identifier format.

MCP through the ACP session boundary

The stable ACP documentation accepts standard stdio and HTTP MCP servers from session/new.mcpServers. Those servers become callable from the pre-imported mcp Python program for the ACP session.

The security boundary is explicit:

• HTTP MCP configuration uses only the URL and headers supplied by the ACP client; it does not read Prime Agent’s stored OAuth/auth configuration or silently mutate persistent MCP settings.
• Stdio MCP processes run with a scrubbed base environment plus the explicit values supplied by the client, but they still execute with the Prime Agent user’s operating-system permissions.
• The ACP-scoped server configuration is removed when the ACP session closes or disconnects.
• Upstream therefore describes ACP stdio MCP as a trusted-code boundary, not a sandbox.

This is an inner tool-integration surface. It does not turn ACP or MCP into the outer UHP contract and does not establish native UHP support.

Continual Harness is durable adaptation, not protocol state

Prime Agent’s /refine mechanism is important because it separates conversation history from harness adaptation. The Continual Harness can persist focused lessons into supplemental prompts, memories, reusable skill descriptions or subagent specifications while leaving the immutable base system prompt untouched and recording snapshots for rollback.

That state belongs to Prime Agent’s runtime/harness layer. UHP does not standardize how a harness learns, rewrites its own supplemental instructions or stores reusable skills. A UHP implementation wrapping such a harness would still need to preserve UHP’s task/session semantics independently of the harness’s internal adaptation mechanism.

The underlying Continual Harness research likewise frames harnesses as the layer that surrounds foundation models with tools, memory, planning and other scaffolding, then extends that layer so an agent can alternate between acting and refining its own harness online without a reset.

Long-running execution and process boundaries

Prime Agent’s architecture separates terminal presentation, process coordination, agent execution, the model-facing Python kernel and persisted state. A daemon supervisor owns routing, attachments, worker health and cross-agent message delivery; each worker owns one root runtime, scheduler, kernels and descendants; AgentSession owns provider calls, queues, tools, compaction, goals, child lifecycles and transcript writes.

Detached sessions, scheduled re-entry, heartbeats, goal continuation and agent-originated messages therefore converge on the same session execution/persistence path rather than becoming separate ad-hoc runners.

This is useful architectural evidence for long-running harnesses, but upstream is equally explicit about the security boundary: separate workers and kernels provide lifecycle and failure containment, not a security sandbox, and normally run with the same OS permissions as the client.

Stable v0.9.4 hardens durable-state failure modes

The v0.9.4 release is relevant to long-running harness reliability rather than just version freshness. Its release notes include:

• restart of a Python kernel after a post-startup death instead of permanently routing later calls to a dead kernel;
• restoration of real skill-MCP tool input schemas after the MCP SDK field rename;
• shared event-log semantics where an unterminated final JSONL line is treated as an uncommitted append and truncated before the next append;
• crash-safe atomic JSON/JSONL writes, including auth.json, settings and session data;
• repair of torn/zero-filled session tails at open;
• safer handling of momentarily unreadable lease-owner records;
• reduced derived session-journal growth and incremental metadata scans instead of rereading whole session files.

Those are harness persistence/recovery semantics. They do not change UHP, ACP or MCP wire specifications.

Evidence boundaries

• Stable: v0.9.4, published 8 Sep 2026 at 23:18:05 UTC; tag target f771dfcedd684d1afff84ca2c6fa95c7a21efbc2.
• Checked main: 1fc1adb6e8062bf871a9b59705c1d15468e589f0.
• Moving beta at checked main: v0.9.4-beta.705.1.1fc1adb; not promoted to stable evidence.
• RLM harness / Continual Harness: established by first-party repository documentation and the associated Prime Agent/Continual Harness papers.
• First-party ACP: established at stable v0.9.4; stable also contains PR #1781’s per-message streamed messageId boundary.
• ACP registry/direct-probe evidence: not established in the 14 Sep 10:43 UTC matrix of 34 agents.
• MCP: client-supplied stdio/HTTP MCP servers are established for ACP sessions.
• A2A protocol: not established; internal direct agent messaging is a different mechanism.
• Native UHP: not established.
• HarnessRouter backend: not present in stable v0.17.1’s 11 released backends.
• UHP conformance evidence: none attributed to Prime Agent.

Related pages

Read Deep Agents, Strands Agents and Pydantic AI Harness for other harness architectures, harness composition for internal delegation topology, UHP vs ACP and UHP vs MCP for protocol boundaries, loop engineering for autonomous feedback-cycle design, and ecosystem for adoption classifications.

Primary sources

• Prime Agent repository
• Prime Agent v0.9.4
• Prime Agent README at v0.9.4
• Prime Agent architecture at v0.9.4
• Prime Agent ACP mode at v0.9.4
• Prime Agent PR #1781 — preserve ACP assistant message boundaries
• Prime Agent merge b5ee2f81
• Prime Agent checked main 1fc1adb6
• Prime Agent paper: arXiv:2608.23552
• Continual Harness paper: arXiv:2605.09998
• Official ACP protocol matrix
• ACP message-ID RFD
• Hermes ACP message-ID port 4a1e44dd
• Hermes UUID follow-up a00f832c
• HarnessRouter v0.17.1