Central claimOne task survived both tested Codex↔Hermes replacement orders without making provider output task truth.
EvidenceE4 · exact source, retained receipts, live runs, and injected faults
ScopeOne bounded repository task across Codex App Server and Hermes ACP

Replacement succeeded because Host-owned identity, generation, artifacts, and completion admission remained durable while provider sessions and lifecycles stayed different.

FigureTwo replacement orders, one durable task
Four real provider runs completed Codex→Hermes and Hermes→Codex. Stale completion, missing artifacts, and response loss were contained without blind redispatch.
Observed
  • Both replacement orders completed.
  • Three injected faults did not become accepted completion.
  • Provider lifecycles and accepted source implementations remained different.
Supports
  • Host-owned task state above provider sessions.
  • Generation fences, artifact requirements, and reconciliation before completion.
Does not establish
  • General provider interchangeability.
  • Equivalent model quality.
  • Long-horizon autonomous reliability.

The experiment was not a Provider benchmark

H1–H5 asked an architecture question: can one durable Task survive materially different Agent Harnesses, physical execution, stale workers, missing deliverables, and ambiguous responses without making a Provider Session or Runtime process the source of truth?

The answer was yes within one frozen repository-repair workload. The answer came with deletion: no universal Provider Session, common Tool lifecycle, Harness database, Runtime Task state, or shared event runtime was justified.

The decisive result was not that Codex and Hermes behaved the same. It was that the Task remained coherent while they behaved differently.

The five stages

StageQuestionEvidenceResult
H1Which Host objects might be necessary?Strict codecs and deterministic lifecycle faultsCandidate boundary
H2Can Runtime correlation remain opaque?Live request identity, replay, conflict, recoveryNo Runtime expansion
H3Does Codex App Server fit the boundary?Real Thread, Turn, Tool, usage, Runtime process treeProvider-faithful driver
H4Does Hermes ACP expose different semantics?Real Session, Prompt, thought stream, sparse Tool updatesDifferences preserved
H5Can both replacement orders survive first faults?Four Provider Runs, independent verification, F1–F3Boundary retained, platform rejected

H3 and H4 proved that Harnesses are materially different

27,325Codex reported tokens
259Codex Provider messages
35,992Hermes reported tokens
689Hermes Provider messages

The H3 Codex Run used CLI/App Server revision 0.145 and model gpt-5.6-sol. It created one real Thread and Turn, executed one successful read command through a Runtime-managed process tree, emitted usage and Tool events, and left the Host Task waiting.

The H4 Hermes Run used Agent 0.18.0, ACP v1, and deepseek:deepseek-v4-pro. It emitted 449 thought chunks, 234 message chunks, two usage updates, and one read Tool observation. No Tool completion update appeared after the Tool start. The Prompt still ended successfully, and the Task still remained waiting.

A code audit found approximately 841 lines in the Codex direct driver and 947 in Hermes, with an exact-line Jaccard similarity near 0.275. Most overlap was subprocess, queue, parsing, validation, serialization, and receipt mechanics. The lifecycle was not common enough to justify a universal implementation.

H5 ran both replacement orders

The frozen workload contained a deterministic largest-remainder allocation defect, a versioned specification, immutable tests, and two required Artifacts: diagnosis.json and completion.json.

Codex diagnosis → Host Assignment generation 2 → Hermes repair
Hermes diagnosis → Host Assignment generation 2 → Codex repair

Each trajectory kept one Task Attempt, compiled fresh Context, passed the diagnosis through Host-retained Artifact evidence, started a new Provider Session, ran independent Runtime acceptance, and let Host alone commit TaskOutcome.

RunReported tokensProvider messagesTool itemsCanonical final source
Codex diagnosis44,255862Provider structured response
Hermes repair242,2762,32911Verified Artifact
Hermes diagnosis136,9071,1516Verified Artifact
Codex repair69,8561064Provider structured response
2replacement orders
4real Provider Runs
493,294combined reported tokens
2/2accepted trajectories

Codex accounted for 114,111 reported tokens and Hermes for 379,183. These values come from different Provider protocols and Runs; they are not a normalized cost or capability benchmark. The experiment was designed to establish the boundary, not compare model efficiency.

Different code, same accepted work

The two replacement orders produced different source digests:

  • sha256:1fb2d560fa109be2673b3d1834df8a441b6c88541b47fdd3c214a3bfd6095ebd
  • sha256:d751a39f77c35bdb0f23cf91cc4da0410be54a740a53a4c5ecb60e9d689136e7

Both satisfied the same frozen specification and acceptance tests. Semantic completion therefore bound diagnosis, required Artifacts, final source digest, and independent verification—not byte-identical implementation.

Fault one: stale Assignment

After Assignment generation 2 was committed, the generation-1 diagnosis Harness proposed that the Task was complete. Both stale proposals were retained and rejected as stale_assignment. The acceptance verifier did not run, no Runtime Job was dispatched by stale adjudication, and no TaskOutcome was created.

This retained Assignment generation as a durable semantic fencing token. Task revision describes Task state; Assignment generation describes which current execution commitment may submit evidence.

Fault two: process success without Artifact

A real Runtime process exited successfully and produced terminal evidence but did not create the required completion Artifact. Host rejected missing_artifact, skipped acceptance verification, and left the Task waiting.

Physical success is evidence. It is not semantic completion.

This retained CompletionProposal and CompletionDecision as an admission boundary distinct from process state and TaskOutcome.

Fault three: response loss

The successful response to the Codex→Hermes repair dispatch was deliberately dropped. A fresh Host recovered exactly one original Runtime Job through the Assignment-bound request identity and opaque Host references:

dispatchCalls = 1
matchingJobs = 1
responseLost = true

No repair was blindly redispatched. This retained Host/Runtime request identity and rejected a Runtime Task table or semantic query platform.

The final message failed as a contract

Both Codex Runs returned usable structured final responses. Both Hermes Runs completed Tools, wrote valid Artifacts, and passed independent verification while ACP final assistant text was absent.

The first orchestration attempt treated missing final text as failure. Inspection showed that the work was already correct. The worker was changed to Artifact-first completion: Provider text became optional observation, and the canonical result was reconstructed from verified Artifacts when text was missing or structurally unusable.

This was not a workaround for Hermes. It exposed a general systems error: language about completion is less authoritative than the state and evidence that completion requires.

What survived—and what did not

CandidateDispositionReasonOwner
Task Attempt roleretain thinlyone semantic path survived two HarnessesHost
Assignment generationretainprevented stale completionHost
HarnessRunReceiptretainlinks Provider, Context, Runtime, Artifact, usage, stopHost boundary
CompletionProposal/Decisionretainprevented false completionHost
Provider Sessionlocalizeuseful Run evidence, not Task identityHarness
Final assistant textshrinkoptional observation, not portable evidenceHarness receipt
Common Provider lifecyclerejectwould erase or invent semanticsnone
Runtime Task staterejectopaque identity already recovered worknone

What H1–H5 did not prove

  • It did not rank Codex and Hermes or establish equal-budget quality.
  • It did not prove that every Provider can fit the same durable boundary.
  • It did not test malicious Harnesses, poisoned Artifact provenance, or verifier compromise.
  • It did not solve multi-Agent branch/join, long-duration compaction, or persistent Session economics.
  • It did not establish that every retained object belongs in a shared Protocol.
  • It did not test a first-party Ordivon Agent Loop over a bare model API.

The new question

The shared Provider-lifecycle question is closed. A distinct construction question is now ready: build the smallest Ordivon Harness that owns a raw model/Tool Loop without copying Host or Runtime.

Version zero will compete against the one-shot gateway and mature Provider Harness, and it carries a deletion condition. If it produces no real capability or strategic model path at acceptable permanent cost, it should not survive merely because the architecture diagram has a place for it.

H1–H5 retained a boundary, not a platform. The next experiment must earn the first-party Loop.

Evidence

Receipts and closeout

  1. Architecture decision. Harness Boundary H5 Decision.
  2. Codex live receipt. H3 Codex App Server evidence.
  3. Hermes live receipt. H4 Hermes ACP evidence.
  4. Replacement and faults. H5 compact live receipt.
  5. Research ledger. Model-to-work study.