When an agent gives a poor answer, the first instinct is often to rewrite the prompt. Sometimes that helps. More often, the agent was missing the current record, had too many irrelevant documents, could not tell which tool was allowed, or had no honest way to say that the evidence was incomplete. Prompt engineering and context engineering are related, but they are not the same job.

A prompt sets the behaviour

Good instructions can explain the role, tone, output format, refusal boundary, and order of operations. They can tell an agent to cite the source, ask one clarifying question, or stop before an external write. That clarity is valuable, especially when the same workflow runs many times.

Context gives the behaviour something real to work with

Context includes the user’s identity, the task state, current evidence, retrieval results, tool results, policy, and the output contract. If the account balance is missing, a more forceful prompt will not make the answer accurate. If the retrieved policy is stale, better wording will not make it current.

Fix the right layer

If the agent is too verbose, change the instruction or output contract. If it uses yesterday’s policy, fix retrieval and freshness. If it sees another tenant’s record, fix the database query and authorization. If it chooses a dangerous tool, narrow the tool and add a server-side check. A useful diagnosis prevents prompt editing from becoming a form of wishful thinking.

Evaluate the complete experience

Keep a small set of real tasks, including ambiguous questions, missing information, prompt injection, tool failure, and high-impact actions. Compare changes by task completion, groundedness, tool choice, refusal quality, latency, and cost. The best prompt is not the one that sounds impressive in isolation; it is the one that helps the whole workflow behave well.