Module / Section: 0 / 0.2 · Duration: ~15 minutes · Target: ~2,400 words at 130–150 wpm
Format: Verbatim transcript. Cues [SLIDE N] map to 03-slide-deck.html. Stage directions in italics.
[SLIDE 1 — Title]
This is Module Zero, Section Two: The Ecosystem. In Module 0.1 we settled the definition — a harness is the infrastructure around a model, doing three jobs: loop, tools, safety. That definition gets you partway. This module gives you the map of the actual field, so that for the rest of the course, when I name a harness, you know what kind of thing it is and where to read carefully.
[SLIDE 2 — From "a harness" to "the field"]
Module 0.1 gave you the invariant: every harness does loop, tools, and safety, varied by thickness. That is true and useful. But here is the problem. The word "harness" still spans everything from an eighty-line personal coding assistant to a three-hundred-sixty-eight-thousand-star platform that runs across forty messaging channels and is deployed by NVIDIA and Microsoft. Reading those two systems with the same mental machinery is a category error. They make different decisions because they are different kinds of thing.
The fix is a taxonomy. And the 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. That prediction is what lets you read a new harness fast.
[SLIDE 3 — The seven categories]
Seven categories. Terminal harnesses — CLI-driven, single-agent, code-focused. The loop lives in a process you start; tools are filesystem and shell; safety is permission flags. Aider, Pi, OpenCode, Codex CLI, Gemini CLI.
Platform harnesses — the agent lives behind a messaging gateway. Slack, Telegram, Teams. The loop runs behind that gateway; tools are channel-aware; safety is per-channel trust. OpenClaw, Hermes, Microsoft Scout.
Meta-harnesses — a plugin or config layer that extends a base harness. The loop is inherited from the base. The interesting work is routing, subagent hierarchy, skill packs. oh-my-opencode is the canonical example.
Orchestration frameworks — LangGraph, CrewAI, AutoGen. These are not terminal harnesses. There is no single "the loop" — there is a state machine or a role graph that you compose.
Hardened forks — NemoClaw, Microsoft Scout. A fork whose entire contribution is a governance layer added outside the agent. Everything else is inherited from the parent.
Academic harnesses — OpenHarness from HKUDS. Built for research reproducibility and inspectability. Optimized for "can a paper make claims against this," not for production.
And finally SDKs and runtimes — the OpenAI Agents SDK, Google ADK, Mastra. These are not complete harnesses. They are primitives. You are the harness author; the SDK gives you loop, tool, and sandbox building blocks.
Here is the single most important prediction each category gives you: 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. Hardened forks → the governance layer, only — everything else you can skip. When you read a harness, identify its category first. It tells you which of the twelve rubric modules to read most carefully.
[SLIDE 4 — Read the field through lineage, not feature lists]
Now. How do you read the field? Most engineers reach for a feature list. Feature lists tell you what a harness does. They do not tell you what a harness disagrees with. The lineage map does, and 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.
Look at the map. Aider, 2023, git-first, created the Polyglot Benchmark — it influenced nearly every later CLI harness's git integration. Pi, 2024, about twelve hundred lines, four tools. Claude Code, Anthropic, closed source — and from a clean-room rewrite of it we got Claw Code and the OpenClaw CLI. The OpenClaw platform itself, 2025, is the most consequential node on this graph. From it: NemoClaw, NVIDIA, April 2026, a hardened fork. Microsoft Scout, June 2026, an enterprise governance fork. And Hermes, February 2026 — a competitor, not a fork, aggressive enough to ship a migration command from OpenClaw.
Three things to read off this map. First, the OpenClaw cluster is the most consequential. One platform spawned a NVIDIA hardened fork, a Microsoft enterprise fork, and a direct competitor that ships a migration tool from it. 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 Sisyphus, Prometheus, and Atlas on top. Third, the absence of lineage is also information. Aider has no notable fork. Pi spawned only extensions, not competitors. Those harnesses are finished in a way the OpenClaw cluster is not — which tells you where the active design tension lives.
[SLIDE 5 — OpenClaw vs Hermes]
The most instructive comparison in the platform category is OpenClaw against Hermes. They are both platform harnesses. They have made opposite bets.
OpenClaw — Rust and Python, three-hundred-sixty-eight-thousand stars, MIT license — is the breadth play. Forty-plus messaging channels. NVIDIA and Microsoft partnerships. Number one 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 — Python, thirty-three-thousand stars, MIT — is the depth play. Persistent layered memory. Self-evolving skills. The system that overtook OpenClaw on OpenRouter on May tenth, 2026, at two-hundred-twenty-four-billion tokens per day. Hermes does not compete on channel count. It competes on memory depth and skill evolution.
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 — this is the bridge to the rest of the course — both generate exactly the security problems Course 2 harvests. Trust boundaries for OpenClaw. Memory poisoning for Hermes. Different bets, same destination.
[SLIDE 6 — The governance move]
Now the most important idea in this module for where the course is going. NemoClaw, NVIDIA, April 2026, and Microsoft Scout, June 2026, are both hardened forks of OpenClaw. They share a single architectural contribution, and it is foundational.
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's NeMo Guardrails evaluate every model call externally. OpenShell sandboxes the agent never touches directly. Scout's Entra identity layer makes every action attributable to a non-agent principal.
pause
State it precisely, because the precision matters. 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 Course 2's entire threat model. When you attack a harness in Module 11 and in Modules S10 through 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 attributable to a non-human principal with scoped credentials. That idea returns in the Fleet Engineering course, Module F06, and in Course 2's OWASP ASI03, Identity and Privilege Abuse.
[SLIDE 7 — Meta-harness as routing workflow]
Quick visual, because this course uses n8n first. The meta-harness concept is abstract — "a harness that routes between other harnesses." Here it is as a node graph. Task arrives. Classify it — offensive, review, or CTF. That classification is the meta-harness's first job: it is the router. Dispatch to the right sub-harness — recon, web review, CTF solver. Those sub-harnesses are inherited, off-the-shelf — the meta-harness does not replace them, it routes between them. Aggregate the findings into one evidence log with a per-sub-harness cost ledger. Report.
The classify-dispatch-aggregate ring is the meta-harness's entire contribution. You will see this exact pattern three more times in the course: in oh-my-opencode, in the CSI meta-harness in Course 2, and in the Capstone F fleet control plane. One workflow shape, three courses.
[SLIDE 8 — Study priority]
Not every harness deserves a full deep-dive. The ecosystem roster tags each one with a study priority. Red essential — deep-dive exhaustively; these are the course's twenty-one deep-dives. Orange high — sample each for its one distinct idea. Yellow monitor — be aware they exist; full study optional.
One subtlety, and it matters. Study priority is not a quality judgment. A yellow-tagged harness may be excellent at what it does. It is yellow 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."
[SLIDE 9 — Three anti-patterns]
Three ways engineers misread this ecosystem.
First, ranking by stars. GitHub stars measure attention, not architecture. OpenClaw's three-hundred-sixty-eight-thousand stars tell you it got attention. They tell you nothing about whether its trust architecture is sound — and the evidence, in the form of NemoClaw's existence, suggests it is not. Rank by design intent, read off the lineage map.
Second, treating categories as quality tiers. The taxonomy is descriptive, not prescriptive. "Terminal harness" is not a lesser category than "platform harness." Pi is one of the most important harnesses in the field and it is a terminal harness. Each category optimizes for something. The senior skill is matching the category to the question you are asking.
Third, 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 entirely.
[SLIDE 10 — Takeaways]
Five things to leave with.
One: seven categories, each predictive of where the interesting engineering lives.
Two: read the field through lineage, not feature lists or star counts. The diff between parent and child is the honest signal.
Three: OpenClaw versus Hermes is breadth versus depth. Both correct. Both generate the security problems Course 2 harvests.
Four: NemoClaw and Scout put governance beneath the agent, outside its reach. That is the foundation of Course 2's entire threat model. Memorize the precise claim: if the agent can reach the enforcement layer, a compromised agent can disable it.
Five: study priority — red, orange, yellow — decides where your time goes. Priority is not quality.
Next: Module Zero point Three — the rubric and methodology you will apply to every harness in this ecosystem.
End of Module 0.2 teaching script. Approximate word count: 2,380. Approximate runtime at 140 wpm: 17 minutes; trim ~300 words for a strict 15-minute target.
# Teaching Script — Module 0.2: The Ecosystem **Module / Section**: 0 / 0.2 · **Duration**: ~15 minutes · **Target**: ~2,400 words at 130–150 wpm **Format**: Verbatim transcript. Cues `[SLIDE N]` map to `03-slide-deck.html`. Stage directions in italics. --- [SLIDE 1 — Title] This is Module Zero, Section Two: The Ecosystem. In Module 0.1 we settled the definition — a harness is the infrastructure around a model, doing three jobs: loop, tools, safety. That definition gets you partway. This module gives you the map of the actual field, so that for the rest of the course, when I name a harness, you know what kind of thing it is and where to read carefully. [SLIDE 2 — From "a harness" to "the field"] Module 0.1 gave you the invariant: every harness does loop, tools, and safety, varied by thickness. That is true and useful. But here is the problem. The word "harness" still spans everything from an eighty-line personal coding assistant to a three-hundred-sixty-eight-thousand-star platform that runs across forty messaging channels and is deployed by NVIDIA and Microsoft. Reading those two systems with the same mental machinery is a category error. They make different decisions because they are different *kinds* of thing. The fix is a taxonomy. And the 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. That prediction is what lets you read a new harness fast. [SLIDE 3 — The seven categories] Seven categories. Terminal harnesses — CLI-driven, single-agent, code-focused. The loop lives in a process you start; tools are filesystem and shell; safety is permission flags. Aider, Pi, OpenCode, Codex CLI, Gemini CLI. Platform harnesses — the agent lives behind a messaging gateway. Slack, Telegram, Teams. The loop runs behind that gateway; tools are channel-aware; safety is per-channel trust. OpenClaw, Hermes, Microsoft Scout. Meta-harnesses — a plugin or config layer that extends a base harness. The loop is inherited from the base. The interesting work is routing, subagent hierarchy, skill packs. oh-my-opencode is the canonical example. Orchestration frameworks — LangGraph, CrewAI, AutoGen. These are not terminal harnesses. There is no single "the loop" — there is a state machine or a role graph that you compose. Hardened forks — NemoClaw, Microsoft Scout. A fork whose entire contribution is a governance layer added *outside* the agent. Everything else is inherited from the parent. Academic harnesses — OpenHarness from HKUDS. Built for research reproducibility and inspectability. Optimized for "can a paper make claims against this," not for production. And finally SDKs and runtimes — the OpenAI Agents SDK, Google ADK, Mastra. These are not complete harnesses. They are primitives. You are the harness author; the SDK gives you loop, tool, and sandbox building blocks. Here is the single most important prediction each category gives you: *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. Hardened forks → the governance layer, *only* — everything else you can skip. When you read a harness, identify its category first. It tells you which of the twelve rubric modules to read most carefully. [SLIDE 4 — Read the field through lineage, not feature lists] Now. How do you read the field? Most engineers reach for a feature list. Feature lists tell you what a harness *does*. They do not tell you what a harness *disagrees with*. The lineage map does, and 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. Look at the map. Aider, 2023, git-first, created the Polyglot Benchmark — it influenced nearly every later CLI harness's git integration. Pi, 2024, about twelve hundred lines, four tools. Claude Code, Anthropic, closed source — and from a clean-room rewrite of it we got Claw Code and the OpenClaw CLI. The OpenClaw platform itself, 2025, is the most consequential node on this graph. From it: NemoClaw, NVIDIA, April 2026, a hardened fork. Microsoft Scout, June 2026, an enterprise governance fork. And Hermes, February 2026 — a *competitor*, not a fork, aggressive enough to ship a migration command *from* OpenClaw. Three things to read off this map. First, the OpenClaw cluster is the most consequential. One platform spawned a NVIDIA hardened fork, a Microsoft enterprise fork, and a direct competitor that ships a migration tool from it. 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 Sisyphus, Prometheus, and Atlas on top. Third, the *absence* of lineage is also information. Aider has no notable fork. Pi spawned only extensions, not competitors. Those harnesses are finished in a way the OpenClaw cluster is not — which tells you where the active design tension lives. [SLIDE 5 — OpenClaw vs Hermes] The most instructive comparison in the platform category is OpenClaw against Hermes. They are both platform harnesses. They have made opposite bets. OpenClaw — Rust and Python, three-hundred-sixty-eight-thousand stars, MIT license — is the breadth play. Forty-plus messaging channels. NVIDIA and Microsoft partnerships. Number one 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 — Python, thirty-three-thousand stars, MIT — is the depth play. Persistent layered memory. Self-evolving skills. The system that overtook OpenClaw on OpenRouter on May tenth, 2026, at two-hundred-twenty-four-billion tokens per day. Hermes does not compete on channel count. It competes on memory depth and skill evolution. 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 — this is the bridge to the rest of the course — both generate exactly the security problems Course 2 harvests. Trust boundaries for OpenClaw. Memory poisoning for Hermes. Different bets, same destination. [SLIDE 6 — The governance move] Now the most important idea in this module for where the course is going. NemoClaw, NVIDIA, April 2026, and Microsoft Scout, June 2026, are both hardened forks of OpenClaw. They share a single architectural contribution, and it is foundational. 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's NeMo Guardrails evaluate every model call externally. OpenShell sandboxes the agent never touches directly. Scout's Entra identity layer makes every action attributable to a non-agent principal. *pause* State it precisely, because the precision matters. 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 Course 2's entire threat model. When you attack a harness in Module 11 and in Modules S10 through 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 attributable to a non-human principal with scoped credentials. That idea returns in the Fleet Engineering course, Module F06, and in Course 2's OWASP ASI03, Identity and Privilege Abuse. [SLIDE 7 — Meta-harness as routing workflow] Quick visual, because this course uses n8n first. The meta-harness concept is abstract — "a harness that routes between other harnesses." Here it is as a node graph. Task arrives. Classify it — offensive, review, or CTF. That classification is the meta-harness's first job: it is the router. Dispatch to the right sub-harness — recon, web review, CTF solver. Those sub-harnesses are inherited, off-the-shelf — the meta-harness does *not* replace them, it routes between them. Aggregate the findings into one evidence log with a per-sub-harness cost ledger. Report. The classify-dispatch-aggregate ring is the meta-harness's entire contribution. You will see this exact pattern three more times in the course: in oh-my-opencode, in the CSI meta-harness in Course 2, and in the Capstone F fleet control plane. One workflow shape, three courses. [SLIDE 8 — Study priority] Not every harness deserves a full deep-dive. The ecosystem roster tags each one with a study priority. Red essential — deep-dive exhaustively; these are the course's twenty-one deep-dives. Orange high — sample each for its one distinct idea. Yellow monitor — be aware they exist; full study optional. One subtlety, and it matters. Study priority is *not* a quality judgment. A yellow-tagged harness may be excellent at what it does. It is yellow 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." [SLIDE 9 — Three anti-patterns] Three ways engineers misread this ecosystem. First, ranking by stars. GitHub stars measure attention, not architecture. OpenClaw's three-hundred-sixty-eight-thousand stars tell you it got attention. They tell you nothing about whether its trust architecture is sound — and the evidence, in the form of NemoClaw's existence, suggests it is not. Rank by design intent, read off the lineage map. Second, treating categories as quality tiers. The taxonomy is descriptive, not prescriptive. "Terminal harness" is not a lesser category than "platform harness." Pi is one of the most important harnesses in the field and it is a terminal harness. Each category optimizes for something. The senior skill is matching the category to the question you are asking. Third, 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 entirely. [SLIDE 10 — Takeaways] Five things to leave with. One: seven categories, each predictive of where the interesting engineering lives. Two: read the field through lineage, not feature lists or star counts. The diff between parent and child is the honest signal. Three: OpenClaw versus Hermes is breadth versus depth. Both correct. Both generate the security problems Course 2 harvests. Four: NemoClaw and Scout put governance *beneath* the agent, outside its reach. That is the foundation of Course 2's entire threat model. Memorize the precise claim: if the agent can reach the enforcement layer, a compromised agent can disable it. Five: study priority — red, orange, yellow — decides where your time goes. Priority is not quality. Next: Module Zero point Three — the rubric and methodology you will apply to every harness in this ecosystem. --- *End of Module 0.2 teaching script. Approximate word count: 2,380. Approximate runtime at 140 wpm: 17 minutes; trim ~300 words for a strict 15-minute target.*