The harness matters more than the prompt
Prompt quality plateaus quickly. The scaffolding around the model — contracts, validation, retries, routing, evaluation — is what makes a workflow dependable.
Teams spend months refining prompts and weeks building everything else, which is exactly backwards. Prompt improvements show sharply diminishing returns. Harness improvements compound.
A harness is the scaffolding that turns a model call into a system: typed contracts, validation, retries, routing, memory boundaries, observability, and evaluation.
Components worth building properly
- Typed tool contracts. Tools take validated arguments and return validated structures. No free-text handoffs between steps.
- Structured output with hard validation. Parse failures are errors, not something to paper over with a repair prompt.
- Bounded retries with variation. Retry with a changed strategy, cap the attempts, and record every one.
- Explicit routing. Confidence thresholds, business rules, and escalation paths live in code where they can be reviewed.
- Deliberate context construction. Decide what enters the window and why; do not append history indefinitely.
- Idempotency. External actions carry keys so a retry cannot double-send, double-book, or double-post.
- Cost and latency budgets per run, enforced rather than monitored after the fact.
- Trajectory capture as a first-class output of every run, not a debug log.
Why this order pays
A strong harness makes model upgrades routine. Swap the model, run the regression suite, read the delta, decide. Without one, every upgrade is a leap of faith and most teams simply stop upgrading — which is its own risk.
It also localizes failure. When something goes wrong in a well-built harness, the trajectory tells you which step, which tool, and which input. In a prompt-centric system, you are guessing.