🗃️ The Harness Skill

name: dual-agent-harness
description: Build or run a soulbis ⚔️ ⊥ soulbae 🧙 dual-agent harness — a proposer and a prover held apart by a Fiat-Shamir Gap, so no result survives that the proposer could have tuned to. Use when setting up a rigorous optimization or autoresearch loop, when an agent keeps grading its own work, when you need held-out validation of AI-proposed changes, or when someone says "dual agent harness", "held-apart agents", "soulbis/soulbae", "autoresearch loop", "the proposer is marking its own homework", or "build my own harness path".
license: Apache-2.0
metadata:
version: 1.0.0
origin: 0xagentprivacy
inscription: "(⚔️⊥⿻⊥🧙)😊 = neg ⊕ bnot → succ"
proverb: "The proposer that grades itself builds mirages; only what the Gap could not tune to is a result."
spell: "measure → propose(held-apart) → hunt → assay(held-out) → critic → accept-only-on-validated-product"

Dual-agent harness

A two-agent loop where the agent that proposes changes and the agent that
validates them are architecturally held apart. Between them sits the Gap:
verification witnesses are derived by hashing the proposal itself, so the
proposer cannot have optimised for them and the prover cannot be accused of
choosing them.

Use it whenever a single agent would otherwise propose a change, run its own
check, and declare victory. That loop produces mirages — candidates that
pass the author's own probe and fail the real gate. This harness makes the
mirage a named verdict rather than a surprise.

When to use

• Setting up an optimization loop (make X smaller/faster/cheaper subject to a
  constraint that must not break).
• Setting up an autoresearch loop (produce a claim, then prove it against
  evidence the producer did not select).
• Any time an AI-proposed change needs held-out validation before a human
  signs off.

Build recipe

1. Define the Gap first. If you cannot say how held-out witnesses derive
   from a proposal by hashing, you do not have a harness yet — you have a
   to-do list. Everything else follows from this.
2. Name the objective, the gate, and the hard constraint. The gate is a
   factor in a product: any zero collapses the result at any score. The hard
   constraint is validity no score can override.
3. Give the proposer at least two blind lenses. For a product objective,
   one lens per factor, plus a cliff-watcher in the prover.
4. Copy templates/harness.config.mjs, fill every TODO, bundle it with
   tools/bundle.mjs, run it.
5. Fold as the keystone, in the main session, with conform.mjs green
   before and after.

Hard rules

• A candidate is not a result. Only a full-gate pass, hard constraint intact,
  and a frontier beat is VALIDATED.
• Witnesses never come from the proposer. A validation on proposer-suggested
  witnesses is void.
• A probe pass that fails the full gate is a MIRAGE. Name it; never soften
  it.
• Negative results are filed as prominently as wins.
• The door is the First Person's. Push, submit, publish, send — the
  harness stops in front of these and lists them. It never opens them.

κ as state — the holon layer

A validated result seals into a κ-addressed holon: a record whose address is
sha256(canonicalJson(itself, minus the κ field)) — the City Key / sigil Law L5
(never trusted, only re-derived). The mint produces them, the runtime feed
self-addresses, and tools/holon_audit.mjs re-derives the whole mesh. Because
verifying content-addressed holons is enumerable, that verifier is an auditor,
not a harness: the harness mints the holons, the auditor verifies the mesh. One
κ law (tools/kappa.mjs), computed identically everywhere, is the interoperability
substrate — a holon minted here re-derives byte-for-byte anywhere else. See
HOLONS.md.

Map

RESEARCH.md (the contribution — problem, claim, evidence, limits) ·
PRACTICES.md (the 2024–26 field surveyed against this harness, every claim
traced through SOURCES.md) ·
AGENTS.md (the tool-neutral boot protocol; CLAUDE.md imports it) ·
HOLONS.md (κ-addressed interoperability, and why it is an auditor) ·
TRUSTS.md (the constitution — six trusts, and where each one bites) ·
GROUND_RULES.md (GR-1..GR-10) · SEAT_CONTRACT.md (the config interface) ·
seats/ (seven cards) · engine/dual_agent_loop.mjs (the loop) ·
engine/conform.mjs (the gate that proves the algebra rather than asserting
it) · examples/field-guide/ (a runnable spar) · SPECIALISATION.md
(personas, spells, and the Game of 42 station pattern) · HARNESS_PATHS.md
(the origin fleet — fifteen real instances, grouped by how much of the loop
each runs; evidence, not part of the system you adopt) ·
WIKI.md (the Observe lane — auto-populating a federated wiki + the
knowledge-graph asset for agents) ·
tools/console.mjs (the live workshop console) · tools/frontier.html (the
interactive, contributable frontier, per workshop).

Assets

Navigation

← Welcome Visitors · The Dual-Agent Harness

the wiki is a projection; ~/dual-agent-harness (git) is the source of truth · (⚔️⊥⿻⊥🧙)😊 = neg ⊕ bnot → succ