Course: Master Course — Harness Engineering (12+ Hours) Module: 0 — The Landscape Section: 0.2 Duration: 15 minutes Level: Senior Engineer and above Prerequisites: Module 0.1 (the three-job definition; the thickness spectrum)
After completing this section, you will be able to:
Module 0.1 gave you the invariant: every harness does three jobs (loop, tools, safety), and the variation between them is thickness. That gets you partway. But "harness" still spans everything from an 80-line personal coding assistant to a 368,000-star platform that runs across 40 messaging channels and is deployed by NVIDIA and Microsoft. Reading those two systems with the same mental machinery is a category error.
The fix is a taxonomy. A taxonomy's job is not to be exhaustively correct — it is to be predictive. Given a harness's category, you should be able to predict roughly where its loop lives, what its tools look like, what it considers "safety," and — critically — where its interesting design decisions hide. The seven categories below do that. They are the organizing frame for this module and for the 21 deep-dives that follow later in the course.
| Category | Definition | tells you |
|---|---|---|
| Terminal harness | CLI-driven, single-agent, code-focused | loop lives in a process you start; tools are filesystem/shell; safety is permission flags |
| Platform harness | multi-channel gateway; agent behind Slack/Telegram/Teams | loop runs behind a messaging gateway; tools are channel-aware; safety is per-channel trust |
| Meta-harness | plugin/config layer that extends a base harness | loop is inherited from the base; the interesting work is routing, subagent hierarchy, skill packs |
| Orchestration framework | graph or role-based multi-agent coordination | there is no "the loop" — there is a state machine or role graph you compose |
| Hardened fork | security/governance-first fork of a base | loop/tools inherited; the entire contribution is the governance layer added outside the agent |
| Academic harness | built for research reproducibility and inspectability | optimized for "can a paper make claims against this," not production |
| SDK / runtime | library of primitives for building your own | you are the harness author; the SDK gives you loop, tool, and sandbox primitives |
The single most important prediction each category gives you is where the interesting engineering lives:
When you read a harness, identify its category first. It tells you which of the 12 rubric modules to read most carefully.
A feature list tells you what a harness does. A lineage map tells you what a harness disagrees with. The second is far more honest. When team B forks or extends team A's work, the diff between them is a direct statement of "A got X wrong." Read the field through lineage and the design tensions become visible.
Aider (2023, Paul Gauthier)
└── created the Polyglot Benchmark; git-first philosophy
└── (influenced) most later CLI harnesses' git integration
Pi (2024, Mario Zechner)
└── oh-my-pi (extends Pi with LSP, browser automation, subagents)
Claude Code (Anthropic, closed source)
└── Claw Code / OpenClaw CLI (March 2026 clean-room rewrite)
└── RyanAlberts skill pack (meta-harness layer)
OpenClaw platform (2025)
├── NemoClaw (NVIDIA, April 2026 — hardened fork)
├── Microsoft Scout (June 2026 — enterprise governance fork)
└── Hermes (Nous Research, Feb 2026 — competitor, NOT a fork)
└── `hermes claw migrate` (migration tool FROM OpenClaw)
OpenCode (2025)
├── oh-my-opencode (Sisyphus + Prometheus planner + Atlas orchestrator)
└── OpenDesign (design-system-aware fork)
OpenAI Agents SDK
└── Codex CLI (separate; Rust; Apache 2.0 — sibling, not child)
Three things to read off this map:
First, OpenClaw's cluster is the most consequential. One platform spawned a NVIDIA hardened fork, a Microsoft enterprise fork, and a direct competitor (Hermes) so aggressive it ships a migration command from OpenClaw. Whatever OpenClaw got right, it also got something wrong enough to generate all three.
Second, oh-my-opencode is the canonical meta-harness. It does not replace OpenCode — it layers a Sisyphus outer agent, a Prometheus planner, and an Atlas orchestrator on top. Studying it teaches you what a base harness lacks that a meta-harness supplies: planning hierarchy, subagent taxonomy, per-agent model assignment.
Third, the absence of lineage is also information. Aider has no notable fork. Pi spawned only extensions, not competitors. These harnesses are finished in a way the OpenClaw cluster is not — which itself tells you where the active design tension lives.
The most instructive comparison in the platform category is OpenClaw against Hermes. They are both platform harnesses. They have made opposite bets.
OpenClaw (Rust + Python, 368,000+ stars, MIT): the breadth play. 40+ messaging channels. NVIDIA and Microsoft partnerships. The #1 platform by total usage until May 2026. The defining architectural debate around OpenClaw is its trust architecture — the way message objects are passed to the model without a clean untrusted-content boundary. That debate is exactly what NemoClaw was forked to fix.
Hermes Agent (Python, 33,000+ stars, MIT): the depth play. Persistent layered memory. Self-evolving skills. The system that overtook OpenClaw on OpenRouter on May 10, 2026 (224B tokens/day; 22T total). Hermes does not compete on channel count — it competes on memory depth and skill evolution.
| Dimension | OpenClaw | Hermes |
|---|---|---|
| Bet | Channel breadth, enterprise adoption | Memory depth, skill evolution |
| Channels | 40+ | fewer; deeper per-channel |
| Memory | conventional | layered, persistent, self-evolving |
| Usage peak | #1 by total until May 2026 | overtook on OpenRouter May 10 2026 |
| Architectural debate | trust boundaries across channels | memory poisoning surface (the cost of depth) |
| What it teaches | platform trust architecture | memory architecture (Module 4) |
Here is the design lesson. Both are correct. OpenClaw optimized for "be everywhere an enterprise already communicates." Hermes optimized for "remember more than any agent has before." A senior engineer who calls one "ahead" of the other has missed the point. They are differently optimized for different buyers — and both generate the exact security problems Course 2 harvests (trust boundaries for OpenClaw; memory poisoning for Hermes).
NemoClaw (NVIDIA, April 2026) and Microsoft Scout (June 2026) are both hardened forks of OpenClaw. They share a single architectural contribution, and it is the most important idea in this module for where the course is going.
The contribution: governance lives beneath the agent, outside its reach.
Most harnesses put safety inside the agent's process — permission flags the agent could in principle subvert, sandbox boundaries the agent shares an environment with, prompt-level instructions the agent reads. NemoClaw and Scout invert this. Policy is enforced by a layer the agent cannot reach: NVIDIA NeMo guardrails evaluating every model call externally; OpenShell sandboxes the agent never touches directly; Scout's Entra identity layer making every action attributable to a non-agent principal.
Why this matters, stated precisely: if the agent can reach the enforcement layer, a compromised agent can disable it. A prompt-injected agent inside a conventional harness can be told to ignore its permission flags, and there is no architectural reason it cannot. A prompt-injected agent inside NemoClaw cannot reach the guardrail layer to disable it — the layer sits between the agent and the world, evaluating every call.
This is not a defensive feature. It is an architectural repositioning. And it is the foundation of the entire Course 2 threat model: when you attack a harness in Module 11 and S10–S13, the first question you ask is "where does enforcement live, and can the agent reach it?" NemoClaw and Scout are the production proof that the answer matters.
Microsoft Scout extends the pattern with Entra-based identity: every agent action is attributable to a non-human principal with scoped credentials. That idea — agents as identity-bearing principals, not shared keys — returns in force in the Fleet Engineering course (Module F06) and in Course 2's OWASP ASI03 (Identity and Privilege Abuse).
Not every harness deserves a full deep-dive. The ecosystem roster tags each one. The course's 21 deep-dives (Module DD-01 through DD-21) are the 🔴 Essential tier. Everything else is context.
The rule of thumb: study the 🔴 tier exhaustively, sample the 🟠 tier for the distinct idea each contributes, and merely be aware of the 🟡 tier so you can place them on the map. A learner who tries to deep-dive all 30+ harnesses in the field will run out of time before reaching the capstone. The priority system exists to prevent that.
One subtlety: study priority is not a quality judgment. A 🟡 harness may be excellent at what it does — it is 🟡 because it is not architecturally distinctive enough to warrant a dedicated session, not because it is inferior. Do not confuse "essential for the course" with "best in class."
GitHub stars measure attention, not architecture. OpenClaw's 368K stars tell you it got attention; they tell you nothing about whether its trust architecture is sound (the evidence suggests it is not, which is why NemoClaw exists). Rank by design intent, read off the lineage map.
The taxonomy is descriptive, not prescriptive. "Terminal harness" is not a lesser category than "platform harness." Pi (terminal) is one of the most important harnesses in the field. OpenHarness (academic) teaches inspectability that no production harness matches. Each category optimizes for something; the senior skill is matching the category to the question you are asking.
You cannot understand NemoClaw without OpenClaw. You cannot understand oh-my-opencode without OpenCode. A fork's entire meaning is its diff from the parent. Studying a hardened fork in isolation reduces it to a feature list and loses the design intent.
This module has given you the landscape: categories, lineage, the central platform tension, and the governance move that prefigures Course 2. Module 0.3 introduces the rubric and methodology you will apply to every harness in that landscape. The 21 deep-dives later in the course then apply that rubric to the 🔴 Essential tier, one harness at a time.
| Term | Definition |
|---|---|
| Terminal harness | CLI-driven, single-agent, code-focused; the loop runs in a process you start |
| Platform harness | Agent behind a messaging gateway (Slack/Telegram/Teams); channel-aware tools and trust |
| Meta-harness | Plugin/config layer extending a base harness; contributes routing and subagent hierarchy |
| Hardened fork | Fork whose entire contribution is a governance layer added outside the agent's reach |
| Lineage map | Parent→child graph of harnesses; the diff between parent and child reveals design intent |
| Governance layer | Policy enforcement that sits between the agent and the world, outside the agent's reach |
| Study priority | 🔴 Essential / 🟠 High / 🟡 Monitor — guides where to invest study time |
Objective: Make the thickness spectrum from Module 0.1 concrete as data, by measuring the actual scale of three harnesses across categories.
Setup: GitHub Codespace or local Git + cloc (npm i -g cloc or brew install cloc).
Steps:
cloc . in each. Record lines by language.Expected output: a three-row LOC table and a one-sentence scale-to-spectrum observation.
Stretch goal: run git log --oneline | wc -l on each to get commit count. A harness with high LOC but low commit count is young and fast-growing; high commit count is mature and iterated. Aider's commit count vs Pi's tells the "3 years of iteration" story as data.
hermes claw migrate migration.# Module 0.2 — The Ecosystem
**Course**: Master Course — Harness Engineering (12+ Hours)
**Module**: 0 — The Landscape
**Section**: 0.2
**Duration**: 15 minutes
**Level**: Senior Engineer and above
**Prerequisites**: Module 0.1 (the three-job definition; the thickness spectrum)
---
## Learning Objectives
After completing this section, you will be able to:
1. Classify any harness into one of seven categories and predict its architecture, failure modes, and the right way to study it from that category alone.
2. Read the harness lineage map and infer what each builder thought the parent system got wrong.
3. Explain the OpenClaw vs Hermes split as a breadth-vs-depth design decision, not a quality contest.
4. State why NemoClaw and Microsoft Scout put governance *beneath* the agent, and why that architectural move is the foundation of Course 2's entire threat model.
5. Use the study-priority system (🔴/🟠/🟡) to decide where to invest your own study time across the field.
---
## 1. Why a Taxonomy Matters Before a Tour
Module 0.1 gave you the invariant: every harness does three jobs (loop, tools, safety), and the variation between them is thickness. That gets you partway. But "harness" still spans everything from an 80-line personal coding assistant to a 368,000-star platform that runs across 40 messaging channels and is deployed by NVIDIA and Microsoft. Reading those two systems with the same mental machinery is a category error.
The fix is a taxonomy. A taxonomy's job is not to be exhaustively correct — it is to be *predictive*. Given a harness's category, you should be able to predict roughly where its loop lives, what its tools look like, what it considers "safety," and — critically — where its interesting design decisions hide. The seven categories below do that. They are the organizing frame for this module and for the 21 deep-dives that follow later in the course.
---
## 2. The Seven Categories
| Category | Definition | tells you |
| --- | --- | --- |
| **Terminal harness** | CLI-driven, single-agent, code-focused | loop lives in a process you start; tools are filesystem/shell; safety is permission flags |
| **Platform harness** | multi-channel gateway; agent behind Slack/Telegram/Teams | loop runs behind a messaging gateway; tools are channel-aware; safety is per-channel trust |
| **Meta-harness** | plugin/config layer that extends a base harness | loop is inherited from the base; the interesting work is routing, subagent hierarchy, skill packs |
| **Orchestration framework** | graph or role-based multi-agent coordination | there is no "the loop" — there is a state machine or role graph you compose |
| **Hardened fork** | security/governance-first fork of a base | loop/tools inherited; the entire contribution is the governance layer added *outside* the agent |
| **Academic harness** | built for research reproducibility and inspectability | optimized for "can a paper make claims against this," not production |
| **SDK / runtime** | library of primitives for building your own | you are the harness author; the SDK gives you loop, tool, and sandbox primitives |
The single most important prediction each category gives you is **where the interesting engineering lives**:
- Terminal harnesses → the loop and tool surface
- Platform harnesses → the trust architecture across channels
- Meta-harnesses → the routing and subagent hierarchy
- Orchestration frameworks → the state machine semantics
- Hardened forks → the governance layer (everything else is inherited)
- Academic harnesses → inspectability and reproducibility
- SDKs → the abstraction boundaries between loop / tool / sandbox
When you read a harness, identify its category first. It tells you which of the 12 rubric modules to read most carefully.
---
## 3. The Lineage Map
A feature list tells you what a harness does. A lineage map tells you what a harness *disagrees with*. The second is far more honest. When team B forks or extends team A's work, the diff between them is a direct statement of "A got X wrong." Read the field through lineage and the design tensions become visible.
```
Aider (2023, Paul Gauthier)
└── created the Polyglot Benchmark; git-first philosophy
└── (influenced) most later CLI harnesses' git integration
Pi (2024, Mario Zechner)
└── oh-my-pi (extends Pi with LSP, browser automation, subagents)
Claude Code (Anthropic, closed source)
└── Claw Code / OpenClaw CLI (March 2026 clean-room rewrite)
└── RyanAlberts skill pack (meta-harness layer)
OpenClaw platform (2025)
├── NemoClaw (NVIDIA, April 2026 — hardened fork)
├── Microsoft Scout (June 2026 — enterprise governance fork)
└── Hermes (Nous Research, Feb 2026 — competitor, NOT a fork)
└── `hermes claw migrate` (migration tool FROM OpenClaw)
OpenCode (2025)
├── oh-my-opencode (Sisyphus + Prometheus planner + Atlas orchestrator)
└── OpenDesign (design-system-aware fork)
OpenAI Agents SDK
└── Codex CLI (separate; Rust; Apache 2.0 — sibling, not child)
```
Three things to read off this map:
**First, OpenClaw's cluster is the most consequential.** One platform spawned a NVIDIA hardened fork, a Microsoft enterprise fork, and a direct competitor (Hermes) so aggressive it ships a migration command *from* OpenClaw. Whatever OpenClaw got right, it also got something wrong enough to generate all three.
**Second, oh-my-opencode is the canonical meta-harness.** It does not replace OpenCode — it layers a Sisyphus outer agent, a Prometheus planner, and an Atlas orchestrator on top. Studying it teaches you what a base harness lacks that a meta-harness supplies: planning hierarchy, subagent taxonomy, per-agent model assignment.
**Third, the absence of lineage is also information.** Aider has no notable fork. Pi spawned only extensions, not competitors. These harnesses are *finished* in a way the OpenClaw cluster is not — which itself tells you where the active design tension lives.
---
## 4. The OpenClaw vs Hermes Split: Breadth vs Depth
The most instructive comparison in the platform category is OpenClaw against Hermes. They are both platform harnesses. They have made opposite bets.
**OpenClaw** (Rust + Python, 368,000+ stars, MIT): the breadth play. 40+ messaging channels. NVIDIA and Microsoft partnerships. The #1 platform by total usage until May 2026. The defining architectural debate around OpenClaw is its *trust architecture* — the way message objects are passed to the model without a clean untrusted-content boundary. That debate is exactly what NemoClaw was forked to fix.
**Hermes Agent** (Python, 33,000+ stars, MIT): the depth play. Persistent layered memory. Self-evolving skills. The system that overtook OpenClaw on OpenRouter on May 10, 2026 (224B tokens/day; 22T total). Hermes does not compete on channel count — it competes on memory depth and skill evolution.
| Dimension | OpenClaw | Hermes |
| --- | --- | --- |
| Bet | Channel breadth, enterprise adoption | Memory depth, skill evolution |
| Channels | 40+ | fewer; deeper per-channel |
| Memory | conventional | layered, persistent, self-evolving |
| Usage peak | #1 by total until May 2026 | overtook on OpenRouter May 10 2026 |
| Architectural debate | trust boundaries across channels | memory poisoning surface (the cost of depth) |
| What it teaches | platform trust architecture | memory architecture (Module 4) |
Here is the design lesson. **Both are correct.** OpenClaw optimized for "be everywhere an enterprise already communicates." Hermes optimized for "remember more than any agent has before." A senior engineer who calls one "ahead" of the other has missed the point. They are differently optimized for different buyers — and both generate the exact security problems Course 2 harvests (trust boundaries for OpenClaw; memory poisoning for Hermes).
---
## 5. NemoClaw, Microsoft Scout, and the Governance Move
NemoClaw (NVIDIA, April 2026) and Microsoft Scout (June 2026) are both hardened forks of OpenClaw. They share a single architectural contribution, and it is the most important idea in this module for where the course is going.
**The contribution: governance lives beneath the agent, outside its reach.**
Most harnesses put safety *inside* the agent's process — permission flags the agent could in principle subvert, sandbox boundaries the agent shares an environment with, prompt-level instructions the agent reads. NemoClaw and Scout invert this. Policy is enforced by a layer the agent cannot reach: NVIDIA NeMo guardrails evaluating every model call externally; OpenShell sandboxes the agent never touches directly; Scout's Entra identity layer making every action attributable to a non-agent principal.
Why this matters, stated precisely: **if the agent can reach the enforcement layer, a compromised agent can disable it.** A prompt-injected agent inside a conventional harness can be told to ignore its permission flags, and there is no architectural reason it cannot. A prompt-injected agent inside NemoClaw *cannot reach* the guardrail layer to disable it — the layer sits between the agent and the world, evaluating every call.
This is not a defensive feature. It is an architectural repositioning. And it is the foundation of the entire Course 2 threat model: when you attack a harness in Module 11 and S10–S13, the first question you ask is "where does enforcement live, and can the agent reach it?" NemoClaw and Scout are the production proof that the answer matters.
Microsoft Scout extends the pattern with Entra-based identity: every agent action is attributable to a non-human principal with scoped credentials. That idea — agents as identity-bearing principals, not shared keys — returns in force in the Fleet Engineering course (Module F06) and in Course 2's OWASP ASI03 (Identity and Privilege Abuse).
---
## 6. Study Priority: Where to Spend Your Time
Not every harness deserves a full deep-dive. The ecosystem roster tags each one. The course's 21 deep-dives (Module DD-01 through DD-21) are the 🔴 Essential tier. Everything else is context.
- 🔴 **Essential** — must study to have a complete picture. The course deep-dives these.
- 🟠 **High** — architecturally distinct enough to warrant focused study.
- 🟡 **Monitor** — worth awareness; full deep-dive optional.
The rule of thumb: study the 🔴 tier exhaustively, sample the 🟠 tier for the distinct idea each contributes, and merely be *aware* of the 🟡 tier so you can place them on the map. A learner who tries to deep-dive all 30+ harnesses in the field will run out of time before reaching the capstone. The priority system exists to prevent that.
One subtlety: study priority is not a quality judgment. A 🟡 harness may be excellent at what it does — it is 🟡 because it is not architecturally *distinctive* enough to warrant a dedicated session, not because it is inferior. Do not confuse "essential for the course" with "best in class."
---
## 7. Anti-Patterns in Reading the Ecosystem
### Anti-Pattern 1: Ranking by stars
GitHub stars measure attention, not architecture. OpenClaw's 368K stars tell you it got attention; they tell you nothing about whether its trust architecture is sound (the evidence suggests it is not, which is why NemoClaw exists). Rank by design intent, read off the lineage map.
### Anti-Pattern 2: Treating categories as quality tiers
The taxonomy is descriptive, not prescriptive. "Terminal harness" is not a lesser category than "platform harness." Pi (terminal) is one of the most important harnesses in the field. OpenHarness (academic) teaches inspectability that no production harness matches. Each category optimizes for something; the senior skill is matching the category to the question you are asking.
### Anti-Pattern 3: Studying forks without the parent
You cannot understand NemoClaw without OpenClaw. You cannot understand oh-my-opencode without OpenCode. A fork's entire meaning is its diff from the parent. Studying a hardened fork in isolation reduces it to a feature list and loses the design intent.
---
## 8. The Course Map
This module has given you the landscape: categories, lineage, the central platform tension, and the governance move that prefigures Course 2. Module 0.3 introduces the rubric and methodology you will apply to every harness in that landscape. The 21 deep-dives later in the course then apply that rubric to the 🔴 Essential tier, one harness at a time.
---
## 9. Key Terms
| Term | Definition |
| --- | --- |
| **Terminal harness** | CLI-driven, single-agent, code-focused; the loop runs in a process you start |
| **Platform harness** | Agent behind a messaging gateway (Slack/Telegram/Teams); channel-aware tools and trust |
| **Meta-harness** | Plugin/config layer extending a base harness; contributes routing and subagent hierarchy |
| **Hardened fork** | Fork whose entire contribution is a governance layer added outside the agent's reach |
| **Lineage map** | Parent→child graph of harnesses; the diff between parent and child reveals design intent |
| **Governance layer** | Policy enforcement that sits between the agent and the world, outside the agent's reach |
| **Study priority** | 🔴 Essential / 🟠 High / 🟡 Monitor — guides where to invest study time |
---
## 10. Lab Exercise: Measure the Ecosystem
**Objective**: Make the thickness spectrum from Module 0.1 concrete as data, by measuring the actual scale of three harnesses across categories.
**Setup**: GitHub Codespace or local Git + `cloc` (`npm i -g cloc` or `brew install cloc`).
**Steps**:
1. Clone Pi, Aider, and oh-my-opencode (or OpenCode).
2. Run `cloc .` in each. Record lines by language.
3. Compute the ratio: how many times larger is each than Pi?
4. Annotate the lineage map (Diagram 2) with each harness's LOC next to its node.
5. Write one sentence: does the scale ordering match the thickness-spectrum ordering from Module 0.1? Where does it diverge, and what does the divergence tell you?
**Expected output**: a three-row LOC table and a one-sentence scale-to-spectrum observation.
**Stretch goal**: run `git log --oneline | wc -l` on each to get commit count. A harness with high LOC but low commit count is young and fast-growing; high commit count is mature and iterated. Aider's commit count vs Pi's tells the "3 years of iteration" story as data.
---
## 11. References
1. **Complete Harness Ecosystem Map** — the course's source roster (categories, lineage, study priority).
2. **OpenClaw documentation and source** — reference for the platform harness pattern and the trust-architecture debate.
3. **Hermes Agent source** — reference for layered persistent memory and the `hermes claw migrate` migration.
4. **NemoClaw (NVIDIA)** — reference for the governance-beneath-the-agent architecture; NeMo Guardrails.
5. **Microsoft Scout announcement (June 2026)** — Entra identity integration; enterprise governance fork.
6. **oh-my-opencode source** — the canonical meta-harness; Sisyphus / Prometheus / Atlas hierarchy.
7. **Aider source** — [github.com/Aider-AI/aider](https://github.com/Aider-AI/aider); the git-first terminal harness and Polyglot Benchmark.
8. **Pi source** — the minimal baseline; ~1,200 LOC reference thin harness.
9. **OpenAI Agents SDK** — sibling relationship to Codex CLI; 2-layer harness/compute split.