Four recurring harness topologies. Each is connected back to the theory, and
each has a runnable lab in ../labs.
[Task] -> [Agent / LLM] -> [Output] -> [Verifier] -> [Accept?]
Theory. One path. Few observable internal boundaries. The bottleneck is often hidden inside the agent. Low trace resolution: when output is wrong, the trace cannot localize the cause.
Demo: 01-single-agent-wrapper.
[Task] -> [Context] -> [Agent / LLM] -> [Verifier] -> [Accept?]
^
|
[Repo / Docs / Memory]
Theory. Adds an inspectable context edge. We can measure context relevance,
context loss, stale memory, and missing information. Common bottleneck:
Context -> Agent.
Demo: 02-context-aware-harness.
[Task] -> [Context] -> [Agent] -> [Verifier] -> [Accept?]
^ |
| |
+---fail-----+
Theory. Adds a feedback edge. Error becomes signal. The loop can improve, oscillate, or saturate. Useful for debugging convergence.
Demo: 03-feedback-harness.
/-> [Path A] -\
[Task] -> [Shared Context] -> [Compare / Verify] -> [Accept?]
\-> [Path B] -/
Theory. Multiple paths carry candidate flow. Compare quality/cost/error and
choose the path with the highest useful-flow score Φ. Can reveal bottlenecks
and route around weak paths.
Demo: 04-parallel-multipath-harness.
The graph exposes tradeoffs before any agent code is written:
| Pattern | Pros | Cons / new failure mode |
|---|---|---|
| Single-agent wrapper | simple, low coordination cost | low observability, hidden bottlenecks |
| Context-aware harness | better input shaping, measurable context quality | wrong / stale context |
| Feedback harness | enables improvement | requires good error signals; can oscillate or saturate |
| Parallel harness | explores alternatives, higher chance of accepted output | higher comparison and coordination cost |