Harnesses versus the runtime
Why agent harnesses own intelligence while the Numinance runtime owns authority, and what an executor adapter promises.
The harness owns intelligence. Numinance owns authority.
Two jobs, two owners
An agent harness is the thing that turns a goal into edits: it manages a model, its tools, its prompts and its loop. That is where intelligence lives, and it improves quickly. The runtime is the thing that decides whether an edit, a command or a network call is allowed, records it, and checks the result. That is where authority lives, and it should change slowly.
Keeping these apart is what allows you to change the model or the harness without renegotiating what the system is permitted to do.
| Concern | Harness | Numinance runtime |
|---|---|---|
| Reasoning and code generation | Owns | Does not interfere |
| Choice of model and prompts | Owns | Does not dictate |
| Tool permissions | Requests | Decides |
| Credentials and egress | Never holds raw secrets | Brokers |
| Policy, grants, approvals | Cannot change | Owns |
| Evidence | Reports | Writes under the runner identity |
Executor adapters
A harness is connected through an executor adapter. The adapter declares which ExecutorCapability values the harness really has, for example EXECUTOR_CAPABILITY_FILESYSTEM_WRITE, EXECUTOR_CAPABILITY_SHELL, EXECUTOR_CAPABILITY_NETWORK, EXECUTOR_CAPABILITY_MCP and EXECUTOR_CAPABILITY_NATIVE_SANDBOX. The runtime compares that declaration to what the work unit needs. If the harness has no native sandbox, the runtime supplies isolation. If it asks for network access, the egress proxy sits in the path. If a required capability is missing, the work unit is not routed there.
Harness adapter explorer
When the executor changes, what stays fixed?
- Policy decisionevaluated outside the model before every privileged action
- Grantcapabilities, allowed and denied paths, budget
- Credential brokerhands out handles, never key material
- Egress proxyonly the allowed destinations
- Protected pathspolicy, CI definitions, IAM, workflow files
- Review and release identityno self-approval; only the release pipeline deploys
A Go adapter drives the harness over its own JSON-lines protocol inside the work-unit sandbox; the harness keeps its own planning and tools.
Example manifest: public specFrom the published example ExecutorManifest claude-cli-bedrock.
Frame unchanged: 6 of 6. Swapped: harness layer, capability manifest, model route.
- TOOL_INTENTharness claim
- POLICY_DECISIONhost-recorded
- TOOL_DENIEDhost-recorded
- TOOL_RESULTharness claim
The harness reports it is about to write .github/workflows/release.yml (a protected path). This is a claim by the provider; it authorizes nothing.
Text description
The authorexecutor port drives one coding harness for one run of one work unit inside a sandbox. Four executors are shown: fake, claude-cli, codex-cli and a read-only reviewer on a different model vendor. All adapters are designed and under development; the spec publishes the port, the event stream, the conformance case list and one example ExecutorManifest (claude-cli-bedrock), not the adapters.
Fixed whichever executor runs: the policy decision, the grant, the credential broker, the egress proxy, the protected paths, and the review and release identities. What swaps is the harness layer and the capability manifest the router pins. Nothing a request says is advisory, and nothing a provider reports is authority.
The sequence is conceptual. The harness reports TOOL_INTENT; the host takes a policy decision (a host record, not a provider event); TOOL_ALLOWED or TOOL_DENIED echoes the broker; TOOL_RESULT reports the outcome. In the denied example a write to a protected workflow file is refused for every write-capable executor. For the reviewer, any write is refused because its run has no write capability and no allowed paths.
The harness owns intelligence. Numinance owns authority. A compromised model can only attempt what its grant allows, and every attempt is decided and recorded outside it. Illustrative and simulated; nothing is connected to a running engine.
What the runtime assumes
The runtime does not trust a harness to enforce its own limits. It assumes:
- the harness may attempt actions outside the grant, and those are denied at the boundary;
- the harness may report success that did not occur, so independent verifiers re-run the checks;
- the harness may be replaced, so nothing about authority lives inside it.
Bring your own
Because the contract is typed and open, a team can write an adapter for a harness the vendor does not ship, and the same governance applies. You are not choosing a model when you adopt Numinance. You are choosing where authority sits.
Availability
Executor adapters and the runtime that hosts them are designed and not in the open build. The open repository carries the contract and conformance material for author and CI executors.
Failure modes
- The adapter overstates its capabilities: conformance checks exist for the port, and the runtime still enforces grants independently.
- A harness crashes mid-unit: the work unit fails, repair or escalation follows.
Next steps
Governed execution
How policy outside the model, capability grants, four distinct identities, protected paths, the circuit breaker and break-glass keep an agent's actions bounded.
Reliability and recovery
How independent verification, bounded repair, canary releases, rollback and escalation limit the cost of a wrong change.