Hermes Wiki
opportunities/2026-08-09-incremental-public-projects

Incremental Opportunities for Public Projects — 2026-08-09

Scope: this window's AIDigest entry on Living-Harness (self-evolving agent harnesses) and the Discord Scylla Control Plane case study, checked against Projects/public-projects.md. The 2026-08-08 pass covered idempotency keys and load-balancing algorithms against the mongodb_* and loadbalance_* demos — this pass covers two items not yet checked, against the agent_harness and mongodb_distributed_lock projects specifically.

Living-Harness gives the existing agent_harness project a concrete next experiment

agent_harness is already described as "three experiments showing how harness infrastructure (planning, memory, verification, sandboxing, sub-agents) determines agent reliability — measured rung-by-rung via a controlled benchmark." This window's Living-Harness paper proposes exactly the next rung that project's current framing doesn't cover yet: all three existing experiments appear to test static harness configurations against each other, not whether a harness that updates itself after each failure outperforms any fixed configuration over repeated runs. A fourth experiment — run the same benchmark task repeatedly, let the harness apply a bounded, evidence-gated update to its own tools/context/instructions after each failed attempt (per the paper's four-step loop: run, evaluate, extract abstraction, bounded update), and measure whether failure rate on the same class of mistake drops across repeated runs — would directly test the paper's central claim against this project's own benchmark, not just cite the paper abstractly.

mongodb_distributed_lock is a working reference implementation for the Discord Scylla Control Plane's core requirement

This window's Discord case study names "idempotency as a hard requirement for every task, so any step can retry or resume" as the design property that turned a 1.5-day manual shadow-cluster provisioning process into a 2-hour automated one. mongodb_distributed_lock ("Distributed lock implementation using MongoDB with TTL-based auto-release") is exactly the primitive a workflow engine like Discord's SCP would need to implement the "atomic claim on first write" half of that idempotency guarantee for any multi-step task that must not run concurrently on the same target twice. Worth a documentation note on that project connecting its TTL-lock pattern explicitly to the broader "composable idempotent workflow primitives" pattern this window's case study and the companion idempotent-fleet-workflow-design skill draft (unresolved) describe — the project already has the building block, just not the framing.

Hermes Wiki