0. Four Layers, Four Responsibilities
The word harness is overloaded. This guide uses four layers so a model, a runtime, a repository setup, and a fleet manager are not treated as interchangeable products.
| Layer | Responsibility | Examples | What it does not replace |
|---|---|---|---|
| Model | Generates and reasons over tokens | Claude, GPT, Gemini, DeepSeek, Qwen | Tools, policy, durable state, or execution |
| Runtime harness | Runs the agent loop and mediates tool use, context, permissions, and recovery | Claude Code, Codex, Gemini CLI, DeepSeek Harness, OpenCode | Project-specific instructions and delivery gates |
| Repository harness | Makes one codebase legible and verifiable to a runtime | CLAUDE.md/AGENTS.md, init.sh, lockfiles, task state, tests; Liza's installed contracts and guardrails | The runtime's model routing, tool loop, or sandbox |
| Orchestrator | Coordinates multiple runs, workspaces, or harnesses | Symphony, Vibe Kanban, AgentBox, Proliferate, Liza | The underlying runtime agent loop |
The boundary is practical. If a product can only schedule or inspect Claude Code and Codex sessions, it is an orchestrator. If it supplies an iterative model-and-tools loop itself, it is a runtime harness. If it is committed with the repository and tells any compatible runtime how to work safely, it is a repository harness.
A product can span two layers without owning all four. Liza installs behavioral contracts, skills, settings, and guardrails into a repository, then coordinates external coding-agent CLIs through worktrees, durable task state, leases, doer/reviewer roles, recovery, and merge gates. Claude Code, Codex, or another selected CLI still owns the inner tool loop. The Landscape profile records the pinned code evidence and security limits.
The term meta-harness is overloaded. In the optimizer research covered by this page, a harness optimizer or meta-harness proposes changes to a target harness, evaluates candidates, and promotes or rejects versions. Some products and practitioner articles use meta-harness for a different role: a common client that dispatches tasks to Claude Code, Codex, Cursor, Pi, or another runtime. Under this guide's taxonomy, a system that selects or coordinates existing harnesses without modifying and evaluating them is an orchestrator or control plane, not a harness optimizer.
Loop, graph, harness, and orchestrator are different views
These terms answer different questions. Treating them as competing product categories hides the boundary that matters.
| View | Primary question | Core artifact |
|---|---|---|
| Loop engineering | What feedback repeats, and what stops the repetition? | Goal, action, observation, verification, stopping rule |
| Graph engineering | Which nodes, edges, state transitions, joins, and checkpoints are executable? | Versioned workflow graph and shared state schema |
| Harness engineering | What context, tools, policy, state, verification, and recovery bound execution? | Runtime and repository controls |
| Orchestration | How are runs, workspaces, queues, budgets, and people coordinated? | Scheduler or control plane |
Loop Engineering is a useful practitioner label for replacing repeated manual prompts with a system that finds work, dispatches it, checks it, and decides what happens next. It is not a formal standard. Graph Engineering in the Era of LLM Agents and What Makes Prompts a Graph propose a broader graph-engineering vocabulary, but both are recent preprints. The mechanisms are older than the label: the official LangGraph Graph API already models shared state, nodes, fixed or conditional edges, and parallel super-steps, while its persistence layer provides checkpoints, interruption, replay, and fault recovery.
A loop can be encoded as a graph. A graph can coordinate several loops. A harness can execute either while adding permissions, context, tools, verification, and recovery. An orchestrator can schedule several harnesses without owning their inner loops. Compare products inside the same layer before comparing feature counts.