Prompt engineering vs harness engineering: where to start

Prompt engineering improves the instructions given to a model. Harness engineering improves the system in which the model works, including context selection, tools, state and verification. Start with the layer that caused the failure. A clearer instruction cannot restore a disconnected account, and another integration cannot clarify an ambiguous request.

Diagnose before adding instructions

Suppose an assistant writes proposals with the wrong service scope. Read the input it actually received. If the approved scope was present but poorly described, improve the instruction and examples. If an outdated document was retrieved, fix source selection. If no scope was available, introduce a missing-information path.

Adding a long warning to the prompt may hide the distinction for a while. The next task can fail differently because the underlying information problem remains.

Keep a small failure worksheet

• Expected result: what should the assistant have produced?
• Available evidence: which source and version reached the model?
• Observed behavior: what did it generate or attempt?
• Enforcement: which system boundary should have stopped the error?
• Retest: what example will show the problem is fixed?

Keep private customer details out of reusable test fixtures. A representative synthetic example often reproduces the failure without copying a real conversation into a development system.

Make one change at a time

For an instruction problem, change the relevant sentence or add a contrasting example. For an execution problem, change the tool contract or permission rule. Run the original failing case alongside a normal one. A fix that blocks every action is not a useful improvement.

Only then consider a broader redesign. Otherwise the team cannot tell whether quality improved because of a better prompt, a new model or a changed retrieval path.

A practical boundary

Use instructions for judgment and explanation. Use application code for constraints that must hold on every run, such as account identity, allowed destinations and required approval. Models can help interpret intent, but the execution system should decide whether an action is permitted. This division keeps the prompt readable and the operating rules testable.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.