AgentHarness: current state, security boundary, and next steps

[AlexsJones]

The problem: Sympozium can execute agents, but the primary agent process has historically been tied to Sympozium's built-in agent-runner. Teams that already use Codex, Claude Code, Goose, DSH, or another harness could not bring that execution model into Sympozium while retaining its Kubernetes lifecycle, policy, tools, memory, and observability.

What AgentHarness solves: It creates a controlled adapter boundary. An administrator approves an adapter image and its contract; Sympozium runs that adapter as the primary process inside the normal AgentRun pod and supplies the task, model routing, policy-controlled tools, and result protocol.

What this unlocks:

• Teams can use their preferred agent harness through normal AgentRuns, channels, schedules, ensembles, and APIs.
• Platform operators keep control of image approval, identity, credentials, NATS, filesystem mounts, SkillPack permissions, and run lifecycle.
• Adapter authors get a versioned contract instead of a private integration with Sympozium internals.
• Users can inspect which approved runtime and immutable image executed, while normal AgentRuns remain unchanged.

This is the practical value: bring existing agent ecosystems into Sympozium without giving an external harness unrestricted access to the cluster, and without creating a second orchestration system.

Summary

AgentHarness is now a supported product direction for running an administrator-approved external adapter as the primary process of an AgentRun. The surrounding Sympozium lifecycle remains intact: Kubernetes Job execution, policy admission, result reporting, memory, observability, and normal AgentRun compatibility.

The umbrella plan is tracked in #349. The current UX and documentation work is tracked separately in #360.

Shipped and verified

• #356: Agent-level runtimeRef inheritance, so channels, schedules, ensembles, APIs, and normal string tasks can resolve an AgentRuntime without object-form task authoring.
• #358: unique per-run Kubernetes identity and token isolation.
• #361: authenticated NATS with subject-level ACLs; the harness cannot publish directly to control-plane subjects.
• #362: harness model credentials are restricted to the backing Agent allowlist, including a fail-closed missing-provider case.
• #364 and #363: managed memory Deployments now follow image-tag changes while preserving PVC data.
• #365: bounded Core NATS flushes fixed IPC bridge tool execution after the NATS security rollout.

On the Framework cluster we verified digest-pinned harness execution, inherited AgentRuntime resolution, normal AgentRun execution, memory-backed AgentRuns, Ergoz power discovery, and a real execute_command request through the authenticated IPC bridge. The bridge hotfix was deployed as immutable image tag ee1c92f; a fresh tool-using AgentRun completed with Succeeded and result IPC bridge smoke passed.

What the model is

An AgentRuntime is an administrator-owned contract and image selection. Users select an approved runtime; they do not run arbitrary upstream harness images by naming them in an AgentRun. The adapter receives the versioned contract environment and returns the structured Sympozium result protocol. Platform-enforced SkillPack policy, IPC boundaries, Kubernetes identity, and run lifecycle remain outside the adapter.

Normal AgentRuns remain a first-class execution path. The harness mode replaces only the primary agent-runner process; it does not replace the AgentRun controller, Job lifecycle, admission policy, memory services, sidecars, or result handling.

Still open

The major remaining items in #349 are:

• canonical digest enforcement plus signature and attestation policy;
• explicit remote MCP credential mediation;
• unmetered-run policy and accounting semantics;
• defined behavior for unsupported runner fields, cancellation, streaming, result-size limits, and metrics;
• API and New Run runtime selection plus run-detail provenance and failure taxonomy;
• a deterministic reference adapter, adapter repository, and conformance suite;
• two real adapter smoke tests, including a SkillPack MCP call.

Product work next

#360 is the next major product slice: publish the operator/user guide, quickstart, AgentRuntime field reference, trust model, compatibility matrix, troubleshooting, runtime selection UX, runtime detail, and run provenance. Documentation must clearly label capabilities as platform-enforced, adapter-claimed, or unavailable.

The merged changes are currently running on Framework. Release publication is tracked by #354. Feedback from adapter maintainers and operators is especially useful on the contract boundary, MCP behavior, and the proposed conformance matrix.

Questions for the community

We would especially value input on these design questions:

• Which agent harnesses should have first-class adapter examples or support tiers?
• Should remote MCP credentials be mediated through a Sympozium proxy, or exposed directly to a trusted adapter?
• What should the minimum conformance bar be before an adapter is marked supported?
• Which runtime provenance and failure details are essential in day-to-day operations?
• What would make selecting and debugging an AgentRuntime feel obvious to you?

If you maintain an adapter, operate agent workloads, or have a strong view on the trust boundary, please share your use case, proposed contract, or objections here. Concrete examples are especially useful as we shape #360 and the remaining work in #349.

[AlexsJones]

Milestone: AgentHarness UX and docs are ready for v0.10.50

The release candidate is #370. It brings the product journey into focus:

• Agents are the starting point. Each Agent now has dedicated Harness, Ensemble, and Runs views.
• Harnesses are discoverable. Agents → Harnesses is the administrator-facing registry for approved runtimes, showing readiness, resolved digest, contract, conformance, support owner, and clearly marked adapter claims.
• Selection stays safe. Choose a default on the Agent’s Harness tab, or make a one-run override from New Run; users still cannot paste arbitrary images into a run.
• Audit is stronger. Inherited harness runs record the resolved runtime, contract, digest, and whether selection came from the Agent default or a run override.
• Docs now cover the whole path. The AgentHarness guide explains policy → AgentRuntime → registry verification → Agent default → normal AgentRun. The UX guide explains the trust model, roles, examples, and remaining product acceptance criteria.

This means teams can start with their existing agent harness while keeping the Sympozium execution boundary: AgentRun lifecycle, policy, per-run identity, skills, memory, MCP integration, and observability remain platform-owned.

The next work is deliberately narrower: complete runtime lifecycle/deprecation, policy eligibility preview, full run failure taxonomy, and adapter conformance coverage. Feedback on the registry/detail experience and what proof operators need on Run Detail is particularly welcome.