How it works
Prompt engineering turns an operating intention into instructions a model can interpret at inference time. A prompt may define the task, assign a role, provide relevant examples, establish boundaries, describe available tools, and specify the expected output. The model then conditions its response on those elements and the rest of the assembled context.
In a production harness, prompt construction is usually a sequence:
- The harness identifies the current task and authoritative workflow state.
- It assembles instructions, evidence, tool descriptions, and relevant history.
- It marks boundaries between trusted instructions and untrusted content.
- It asks for an output that can be inspected or validated.
- The harness evaluates the result before permitting another action or state transition.
Ordering and specificity matter because prompts contain competing signals. A concrete task contract generally provides better direction than broad role language. Examples can clarify an output pattern, but they can also introduce accidental rules or stale assumptions. More context is not automatically better; irrelevant material can obscure the current objective.
Prompt engineering remains probabilistic. It can influence model behavior, but it cannot guarantee compliance. A sentence such as “never delete files” is useful guidance, not an authorization control. The harness must enforce that boundary outside the prompt.
Why it matters in an agent harness
Prompts sit at the point where deterministic software delegates judgment to a model. Poorly designed prompts make that handoff ambiguous. The model may optimize the wrong objective, use evidence inconsistently, produce an unparseable result, or continue acting after the task should have stopped.
Good prompt engineering makes the delegation legible. An operator should be able to inspect a prompt and answer: What decision was delegated? What evidence was available? Which uncertainty should the model expose? What output does the next component expect? Those questions matter more than whether the wording sounds sophisticated.
Prompts also affect observability. If instructions require the model to return explicit decisions, source identifiers, rejected alternatives, or uncertainty fields, the harness gains useful evidence for evaluation and incident analysis. This does not mean requesting unrestricted hidden reasoning. It means designing outputs that expose the operational facts needed by downstream controls.
The boundary is equally important. Prompts should not carry responsibilities that software can enforce more reliably. Permission checks, spending limits, schema validation, approval requirements, stop conditions, and irreversible-action controls belong in code or policy. Treating prose as enforcement creates a control surface that is difficult to test and easy for conflicting context to weaken.
Prompt changes should therefore be versioned and evaluated like behavioral code. A small wording change can alter tool selection, refusal behavior, or output structure without causing a conventional test failure. Regression cases should cover successful work, ambiguous inputs, hostile content, missing evidence, and attempts to exceed delegated authority.
Prompt engineering vs context engineering
The distinction changes where an engineer looks when behavior fails. Prompt engineering designs the instructions and examples that direct the model. Context engineering designs the larger information environment presented for a particular model call, including retrieved evidence, workflow state, memory, tool descriptions, and prior results.
| Design question | Prompt engineering | Context engineering |
|---|---|---|
| Primary concern | What the model is asked to do | What the model is allowed to see for this decision |
| Typical inputs | Instructions, roles, examples, output rules | Evidence, state, memory, tool metadata, selected history |
| Common failure | Ambiguous or conflicting direction | Missing, stale, excessive, or untrusted information |
| Main evaluation | Behavioral compliance and output quality | Relevance, provenance, isolation, and context sufficiency |
They overlap because instructions are part of context. The practical separation is ownership: prompt engineering shapes the decision policy expressed to the model, while context engineering controls the information assembled around that policy. Fixing one does not necessarily repair the other. A precise instruction cannot recover missing evidence, and perfect retrieval cannot resolve a contradictory task contract.
The Rifty take
We treat prompts as versioned behavioral interfaces, not as the system’s security boundary. We optimize for explicit delegation, inspectable outputs, and prompts that are small enough to evaluate. We accept that model behavior remains variable, then contain that variability with permissions, validators, checkpoints, and execution limits outside the prompt.
Implementation checks
- State the delegated decision, completion condition, and expected artifact explicitly.
- Separate trusted instructions from retrieved pages, user content, and tool output.
- Pass authoritative workflow state instead of asking the model to infer it from a transcript.
- Require source identifiers or first-party proof for claims that enter final artifacts.
- Use schemas or deterministic validators when downstream code depends on output shape.
- Enforce permissions, budgets, approvals, and irreversible-action boundaries outside the prompt.
- Keep examples narrow, current, and consistent with the written instructions.
- Version prompts with the evaluations that justify each material change.
- Test missing evidence, conflicting instructions, prompt injection, malformed tool results, and stop conditions.
- Record the effective prompt and context inputs in an execution trace without leaking secrets.
Frequently asked questions
Can prompt engineering enforce permissions?
No. Prompt engineering can tell a model which actions are appropriate, but it cannot enforce authorization. The harness should restrict available tools, credentials, arguments, and write scopes in code. Prompt instructions remain useful for intent alignment, while deterministic controls prevent an incorrect or manipulated model decision from crossing the permission boundary.
How should prompt changes be tested?
Test prompt changes against a versioned set of representative and adversarial cases. Measure task completion, output validity, evidence use, tool choice, boundary compliance, and stopping behavior. Include missing context and malformed inputs. Compare behavioral regressions before deployment rather than accepting a few plausible sample responses as sufficient evidence.
How much context should a prompt include?
Include the smallest context that preserves the task contract, authoritative state, necessary evidence, and relevant tool guidance. Extra context can create conflicts, hide important instructions, and increase evaluation difficulty. If information is useful only for another stage, keep it out of the current model call and pass a structured result instead.
What belongs in the prompt versus the harness?
Put judgment guidance, task goals, examples, and output expectations in the prompt. Put authorization, state transitions, validation, budgets, retries, approval gates, and irreversible-action controls in the harness. A useful rule is that anything requiring a guarantee should not depend solely on the model interpreting prose correctly.