The word Harness was hiding two decisions

Ordivon H1–H5 concluded that Codex App Server and Hermes ACP should not be compressed into one shared internal lifecycle. Codex exposes Thread, Turn, Item, structured output, and explicit terminal events. Hermes exposes JSON-RPC Session and Prompt semantics, bidirectional requests, thought chunks, sparse Tool updates, and—in our live replacement Runs—no usable final assistant text.

That negative result was correct. The language around it was too broad. Rejecting a universal wrapper around mature Provider Harnesses is not the same as rejecting an Ordivon-owned Agent Loop for a bare model API.

Ordivon does not need a Harness above every Harness. It does need a Harness when the Provider supplies intelligence but no Agent Loop.

Two paths, not one platform

PathProvider suppliesOrdivon suppliesBest use
Mature external HarnessSession, Agent Loop, Tools, lifecycleAssignment, durable Context, Runtime binding, evidence admissionProvider-optimized coding and Agent work
Ordivon HarnessModel inference API or local endpointModel Adapter, Tool Loop, Run-local Context, budgets, evidenceBare APIs, local models, controlled experiments, fallback independence

The first path reuses Codex, Hermes, Claude Code, or another complete Agent system. The second path turns OpenAI Responses, Anthropic Messages, Gemini, DeepSeek, OpenRouter, vLLM, or a local inference endpoint into one bounded Agent Run.

Both return to the same Host boundary:

HarnessAssignment
→ external Provider Harness OR Ordivon Harness
→ HarnessRunReceipt
→ optional CompletionProposal
→ Host verification and TaskOutcome

Why the first-party Loop is strategically necessary

Bare models otherwise remain only inference functions

A raw model API can produce Tool requests, but someone must interpret them, check authority, execute through Runtime, return observations, maintain a bounded Context, stop on budget or interruption, and emit evidence. Without that Loop, Ordivon can use the model for one-shot judgment but not as a general Tool-using Agent.

Not every useful model will ship a mature Harness

Local models, specialist models, research checkpoints, new API providers, and self-hosted inference systems may expose only generation. Requiring every intelligence source to arrive inside Codex- or Claude-shaped software would make Ordivon's work continuity independent at the top but dependent at the cognition boundary.

Some research requires control of the Loop

Context selection, Artifact-first completion, Tool-result compression, stopping behavior, calibrated non-action, cost routing, and model replacement cannot always be studied when the Provider owns every internal decision. Ordivon Harness creates one controlled experimental path without forcing external Harnesses through it.

A minimal fallback is different from rebuilding the ecosystem

The goal is not to reproduce years of Codex or Claude Code engineering. A thin first-party Loop is a capability floor: Ordivon can still act through Tools when only intelligence is available. Mature Harnesses remain preferred when their capabilities and optimization justify the dependency.

Why a universal Harness is the wrong goal

A universal internal lifecycle usually has two failure modes.

Lowest common denominator

The abstraction keeps only Session, Tool request, message, and final result. Rich Provider events, interruption, provenance, output schema, thought observations, modes, compaction, or native commands disappear. The interface becomes portable by discarding the reasons to use a mature Harness.

Synthetic equivalence

The abstraction requires every backend to emit ToolStarted, ToolCompleted, and FinalText. When Hermes omits a Tool completion update or final assistant text, the wrapper must invent an event, guess a state, or fail valid work. H4 and H5 observed both sparse Tool completion and absent final text.

Normalize durable facts that the Host needs. Do not normalize Provider behavior that did not occur.

Why Ordivon Harness can remain thin

Most general Agent frameworks are broad because they also own planning, workflows, sessions, memory, files, shell, approvals, hosting, observability, and deployment. Ordivon has already assigned the heaviest responsibilities elsewhere.

Host already ownsTask semantics

Goal, Task, Attempt, Assignment generation, Context, Artifact provenance, recovery, completion, and Outcome.

Runtime already ownsExecution mechanics

Workspace, Job, process, output, Artifact retention, cancellation, request identity, and response-loss reconciliation.

Harness only needsThe cognitive episode

Model calls, Tool interpretation, bounded observations, Run-local Context, budget, interruption, stop, and receipt.

This is not a claim that the Agent Loop is trivial. It is a design constraint: whenever Ordivon Harness begins to own durable Task truth or process supervision, it has crossed into an existing layer.

The admitted v0

Version zero is intentionally austere:

  • one real bare-model Adapter;
  • one sequential model/Tool Loop;
  • an Assignment-scoped Tool catalog;
  • Runtime-backed Tool execution;
  • turn, token, time, and Runtime-Job budgets;
  • cancellation and explicit stop states;
  • Artifact-first canonical result;
  • existing HarnessRunReceipt and CompletionProposal output.

It will compare the same frozen repository task under a one-shot ModelGateway, Ordivon Harness with a bare model API, and one mature Provider Harness. The first-party Loop earns retention only if it solves a real failure or enables a real model path at acceptable permanent cost.

What v0 deliberately does not contain

persistent Sessioncompactionparallel Toolssubagentsmodel routingSkillsPluginsworkflow languagenew database

Each capability may become valuable. None is free. Persistent Sessions create replacement and hidden-state questions. Parallel Tools create dependency and partial-failure semantics. Subagents blur Harness-local work and Host-managed durable workers. Compaction can turn unverified summaries into accidental truth. They should enter only after a bounded failure and ablation.

When Ordivon Harness becomes a repository

The project name is already Ordivon Harness. Its first implementation should remain inside Host. A standalone repository is eligible only after:

  • a working first-party model/Tool Loop exists;
  • two bare-model Adapters pass the same Loop contract;
  • two independent consumers need the package;
  • the package imports no Host storage and mutates no Task state;
  • the package owns no Runtime Workspace or process internals;
  • extraction produces measurable net deletion and independent release value.

This is a different promotion gate from H5. H5 tested whether Provider drivers should become a common platform. The new gate tests whether a real first-party Agent Loop has become an independently useful component.

The deletion condition matters

Ordivon Harness is strategically plausible, not exempt from evidence. If one-shot calls and mature Provider Harnesses cover the actual workloads with equal correctness and recovery at lower permanent cost—and no bare-model path matters—the prototype should be deleted.

Owning a capability is valuable only when the capability is used. Optional independence can become another expensive fiction.

The right architecture is not Provider dependence or universal abstraction. It is selective ownership: reuse the complete Harness when it exists, own the minimal Loop when it does not.

Evidence

Decision record and primary sources

  1. Ordivon H5. Harness Boundary H5 Decision.
  2. Ordivon research. From Model Tokens to Durable Work and ANC-HARNESS-002.
  3. OpenAI. Unlocking the Codex harness.
  4. Anthropic. Effective harnesses for long-running agents.
  5. Microsoft. Agent Harnesses.