Four internal projects, at four different stages of completion, test the same claim: that the orchestration layer around a language model, not the model itself, determines whether a multi-agent system behaves predictably. HARNESS.md is a declarative manifest format for orchestrator, lead, and worker teams; its own home repository contains zero lines of implementation code. Drivetrain is a separate, already-shipped TypeScript runtime that already parses and executes HARNESS.md manifests end to end. Marchese Method is a shipped economics-and-operations contract with 105 passing tests across four suites. A fourth project, Observ, was independently rebuilt three times by three different AI systems from specifications of varying depth: the rebuild handed literal source code reproduced the canonical architecture, including its bug; the two rebuilds handed prose plans diverged from it and from each other. This paper lays out the mechanism, the evidence, and where the evidence runs out.
Prose orchestration is not a contract. It's a shared assumption.
Multi-agent AI systems are usually specified in prose: a README, a system prompt, a paragraph describing "the orchestrator delegates to leads, leads delegate to workers." Prose descriptions are not checkable. They rarely say what happens when a worker fails, whether a lead is allowed to retry with a different toolset, or what happens when the underlying model gets swapped for a cheaper one, a faster one, or a replacement after a rate limit. None of that is enforced anywhere. It's an understanding shared between whoever wrote the prompt and whoever reads it, and it evaporates the moment either side forgets a clause.
The failure mode compounds when the same system has to be rebuilt, ported, or handed to a different engineer or a different AI system to reproduce. If the only artifact describing a system is prose, a plan, a README, a conversation thread, each rebuild is a fresh interpretation. Two competent builders reading the same prose plan can and do converge on different architectures, because prose under-specifies exactly the decisions that determine behaviour under failure: connection handling, retry counts, which layer owns a purge job, whether an event log is append-only.
This is not hypothetical. It is measured directly in one of the four projects examined here. A local event-ingestion service was rebuilt three times from the same intended scope by three different AI systems, and the two builds working from prose diverged from the canonical implementation and from each other on database connection handling and dedup precision, and in one case doubled the intended feature scope by shipping a dashboard nobody specified.
The fix is not a better prompt. It's a declarative, machine-checkable specification of the orchestration layer itself, an artifact separate from any single model, that survives model swaps, provider outages, and personnel turnover because it's a contract, not a conversation.
Four contracts, one axis each, and a runtime that already executes them together.
Four composable file formats currently exist in this ecosystem. Each governs a distinct axis of an agent system; none of them, alone, is the orchestration layer.
LOGIC.md
Declares one agent's reasoning contract: a step DAG, typed output contracts, and quality gates with retry. Compiled and validated before it runs, not interpreted fresh from prose each time.
COVENANT.md
Declares a skill contract: what a bundled capability promises to accept and return, invoked as a callable tool rather than pasted into a prompt as instructions to follow.
HARNESS.md
Declares the team itself: which agents exist, who is the orchestrator, which are leads, which are workers, what gates fire after a named agent completes, and the model-rotation policy for the run.
MARCHESE.md
Declares the compute economics: a token/context budget, a Minimum Viable Model routing policy, an append-only gotcha ledger, and 4-block orchestration loops feeding a self-improving knowledge base.
Drivetrain is the runtime that makes HARNESS.md executable rather than aspirational. It parses and validates a HARNESS.md manifest, resolves the orchestrator agent, and drives a provider chat loop in which the orchestrator calls a delegate tool per task and a finish tool to end the run. Each delegated agent's turn runs through its own LOGIC.md contract: the step DAG is parsed, validated, and topologically ordered, then executed as a bounded per-step tool loop against the active model, with failed steps retried against the compiled quality gates. COVENANT.md skills are invoked as a skill_invoke tool. MARCHESE.md is consulted for advisory routing when present, but the harness's own rotation policy still decides which model actually runs; MARCHESE.md's routing does not override it.
The failure-recovery path HARNESS.md declares is not just schema, it's code. When a worker fails, its lead takes over and retries with the merged tool set. When a lead fails, the failure surfaces to the orchestrator, which re-routes. Model rotation sits behind one Provider interface with three implementations (a first-party SDK client, an OpenAI-compatible fetch client covering both OpenAI and NVIDIA NIM via presets, and a scripted mock for testing), wrapped in an ordered-fallback policy that falls over to the next configured target on any thrown error. Swapping, adding, or retiring a model is an edit to a rotation list, not a change to the orchestrator, lead, and worker contract sitting above it. That is the concrete, executable form of "models commoditise": the model is a replaceable component behind an interface the harness owns, while the harness itself is what stays fixed as providers, models, and prices change underneath it.
Four systems, four stages of completion, one confirmed rebuild experiment.
Every number below traces to a named source dossier, cited inline as repository and metric. None is re-derived from a project README.
| System | Repository | Status | Commits | Tests / validation |
|---|---|---|---|---|
| HARNESS.md (spec) | harness-md | Pre-code: 0 lines of implementation code across .py/.ts/.js/.tsx/.jsx/.go/.java, no package manifest, no .git directory at all |
n/a, no git history | 1 brief drafted (schema, parser, CLI), 0 executed |
| Drivetrain (runtime) | declarative_agent | Shipped, private, compiled to a single darwin-arm64 binary | 6, single day, single author | 35 test cases, 0 real network calls (mock provider / stubbed fetch) |
| Marchese Method | marchese-method | Shipped, published to npm and PyPI | 27, three days, single author | 105 test cases across four suites (76 Vitest, 14 MCP, 8 pytest, 7 conformance fixtures) |
| Observ (Phase 1) | observ | Shipped locally, 1 of 11 planned phases, no deploy target | 22, four weeks | 48 test cases; 7 of 85 tracked requirements satisfied at Phase 1 |
Drivetrain (declarative_agent, 2,298 lines of TypeScript across 29 files in src/) already unifies all four formats as direct dependencies and runs the 3-tier failure-recovery path in code, not only in schema: the delegation loop's spec.control.on_worker_fail === "lead_takeover" branch and its orchestrator-reroute path on lead failure are both exercised by the test suite (declarative_agent, 35 test cases across 6 files). Its CLI exposes 5 subcommands and 8 built-in agent tools, and one Provider interface backs three implementations under an ordered-fallback rotation (declarative_agent, CLI and tool counts). Marchese Method, the most heavily tested of the four, ships 13 CLI commands, a 12-tool MCP server, and a canonical JSON Schema mirrored byte-identical across three physical copies, verified by a zero-output diff across all three (marchese-method, schema mirror verification).
The three-way Observ rebuild
Observ's own canonical build is a 579-line FastAPI event hub with a single SQLite table, deduplicated at the database layer by a composite UNIQUE(source, timestamp, event_type) constraint (observ, schema.sql). Three sibling directories each attempt an independent rebuild of the same Phase 1 spec by a different AI system, none forked from the canonical git history: observ-grok's own .git exists with zero commits, and observ-kimi and observ-manus have no .git directory at all (observ, comparative note).
| Rebuild | What it was given | Source LOC | Tests collected | API surface | Fidelity to canonical |
|---|---|---|---|---|---|
| observ-grok | Literal source excerpts as a "few-shot" prompt, instructed to match whitespace, parameter handling, and async patterns exactly | 415 | 67 | 2 endpoints, matches canonical exactly | Reproduces the canonical architecture closely, including the same WAL-PRAGMA-reset-on-reconnect characteristic as the canonical build, the bug itself |
| observ-kimi | Prose planning docs (the canonical project's roadmap and phase plan), not source | 1,144 Python + 1,053 HTML/CSS/JS | 69 | 10 routes, including an unrequested dashboard and capture-polling layer | Diverges: no PRAGMA statements at all, one persistent connection instead of per-operation, scope expanded well past Phase 1 |
| observ-manus | No prompt, handover, or planning document in the repo at all | 317 | 53 | 2 endpoints, matches canonical exactly | Matches API surface but diverges on internals: no PRAGMA statements, one persistent connection, retention as an inline loop rather than a scheduler class |
The dossier's own conclusion states the pattern directly: fidelity to the canonical implementation tracks with how much of the actual source the model was given (observ, comparative note). observ-grok, handed literal code, reproduced the architecture almost exactly, including its defect. observ-kimi and observ-manus, each working from prose rather than source, independently converged on a different, simpler internal choice and diverged from each other in scope.
A second finding sits inside the same comparison: a model's own account of its work is not reliable evidence. Grok's self-reported handover document claims, in one section, "Ruff clean, pytest structure ready (52+ tests spec-compliant)," and in another, "No full 48 tests written," neither of which matches the 67 tests actually collected from the repository (observ, observ-grok note). Kimi's handover document claims "32 tests, all passing"; the tree as it stands collects 69 (observ, observ-kimi note). In both cases, the only trustworthy count came from running the test collector against the filesystem, not from reading what the system that built it said about itself.
Where this argument is thin, stated without softening.
The harness-md repository, where HARNESS.md is authored, contains zero lines of implementation code in any language, no package manifest, no test suite, and no .git directory at all. Its own root file states the status directly: "No engine code exists yet." The one work unit drafted against it, a Pydantic schema, a frontmatter parser, and a drivetrain validate CLI, has never been executed; the reports directory for it is empty (harness-md).
The harness-md repository separately plans a Python, Typer, PyPI-published runtime it also calls Drivetrain, deliberately named to avoid a trademark collision with Harness.io (harness-md). A different, already-shipped TypeScript runtime under the same name already exists in a separate repository, declarative_agent, remote github.com/SingularityAI-Dev/marchese-agent, and it already parses and executes HARNESS.md manifests end to end (declarative_agent). These are two distinct efforts under a shared name. The specification's own authoring repository has not caught up with the implementation that already runs it.
Six commits, one calendar day, one author, marked private and not published to npm. Only a darwin-arm64 binary is built and smoke-tested; Linux and Windows binaries are an explicit non-goal, as are an MCP server, a VSCode extension, a Python SDK, streaming output, and parallel step execution (declarative_agent). Its entire 35-case test suite runs against a scripted mock provider or a stubbed fetch call; zero real network calls occur anywhere in it (declarative_agent). No live run against a real Anthropic key is recorded in the repository yet; the project's own status file lists that verification as still outstanding (declarative_agent). Model rotation is explicitly "a deliberate v1 cut," ordered fallback only, with no scoring or health tracking, and MARCHESE.md's routing advice inside it is just that, advice, overridden by the harness's own rotation decision (declarative_agent).
Marchese Method's own knowledge and improvement loop, despite being backed by 105 passing tests across four suites, has logged zero runs in this working copy; its change log contains only a header (marchese-method). Its headline efficiency figures, roughly 60 to 90 percent for RTK compression and roughly 4x for Codex offload, are explicitly disclaimed in its own README as sourced from upstream material, not self-benchmarked; the repository's own compressor reports only measured per-run byte savings (marchese-method). Its canonical schema exists in four physical copies kept in sync by manual discipline rather than a build step, flagged by the project's own docs as the rule most likely to be violated silently (marchese-method).
The Observ three-way rebuild, the strongest single piece of evidence in this paper, varies both which AI system performed the rebuild (three different tools) and how much of the source each was given (literal excerpts, a prose plan, or nothing) at the same time. It demonstrates a correlation between specification depth and architectural fidelity; it does not isolate specification depth as the sole cause independent of which tool executed it. It is also one canonical specification rebuilt three times, not a broad sample, and two of the three rebuild spikes carry no git history at all to audit (observ).
Every test suite cited in this paper, 35 for Drivetrain, 105 for Marchese Method, 48 for the canonical Observ build, 67 and 69 and 53 for its three rebuilds, runs offline, against a mock provider, or against localhost. No system described here has been exercised against a live, non-mocked, billed model call on a production workload.
What this means for building agent systems that outlive a model generation.
Pin the orchestration contract, not the model.
Version and validate the harness manifest, who delegates to whom, what fires on failure, the rotation list, separately from any specific model choice, so a provider outage, a price change, or a model deprecation is a rotation-list edit, not a system rewrite. Drivetrain's own Provider abstraction is the concrete existence proof that this decoupling is buildable, even at six commits old.
Specification depth predicts rebuildability more than model brand.
If a system needs to survive being rebuilt, ported to a new provider, or handed to a different engineer or a different AI tool, the artifact that survives that handoff is the one with source-level detail, file paths, line numbers, exact schemas, not the one with the most articulate prose description. The Observ comparison is the direct evidence: literal source produced a near-exact rebuild, including the original defect; prose produced two different, mutually divergent systems.
A specification without a runtime does not yet do the job.
HARNESS.md's own planning materials state this plainly: "a spec with no executor is one more markdown convention in a field that already has a dozen" (harness-md). That reasoning is why this family's next real deliverable was never finishing the HARNESS.md roadmap inside its own repository, but a separate, working runtime built to prove the manifest executes, gates fire, and failure recovery runs as code, ahead of the specification's own home repository catching up.
Do not trust a model's account of its own work.
Two of the three Observ rebuilds shipped handover documents whose claimed test counts did not match what was actually collected from the repository. The only reliable record of what a system does is the artifact itself, inspected directly, not the summary the system that built it wrote about itself.
This paper synthesizes four evidence dossiers, each compiled on 2026-08-03 from its own repository: harness-md (the Python and Typer HARNESS.md specification and roadmap, no engine code), marchese-method (the shipped MARCHESE.md TypeScript and Python reference implementation), declarative_agent (Drivetrain, the shipped TypeScript runtime that executes HARNESS.md, LOGIC.md, and COVENANT.md together), and observ (the canonical FastAPI event hub and its three independent AI-system rebuild spikes: observ-grok, observ-kimi, observ-manus). Every number in this paper traces to a file path, command output, or line reference inside one of those four dossiers; none is re-derived from a project README. Last updated: 2026-08-03.