harness-node-splitter

Harness Node Splitter

Overview

The horizontal workflow graph says what the agent should do; the harness executes it. Before the harness can run anything, the workflow must be split into nodes with focused responsibilities. The chapter gives one rule that cuts through the design space:

Nodes differ by tool surface, not by prompt.

The sharpest example is security tooling. Kyle Polley's RedAI splits vulnerability discovery across two roles whose distinction is entirely tool-level. The scanner node holds a filesystem and threat-models source code (optimized for recall). The validator node holds a browser driver, an iOS simulator, a network stack, and a scripting runtime, and drives each candidate into a live environment. Swap the prompts and nothing changes — the validator can still drive the browser because it holds the tool. The role lives in the tool surface.

The chapter's Tip operationalizes this:

Before you add a node, list the tools it will call. If the list overlaps more than 80% with an existing node, you have a prompt variation of that node — merge them and vary the prompt. If the tool lists differ substantially, split.

This skill applies that rule to candidate operations and emits each node's constrained context scope — the tool surface it may invoke, the memory slices it reads/writes, and the input/output contract the schema validator holds it to (three of the harness's six surfaces). A tool-less reasoning node (like Example 2-3's classify vs analyze) is distinguished by prompt and DAG position, not tools, so tool-less nodes default to split.

When to Use

• Turning a horizontal-workflow sketch into executable nodes
• Auditing an existing workflow for the common failure mode: one retrieval-and-reasoning node that both queries the graph and does causal analysis, with neither pass at specialist quality
• Deciding whether a proposed new node is a real role or a prompt variation of an existing one (the Tip as a pre-add gate)