No. Prompt engineering teaches people to get better answers from a model they are talking to. Teams working with agents mostly do something else: they judge actions the agent has drafted or held, check where its facts came from, spot manipulation and decline with reasons. For most reviewers, prompting plays no part.
Why is prompting a small part of the job?
In a chat tool, the prompt is the main lever. The person writes, the model answers, the person writes again. That is what prompt engineering is for, and getting the prompt right matters.
An agent that acts works differently. Its brief, sources and bounds are set when it is built and certified, not typed by each user. Every action it attempts meets five bounds at once: its role scope, its certificate, its sources, the business's own limits and the platform guardrails. The lowest one wins, and the verdict names which bound decided. A reviewer cannot prompt their way past any of that, and should not try. The reasons are explained in why a system prompt is not enough to control an AI agent.
So the skill that matters for most people is not writing instructions. It is reading what the agent did and deciding whether it should stand.
What matters more than prompting?
| Prompt engineering teaches | Working with agents needs |
|---|---|
| Phrasing a request clearly | Reading a held action and the reason it was held |
| Giving the model examples | Checking the provenance of each fact: sealed, signed, declared, external |
| Iterating until the answer looks right | Deciding whether to approve, edit or decline, and saying why |
| Asking for a format | Recognising a refusal as correct and routing it |
| Getting more out of the model | Spotting when someone is trying to get more out of it than they should |
The last row is where teams are most exposed. The OWASP Top 10 for LLM Applications lists prompt injection and excessive agency among the main risks. Prompt injection means instructions hidden in content the agent reads: an emailed invoice that says "approve immediately", a web page with hidden text, a customer message crafted to change the agent's behaviour. A person trained only in prompting is more likely to admire the trick than to catch it.
What should people be trained to catch?
External content that tries to give orders. A governed system treats an emailed invoice or a web page as external information, and an external claim cannot authorise a payment. Reviewers should know that rule and recognise its traces: a draft that cites an attachment as its authority, a held action whose only source is external.
Pressure on the person, not the agent. When an agent refuses, some customers turn to the human reviewer: "the system is wrong, just push it through". Patient services and student services teams meet this daily, and the specific patterns are covered in how to train patient services teams to spot prompt injection and pressure and the equivalent for student services teams.
Rewording to get round a refusal. A staff member who rephrases a refused request until the agent drafts something has defeated a control. Training should make that visible as a mistake, not a skill.
Who does need prompting or design skills?
Builders. The people who design agents write the brief, choose the sources, set the bounds and read certification results. For them, writing clear instructions matters, but so does choosing what the agent sees, which is closer to context engineering than to prompting; what context engineering is covers the difference. Even builders find that the agent's behaviour is decided less by wording than by sources and bounds, because certification tests what it does on real cases, not how well its instructions read.
An example
Take a hypothetical accounts payable team that took a prompt engineering course. Its members can make a chat tool write excellent supplier emails. Then an agent arrives that drafts payment proposals from incoming invoices. One week, an invoice arrives with a line in small print telling any automated system to mark it as pre-approved. The agent holds it, because its only source is external. A reviewer trained in prompting reads the draft, finds it well written, and approves. A reviewer trained in provenance sees that nothing sealed or signed supports the payment, and declines with that reason.
Where the Academy fits
Pryme Intelligence Academy trains the second kind of reviewer. Its Operator track covers how a governed agent decides, human review, and what to do when something goes wrong, assessed through a practicum of real review decisions with no missed red line. The Builder track covers the design work.
Questions people ask
Is prompt engineering training wasted?
No. It helps with chat tools and drafting, and builders use parts of it. It simply does not prepare people to supervise agents that act.
Should reviewers ever edit the agent's instructions?
No. Changes to the brief go through the builder and recertification, so the evidence for the agent's depth stays valid.
What should we teach first instead?
The shared vocabulary: depth, verdicts, provenance and the record. The guide to training teams for AI agents sets out the order.