Harness² vs DSPy
Last updated: October 19, 2026
DSPy compiles pipelines against a metric; Harness² improves the harness from behavioural comparison. A side-by-side on target, weights and data needs.
Both frameworks optimize something other than the model weights, which makes the comparison worth doing carefully — the difference is in what gets optimized and what feedback drives it.
Different optimization targets
DSPy compiles a pipeline: you declare modules and a metric, and it searches for prompts (and, in some configurations, weights) that score well against that metric. The signal is your metric on your data.
Harness² optimizes the harness — prompts, tools, memory, skills and orchestration together — and it does so from behavioural comparison across multiple runs on the same task. The README describes Propose–Probe–Compose as not relying on ground-truth feedback.
The practical consequence
DSPy's approach needs a metric you can compute and data to compute it on. Harness²'s approach needs tasks the agent can attempt and runs you can compare. If you have clean labels and a scoring function, DSPy's path is direct. If your tasks are professional work where "correct" is expensive to label, the comparison-driven path is the point.
Side by side
| Dimension | Harness² | DSPy |
|---|---|---|
| What is optimized | The harness around the model | Pipeline prompts (and optionally weights) |
| Modifies model weights | No | Not in the default prompt-optimization path |
| Needs labelled data or a metric | Not for the Propose–Probe–Compose step | Yes — a metric is the optimization signal |
| Feedback source | Behavioural comparison across runs | Metric score on your data |
| Scope | Eight components including tools, memory and orchestration | Modules and their prompts within a pipeline |
DSPy entries above are limited to what its official documentation states. Verify against the current DSPy docs before relying on a specific row.