II Agent Harness

Bring your existing harness.

Secure. Deploy. Measure. A planned TypeScript SDK, Commander CLI, provider adapters, and React local console around Claude Code, Codex, OpenCode, or your own harness.

Roadmap
These are accepted implementation requirements, not a released integration. Packages and tested installation instructions are planned. Examples below explain record shapes; they are not a runnable API or finalized schema.

Prepare the workloadSupply your harness, workspace, infrastructure, trusted launching identity, and credential delivery.
Check and deploy a setupResolve a JSON configuration, run fresh permission checks, and coordinate OpenTofu operations.
Run and retain evidenceYour lifecycle owner starts and tracks work, captures required outputs before teardown, and submits lifecycle evidence.
Inspect and evaluateFollow execution records in the local panel and run evaluation in your own environment.

We supply software. You operate the workload and its infrastructure. The library does not host an API, supervise jobs, retry workloads, enforce execution budgets, or send conversational follow-ups.

01 / Prepare

Describe a versioned setup in JSON.

JSON authoring and JSON Schema public records are selected. Keep the prepared workload and lifecycle owner in your project; connect the TypeScript library from a protected integration.

customer-workload/ Illustrative layout

setup.json          # configuration and target inputs
src/integration.ts  # trusted identity + library operations
src/lifecycle.ts    # your startup, recovery, limits, teardown
workload/           # prepared harness and workspace
evaluation/         # task fixtures, tests, or rubric

An immutable revision ID identifies a setup. A separate digest identifies normalized, resolved inputs. Equivalent configurations must resolve to the same digest whether authored in the panel, CLI, or library.

The digest excludes secret values, generated execution IDs, measurements, and outputs. It does not recover missing artifacts, authenticate approval, or guarantee deterministic model output.

02 / Authorize

Protect the library invocation.

Supply a trusted launching identity through your protected integration. The library authorizes the configured operation and target before dispatch. CLI, panel, and direct callers use the same authorization behavior.

Your identity handoffVerified caller and explicit target
Shared authorizationConfigured operation evaluated before dispatch
Authorized operationDeployment or invocation integration

Loopback location and a role supplied in a request body are not trusted identity. No additional login system or per-tool interception is introduced. Harness, OS, and provider controls enforce access while work executes.

Credential ownership

Use actual credential key names with explicit provider and environment context. You own key material and delivery; humans apply provider-access changes. The library does not retrieve secret values, rotate credentials, mutate access, or generate provider-policy changes.

03 / Check

Check the exact inputs before deployment.

Every deployment runs fresh permission checks. A manual Commander check uses the same behavior; a previous pass cannot bypass deployment validation. Findings cover configured circular and indirect access paths, using the provider evidence actually available.

validation-record.json

{
  "example": "Record shape, not a finalized schema",
  "setupRevision": "setup-17",
  "resolvedInputDigest": "sha256:<resolved-input-digest>",
  "mode": "strict",
  "requiredChecks": [
    {"name": "provider evidence", "result": "unanswered"}
  ],
  "decision": "blocked"
}

Bind validation evidence to resolved inputs, relevant versions, findings, and gate configuration. Verify both authenticity and input matching; a hash alone does not authenticate a record. Strict mode blocks failed or unanswered required checks. Explicit blocking overrides retain the original findings.

Permission semantics still to be selected

The access-expression model and its TypeScript evaluator remain open. Explicit grants/groups, resolved attributes/relationships, and bounded conditions are alternatives. Do not assume flat RBAC, a selected policy language, universal redundancy detection, or a specific delegation formula. The evaluator choice follows the expression model.

Permissions overview →

04 / Deploy

Coordinate OpenTofu operations.

OpenTofu is the selected creation and removal engine. Versioned modules and TypeScript invocation return structured per-target outcomes for individual or batch operations. You supply provider authentication and operate the state backend and locking.

setup.json

{
  "example": "Configuration shape, not a finalized schema",
  "revision": "setup-17",
  "workload": "prepared-coding-workload",
  "target": "local",
  "credentialBinding": {
    "keyName": "WORKLOAD_CREDENTIAL",
    "provider": "your-provider",
    "environment": "development"
  }
}

Initial target plan
Target	Boundary
Local infrastructure	Prove the local workflow first. The hypervisor needs implementation research.
Google Cloud	Included in the initial plan; real deployment, permissions, network, quota, and cleanup evidence is required.
AWS and Azure	Planned provider support beyond the initial cloud target.
GitHub	Planned integration and deployment target.
Internal infrastructure	Custom adapters for your compute platform, sandbox, runners, or deployment API.

Separate setup history from running resources

A setup edit affects future deployments only. Separate deployment identity and state prevent a new revision from updating resources behind running work. Consumers own exceptional intervention and external credential revocation.

Your lifecycle owner

You start, track, recover, limit, and tear down the workload. The library exposes operations and accepts lifecycle reports; it does not add a supervisor, watchdog, workload retry loop, or VM reuse policy.

Partial results, timeouts, and removal

Keep per-target resource identities and partial or unknown outcomes. A timeout does not prove cancellation. After an ambiguous apply, inspect known resources and uncertainty rather than retrying blindly. Ownership must be verified before removal; matching names do not establish ownership.

05 / Inspect

Retain execution and evaluation evidence.

Reuse the existing collection code and its verified capture and routing capabilities. Add run correlation rather than another collector. You choose supported capture, destinations, retention, and artifact availability.

Linked records
Record	What it preserves
Resolved inputs	Available task, repository and local changes, configuration, versions, environment, permission context, credential key names/provider, and benchmark inputs.
Execution	Caller, captured inputs/outputs, timings, reported usage, lifecycle evidence, durable artifacts, and coverage gaps.
Evaluation attempt	Exact execution, task snapshot, candidate output, evaluator context, and native results. Multiple attempts can grade the same execution.

Retain permitted bytes or durable references and identify missing or inaccessible artifacts. Late evidence and regrading do not rewrite original inputs. Keep reported costs, estimates, and unknown usage distinct. Telemetry failures must not become tool-action gates.

Planned SWE-bench and Harbor integrations

The planned integrations capture required outputs before your teardown, resolve task context, prepare native inputs, map identifiers, check completeness, and import results. You supply the evaluator runtime and task-specific tests, rubrics, fixtures, output paths, and verifier dependencies. You do not write exporters or result parsers.

Native evaluation contracts

SWE-bench retains the exact task/dataset and repository baseline, captures the candidate patch, exports instance_id, model_name_or_path, and model_patch, and imports native reports/logs. Each evaluation attempt uses a fresh native run ID; grading-only solutions stay out of workload inputs.

Harbor retains task, verifier and environment definitions, native trial records, artifact paths, manifests, and bytes. Native rewards and errors remain distinguishable. Post-teardown regrading and custom or multi-step paths require compatibility proof; arbitrary historical-run conversion is not established.

Evaluator errors, missing evidence, and failed verification are different outcomes. A missing reward stays missing. A numeric score means pass or fail only if the task defines that meaning.

Telemetry overview →

Use the same operations through localhost.

The React and TypeScript panel produces the same JSON used by Commander and direct callers. Forms preserve supported fields they do not yet expose; equivalent authoring paths resolve to the same digest.

Show setup history, findings, deployment results, consumer lifecycle updates, telemetry, and evaluation records. All protected operations share authorization. Surface partial data, unknowns, and errors explicitly. Browser closure neither stops the workload nor transfers its lifecycle ownership.

Management overview →

Tools & packaging

TypeScript library: Pure TypeScript implementation and shared operation contracts. No separate first-party native kernel.
Commander CLI: Manual checks and operations through the same library behavior.
React localhost panel: JSON authoring and record inspection in your local companion environment.
OpenTofu: Selected deployment engine, with consumer-owned provider authentication, state, and locking.
JSON Schema records: Shared configuration and evidence contracts across authoring paths.

Remaining architecture decisions

The permission-expression model and evaluator remain open. Application record storage is also unanswered; it is separate from existing collector storage and the OpenTofu state backend. Other architecture follows the accepted plan. Public release, runnable integration, and compatibility claims require implementation evidence.

Extend the supported contracts.

The plan bundles supported harness and provider adapters, with custom registration for integrations you supply. Components ship in coordinated compatible releases from one repository. No plugin registry or mixed-version component matrix is required.

Custom integrations must preserve trusted identity, exact input binding, resource ownership, capture coverage, and native evaluation evidence. Unsupported capabilities fail explicitly rather than falling back silently.