Runtime operations

Inspection-first runtime behavior

A production runtime cannot treat the final model answer as the only product artifact. Operators need requests, sessions, approvals, health, and event history. That is why the runtime ships inspection methods alongside run execution.

const unsubscribe = subscribe(runtime, (event) => {
  console.log(event);
});

const requests = await listRequests(runtime);
const sessions = await listSessions(runtime);
const approvals = await listApprovals(runtime);
const health = await getHealth(runtime);

Typical operator loop

1. Subscribe to runtime events while a request is running.
2. Inspect persisted requests, sessions, and approvals after the run pauses or completes.
3. Resolve approvals through the runtime surface rather than touching checkpoint internals.
4. Use exported artifacts, events, and health data to decide whether recovery or escalation is needed.

Approvals are a runtime contract

Approval decisions are product-facing. Raw checkpoint manipulation is not. When a run pauses for human approval, the operator should think in terms of deciding and continuing the run, not in terms of manual checkpoint orchestration.

await resolveApproval(runtime, {
  sessionId,
  requestId,
  approvalId,
  decision: "approved",
  message: "ok"
});

Recovery is system-managed

Restart recovery, approval-driven continuation, and internal resume behavior are runtime responsibilities. A good runtime makes recovery feel like lifecycle continuity rather than a bespoke operator ritual.

Persistence and evidence packages

Runtime operations are only reliable if the important evidence is durable. Requests, sessions, approvals, events, and artifacts should be inspectable after the run, after process restart, and during incident review.

Queueing and concurrency

Upstream frameworks may define execution concurrency semantics, but application runtime scheduling, isolation, maintenance, and approval flow are still runtime concerns. The runtime should manage those concerns consistently across requests, tools, agents, and resources.

What should be runtime-owned

• Request queue admission and backpressure.
• Isolation between concurrent work and operator-visible status.
• Maintenance policies that keep recovery and persistence healthy.
• Approval pauses that coexist cleanly with other running work.

Operator posture

Operators need a durable control plane: clear status, restart-safe history, and enough correlation metadata to join one persisted request to logs, traces, and failure handling. Without that, every incident becomes a new investigation into ephemeral backend behavior.

The shipped operator loop should be visible in product surfaces too: runtime health checks, approval queue inspection, request-tail views, and trace-export metadata all belong to the runtime control plane rather than ad hoc local scripts.

The CLI surface should not stop at raw JSON dumps. Operators need one-glance summaries for failing checks, pending approvals, stuck requests, current delegated agent, and last activity timestamps before they decide whether to approve, retry, resume, or patch code.

Minimal incident playbook

1. Find the affected request and session ids.
2. Inspect the event stream and current approval state.
3. Check artifacts and exported runtime evidence if the run crossed multiple subsystems.
4. Decide whether the next action is approval, retry, resume, or code fix.
5. If the problem is systemic, update policy, docs, and tests instead of only unblocking one run.

agent-harness runtime overview --workspace .
agent-harness runtime health --workspace .
agent-harness runtime approvals watch --workspace . --status pending --once
agent-harness runtime requests tail --workspace . --once
agent-harness runtime export request --workspace . --session session-123 --request request-456 --artifact-contents --health