Agent Harness Wiki

6 min read

High-Impact Artifacts for Multiplayer Harness Design

Question

If you want to make progress on a multiplayer harness quickly, what should you inspect first?

Short answer

Look first at the artifacts that force irreversible architectural choices:

  1. shared ontology
  2. sidecar/reference-node shape
  3. interop boundary
  4. replication semantics
  5. trust and bounded delegation
  6. multiplayer human surfaces

That means the highest-impact reading is not the broadest survey. It is the handful of pages and sources that decide what your system is allowed to become.

If you only inspect three things today

1. moldable-operations-studio-schema-pass

Why it matters:

  • This is the object/event ontology.
  • It decides whether the network is exchanging real collaboration objects or just smuggling chat logs around with nicer branding.
  • If the schema is wrong, every later adapter becomes a tax on the soul.

What to look for:

  • Are work_item, artifact, approval, trace, authority_budget, and view_definition actually the right minimum shared objects?
  • Is the linearizable subset small enough?
  • Are causal parents, frontier, suspicion, and lifecycle sufficient for replay and cross-node coherence?

Design question it answers:

  • What exactly is the thing every harness would jack into?

2. another-harness-work-item-closure-environment

Why it matters:

  • This is the most concrete local proof that a sidecar-style control plane can exist beside a real repo workflow without becoming decorative nonsense.
  • It shows how to derive executable state from canonical artifacts rather than inventing a second truth model.

What to look for:

  • How the grading contract is frozen in the baseline commit
  • How the environment stays artifact-first instead of transcript-first
  • How narrow, executable scope beats grand platform mythology

Design question it answers:

  • What should a reference node or sidecar actually feel like in practice?

3. how-to-build-a-multiplayer-harness-network

Why it matters:

  • This is the current build-order judgment.
  • It turns the research pile into sequencing: ontology first, node second, bridge third, protocol later.

What to look for:

  • native node vs sidecar bridge vs gateway wrapper
  • protocol boundary early vs protocol standard late
  • capability card and minimum participation contract

Design question it answers:

  • In what order do you make this real without getting trapped in standards theatre?

The next four high-impact things

4. google-agent2agent-protocol plus arxiv-ehtesham-2025-survey-agent-interoperability-protocols

Why they matter:

  • These clarify that tool access, peer delegation, messaging, and open-network discovery are different seams.
  • That separation is probably the single most important protocol-design insight for your system.

What to look for:

  • capability cards
  • task lifecycle
  • artifact passing
  • what belongs to A2A-like peer interop versus MCP-like local tool access

Design question they answer:

  • What should the adapter boundary expose, and what should remain local to each harness?

5. local-first-software plus pushpin-peer-to-peer-collaboration

Why they matter:

  • These decide whether your network is actually peer-oriented or just a cloud product with some polite peer rhetoric.
  • They force you to think about sovereignty, offline usefulness, sync, and real product ergonomics together.

What to look for:

  • local ownership of state
  • offline operation
  • why CRDTs alone are not enough
  • why networking and UX have to be designed together

Design question they answer:

  • Is each harness node genuinely first-class on its own, or merely a cache for someone else’s server?

6. merkle-crdts

Why it matters:

  • This is the cleanest current pointer for how replicated state and artifact sync might actually scale beyond a toy two-user demo.
  • It turns “share state” into content-addressed, hash-verifiable anti-entropy rather than optimistic hand-waving.

What to look for:

  • operation vs state sync
  • how artifact graphs might fit Merkle-DAG structure
  • which objects should be CRDT-backed and which should not

Design question it answers:

  • How should shared spaces synchronize without central serialization?

7. session-guarantees-weakly-consistent-replicated-data plus escrow-transactional-method

Why they matter:

  • These are the sharpest old distributed-systems imports for human trust in the system.
  • They tell you what must feel consistent locally and what can remain only causally or eventually coordinated.

What to look for:

  • read-your-writes and monotonic reads across surfaces
  • bounded rights / escrowed budgets for delegated autonomy
  • where stronger coordination is truly necessary

Design question they answer:

  • What consistency and trust guarantees are the minimum needed for humans not to hate the system?

Human-surface references with disproportionate leverage

8. visual-studio-live-share

Why it matters:

  • It proves that collaboration becomes much stronger when runtime context is shared, not just source text.

What to look for:

  • follow mode
  • shared terminals and servers
  • temporary focus handoff

Design question it answers:

  • What should a multiplayer harness share besides files?

9. jupyterlab-real-time-collaboration

Why it matters:

  • It shows what it means to make a structured computational artifact, not just a text file, genuinely multiplayer.

What to look for:

  • how shared computational objects behave when multiple actors inspect and edit them live
  • what kinds of artifacts in your system should behave like notebooks or cells

Design question it answers:

  • What are the collaborative units of work in a human-plus-agent workspace?

Inspection order I would actually recommend

Session 1: ontology and sidecar

Goal:

  • decide the minimum shared objects and what the reference node should own

Session 2: adapter and protocol seams

Goal:

  • define the minimum capability card and adapter contract

Session 3: replication and trust

Goal:

  • decide what replicates, what stays local, and what needs stronger guarantees

Session 4: human surfaces

Goal:

  • decide which multiplayer views are essential in the first product slice

What to explicitly avoid while inspecting

  • Do not let protocol curiosity outrun ontology.
  • Do not let replication fascination outrun product shape.
  • Do not let UI wireframes outrun the control-plane semantics.
  • Do not let one foreign harness’s quirks define the universal model too early.

Bottom line

The most valuable things to inspect are the ones that constrain the design irreversibly: schema, sidecar shape, adapter boundary, replication semantics, and bounded trust. Everything else is downstream.

If sovereignty and non-scalar trust are central to the design, the dedicated deep-dive now lives in sovereignty-and-observed-goals-ledgers-for-multiplayer-harnesses, and the concrete schema extension now lives in sovereign-identity-and-observed-goals-schema-pass.

If you want the single highest-leverage next move after that inspection, it is to write the minimum capability card and adapter contract against the existing schema. That artifact now lives in node-card-and-minimum-adapter-contract.

Read this with node-card-and-minimum-adapter-contract, sovereignty-and-observed-goals-ledgers-for-multiplayer-harnesses, how-to-build-a-multiplayer-harness-network, multiplayer-agent-harnesses-and-p2p-networks, moldable-operations-studio-schema-pass, another-harness-work-item-closure-environment, another-harness-atropos-environment-schema, and grounding-moldable-operations-studio-ideas-in-real-research.

Graph View

Backlinks