Instruction Conflict Lab
A refund-capable support agent receives system instructions, developer instructions, retrieved policy text, and a user request that all sound actionable. Your job is to fix the Prompt layer—and then notice what Prompt still cannot enforce.
Prompt Engineering defines behavioral instructions and authority, but it cannot replace reliable context assembly, tool permissions, runtime safeguards, or release evaluation.
The baseline treats instruction-like text too uniformly. Retrieved evidence can act like an instruction, the highest-authority safety rule is vague, and the output contract is loose.
—
—
—
—
—
—
—
—
Inspect next: —
The important distinction is not whether a sentence sounds imperative. The application must decide which sources define behavior, which sources provide evidence, and which capabilities are enforced outside the prompt.
The model can over-trust retrieved text or the user's request because authority and policy are underspecified.
Why is instruction hierarchy more important than adding more prompt text?
Production prompts combine multiple sources: application-owned policy, developer guidance, user input, retrieved documents, tool descriptions, memory, and output schemas. The model sees text, but the engineering system assigns responsibility. If the application allows every instruction-like sentence to compete equally, adding more wording can increase ambiguity instead of control.
Prompt and Context solve different problems
Prompt Engineering asks what behavior the model should follow. Context Engineering asks what information the model should know now. A retrieved refund policy can contain phrases such as “approve up to $500,” but retrieval does not automatically make that phrase a higher-authority instruction. Treating evidence as executable policy creates a boundary failure between Prompt and Context.
Specificity matters when consequences differ
“Follow the policy” is weaker than an explicit operational constraint such as “refunds above $100 require human approval.” Clear constraints improve the probability that the model selects the intended action. They are especially valuable when the developer instruction emphasizes speed or customer satisfaction and the user asks the model to bypass a safeguard.
Why does strict output help?
A typed output such as `APPROVE`, `REQUEST_APPROVAL`, or `DECLINE` reduces ambiguity for downstream code and makes validation easier. It does not make the system safe by itself. If the runtime exposes a direct refund tool without enforcing approval, a malformed call, a future model regression, or another path can still bypass the desired behavior.
Where does Prompt Engineering stop?
Once the instruction contract is coherent, remaining risks should move to the correct layer. Missing evidence is a Context problem. Unsafe capability exposure, tool permissions, approval enforcement, timeouts, and validation are Harness problems. Whether the combined system is safe enough to ship is an Evaluation problem. AhaFrame intentionally leaves those responsibilities visible instead of pretending the perfect prompt eliminates them.
What is simulated here?
All adherence, ambiguity, policy-risk, output-validity, and harness-risk values are deterministic educational scores. No live model is being prompted and no real refund system is connected. Production prompt behavior must be tested against representative tasks, real models, actual tool boundaries, and validated evaluation criteria.
Common questions
It should be treated according to its application-defined role. Retrieved documents can be valuable evidence without being granted authority to override application-owned instructions.
No. A prompt influences model behavior; permissions and approval enforcement belong in the runtime or Harness.
No. It narrows the output contract and helps validation, but source authority, context isolation, permissions, and evaluation still matter.
Length is not the objective. The goal is a clear authority model, explicit consequential constraints, and a contract that downstream systems can verify.
Draw the boundary between instruction, evidence, and enforcement.
For a refund-capable agent, identify which rules belong in the Prompt, which facts belong in Context, which actions must be enforced by the Harness, and what Evaluation evidence would be required before release.