Managed runtime mode that disables autonomous and long-running capabilities

[TuralHeydarov]

Problem

We are integrating Prime Agent v0.7.2 as a peer runtime behind an external multi-tenant control plane. The control plane must remain authoritative for scheduling, concurrency, approvals, budgets, audit, and termination while still using the official prime-agent --mode rpc transport and the ipython coding tool.

Today --no-extensions, --no-skills, --no-prompt-templates, and --no-themes do not disable built-in long-running capabilities. RLM_MAX_DEPTH=0 can block child depth only when no persisted or global override wins. Goals, rlm_heartbeat, agent messaging, schedule and heartbeat RPC commands, resident promotion, and persisted due work remain available. A persisted schedule may execute as the worker starts, before an embedding client can list or cancel it. --no-tools removes ipython and therefore removes the coding capability we need.

This means a model or resumed session can create model calls and code execution outside the embedding control plane lifecycle. Post-start inspection and prompt instructions are racy and are not a security boundary.

Proposed solution

Please add an official versioned managed-runtime capability, exposed by CLI and RPC handshake, that can be selected at process startup and fails closed when unsupported. A possible shape is --managed-runtime or independent hard-disable flags with these semantics:

• retain ipython coding but set and lock RLM max depth to zero;
• disable goal creation and autonomous continuations;
• omit or reject all schedule and heartbeat creation, persistence, due-job execution, and resident promotion;
• omit or reject agent messaging and observation outside the current root session;
• reject persisted sessions containing incompatible active goals, schedules, heartbeats, queued work, or children before any of that work can execute;
• expose negotiated capability bits and a stable protocol/version identifier over RPC;
• guarantee EOF/abort closes the client-owned worker and descendants, with no background work left behind.

Independent flags are also workable if their combination has the same startup-before-rehydration guarantee and is covered as a compatibility contract.

Alternatives considered

• --no-tools: safe but removes the coding tool, so it is not a Prime coding-agent integration.
• RLM_MAX_DEPTH=0 plus post-start list/cancel: does not disable goals or heartbeats and cannot prevent persisted due work from running first.
• prompt instructions: model behavior is not enforcement.
• patching Prime or wrapping private internals: breaks the goal of integrating the official release and protocol.
• killing the daemon after each task: necessary cleanup, but does not prevent work created or rehydrated before cleanup.

Additional context

The integration is currently fail-closed for v0.7.2 rather than claiming that an operator attestation is a sandbox. An official managed capability would unblock a native adapter without carrying a Prime fork.