Skip to main content

Where this comes from

In August 2026 we ran a full-source review of three agent-orchestration systems — reading implementations, not READMEs, and separating genuinely-built capability from aspiration:

oh-my-claudecode

Hook-enforced execution guarantees, battle-tested across thousands of users. Its enforcement hooks each trace to a real production failure.

ruflo

Self-verification machinery: witness manifests, behavioral smoke-test CI, temporal memory semantics.

ralph

The fresh-context loop: 113 lines of bash proving statelessness can be the architecture.
The review’s seven deep-dive passes catalogued 63 features (nine passes in total, including a ZO baseline map and an adversarial synthesis), then distilled them to the 12 below — deduplicated, ranked by leverage against ZO’s documented failure modes, and stripped of the things those repos get wrong (we documented 11 anti-patterns we are explicitly not copying, from keyword-triggered orchestration to self-asserted completion). The conclusion in one line: ZO’s oracle discipline stays; underneath it we’re adding a deterministic enforcement plane, a machine-readable control plane, a fresh-context execution substrate, and an oracle for the platform itself.

The 12 features

Organized into five layer-based workstreams. The source repo is provenance, not architecture — features from different repos interlock into single mechanisms.

Workstream A — Enforcement plane

What spawn prompts promise, hooks now guarantee.

Workstream B — Control plane

Progress becomes a query, not prose interpretation.

Workstream C — Execution substrate

The failure unit becomes one iteration, not one 38-hour session.

Workstream D — Self-learning & platform oracle

The self-evolution loop gets the same rigor ZO applies to ML work.

Workstream E — Operator experience

Observe/notify/control as load-bearing infrastructure.

How it ships

The build follows ZO’s own discipline — the plan lives at plans/zo-v2-rearchitecture.md with a full oracle:
  1. Plan — six gated phases (enforcement → control plane → substrate → platform oracle → operator UX → integration), each with named verification checks agreed before work starts.
  2. Build — every feature lands as a PR with a seeded-failure test: the enforcement mechanism must catch a deliberately planted violation before it merges. Nothing ships unwired — no mechanism merges without a runtime caller and an observable test.
  3. Test — the 854-test platform suite stays green on Python 3.11 and 3.12 throughout; new mechanisms add their own unit + integration coverage.
  4. Verify — 20 oracle verification checks (tiered must/should/could), ending with a full demo project run where every new mechanism is observed firing — and a substrate go/no-go: the fresh-context loop must match v1’s demo accuracy at ≤ 1.15× cost before it becomes the default.
  5. Ship — phase-gated releases; the roadmap and this page track progress.

What we’re deliberately not copying

The review also produced an anti-pattern catalog — dead code presented as capability, unverified performance claims, keyword-triggered orchestration, self-asserted completion, verification theater, surface-area maximalism. These are encoded in the plan’s anti-scope and enforced in review. ZO’s small, honest surface is the asset we’re protecting.