Every prior attempt at "the agent config file" tried to be everything at once.
That's why they stayed rough drafts. A file that declares identity, reasoning, contracts, orchestration, and economics all at once has no coherent audience: the person validating a skill's interface doesn't want to read your model-routing policy, and the person auditing a reasoning trace doesn't care about your host sandbox config. Collapsing five concerns into one schema means every consumer wades through fields meant for someone else.
The stack takes the opposite bet: one file per axis, each independently useful, each independently adoptable. A team can ship COVENANT.md alone to harden their skill library and never touch the other three. A solo builder can adopt MARCHESE.md purely for the gotcha ledger. The moment a system's shape justifies it, the files compose, but composition is never the price of entry.
One sentence describes the whole stack in motion.
This is the canonical composition line, verbatim from the spec. Every clause names exactly one file and exactly one thing that file governs.
Each file answers exactly one question a prose CLAUDE.md can't.
LOGIC.md
"In what order, under which contracts, does the thinking proceed?"
Step DAGs, typed handoffs between reasoning stages, quality gates with retry and self-verification, per-step tool permissions, fallback and escalation chains.
COVENANT.md
"What may a caller depend on?"
A skill's domain, its public interface, its dependencies, typed input/output contracts, and the fixtures that prove it meets them, declared beside SKILL.md, before implementation.
HARNESS.md
"Where, and under what isolation, does execution actually run?"
Team composition, orchestrator, leads, workers, tool bindings, shared state, the control loop, model rotation, sandbox rules, and approval gates for a multi-agent team.
MARCHESE.md
"How is compute spent, and how does the system learn from spending it?"
Context budgets, Minimum Viable Model routing, an append-only gotcha ledger, 4-block orchestration loops, and a self-improving knowledge layer.
Four independent projects. Visit each one for the full case.
Declares agent reasoning as structured contracts: step DAGs, output schemas, tool permissions, quality gates. Validated at compile time, executed deterministically, auditable by default.
Declares what a skill is on five axes, domain, interface, dependencies, contracts, quality, beside SKILL.md, validatable before a line of implementation is written.
An open, declarative, executable manifest for multi-agent teams: orchestrator, leads, workers, tool bindings, control loop, model rotation. The harness-md repo's own Python reference implementation is still unbuilt; a separate, unpublished prototype already executes HARNESS.md manifests end to end.
Declares the economics of an agent system: context budgets, MVM routing, an append-only gotcha ledger, 4-block loops, and a self-improving knowledge layer.
What makes four files a stack, and not just four unrelated ideas.
No file duplicates another's authority
Reasoning flow, skill boundaries, execution substrate, and spend policy are governed by exactly one file each. If a field could plausibly live in two files, that's a design bug in the stack, not a feature.
Every file is independently useful
None of the four requires the others to justify its existence. COVENANT.md hardens a skill library with zero LOGIC.md in sight. MARCHESE.md's gotcha ledger pays off in a project with no multi-agent orchestration at all.
Composition is additive, never required
When two files do meet, a LOGIC.md step invoking a COVENANT.md-bound skill, the reference is explicit and one-directional. Removing a file never breaks another; it just leaves that axis ungoverned.
Portable format, pluggable runtime
Every file is markdown plus YAML frontmatter: readable without tooling, diffable in a normal PR, and parseable by any runtime in any language. The reference implementations are TypeScript-first with Python SDKs; nothing about the format requires either.
Honest about what's shipped and what isn't
Three of the four have working validators, test suites, and published packages. The fourth, HARNESS.md, has a locked architecture-decision-record and no published engine: a private prototype (Drivetrain) exists but is unpublished, single-author, and unproven against a live model. That's stated plainly here, not smoothed over with README theater.
Adopt in the order your system actually needs, not this order.
There's no mandated sequence. This table reflects what tends to pay off first, not a dependency chain.
| File | Adopt first if… | Smallest useful unit |
|---|---|---|
| LOGIC.md | You have a multi-step pipeline where one agent's output feeds another and the handoff needs to be enforceable, not just described in prose. | A single step's output contract with one quality gate. |
| COVENANT.md | You maintain a library of skills that other skills, agents, or humans depend on, and the boundary needs to be explicit. | Domain and interface on one existing skill, no fixtures yet. |
| HARNESS.md | You're running or planning a genuine multi-agent team, orchestrator plus leads plus workers, not a single-agent pipeline. | Not published. A private single-day prototype (Drivetrain) already runs a demo HARNESS.md team end to end; no live LLM run is recorded yet. |
| MARCHESE.md | The same edge case keeps resurfacing across sessions and you want it remembered, or your sessions run long enough that context tax is a real cost. | The gotcha ledger alone, with everything else left unset. |
Four files. Four axes. Read each one on its own terms.
Every page in the family gets the same treatment: honest disclosure on what's measured versus claimed, and no README theater.
Evidence: compiled from the logic-md, covenant-md, harness-md, marchese-method, and declarative_agent repositories on 2026-08-03. Every number on this page traces to a file path or command output in the source trees. Last updated: 2026-08-03.