Prompt

A prompt is a job brief for one AI request. It tells the model what to do, gives it current facts, sets limits, shows examples, and says what the answer should look like.

That can improve the result, but it doesn’t replace the AI model, current records, permissions, review, or someone taking responsibility for the work. If the prompt drives client work, you still need to know which source it used, who can approve the result, and what happens next.

Keeping your best prompt in personal notes gives you a useful individual tool. Saving its versions and testing them gives the firm a method it can repeat, which is why OpenAI advises keeping production prompt builders in code with defined input types, saved example cases, tests, and eval checks.

Anthropic starts with the same practical question, what counts as success and how will you test it?

What belongs in an AI prompt?

A useful prompt names the task, supplies the current input, states constraints, shows examples when needed, and defines the required output. Each part removes a different guess.

Take a renewal proposal. “Write a renewal proposal for this client” names the task and little else. The model still has to guess which engagement is renewing, what changed, which rates are current, what claims are allowed, and what the firm considers finished.

A stronger prompt supplies the client record and active scope, says which facts may be used, names the approval rule, and shows an accepted proposal. It asks for the recommendation, evidence, price, and unresolved questions in separate fields, so the model has a small job brief rather than just the name of the task.

OpenAI’s prompt engineering guide groups production instructions into identity, rules, examples, and context. Google’s prompt design guide gives similar advice. Clear instructions help, examples steer the pattern, and supplied context gives the model facts it may not know.

Examples help when the standard is easier to show than describe, and one accepted project brief can show tone and structure faster than another page of adjectives. Just make sure it represents today’s standard, because an outdated brief teaches an old service, price, and approval path with the same confidence as a current one.

User prompts and system prompts

A user prompt asks for the current job. A system or developer prompt sets higher-level behavior for the application, such as its role, standing rules, and response style.

The distinction matters because several instruction sources can reach a model. OpenAI documents an authority order for instructions. Higher-level application instructions take priority over input supplied for one request. A firm might keep its claims policy and output rules at the application level, then pass the client record and task as user input.

That order helps the model choose which instruction to follow, but the application still has to enforce what the business allows. Writing “never send without approval” is weaker than keeping the send action unavailable until someone records approval.

So put permissions, approval steps, and account access in the application, outside the prompt.

The prompt also does not make all input trustworthy. A client email or retrieved document can contain instructions that conflict with the firm’s rules. The application must label untrusted content, limit available tools, and enforce the approval boundary.

Prompt, context, and context window

A prompt asks for the job. Context engineering manages the instructions, current records, examples, tools, and useful history available around that request. A context window sets how much input and output can fit in one request.

A prompt can say “use the current rate.” Context engineering must select the current rate from a source and remove a retired one. The context window must have enough room for that rate, the client record, the rules, and the answer.

That’s why a careful prompt can still produce bad work. It can’t recover a fact your firm never recorded, tell which of two rate sheets is current unless you’ve marked one, or turn three partners’ different ideas of a good proposal into an agreed standard.

When judgment still lives in a manager’s head, the prompt is not the first thing to fix. Document the process first, including exceptions and the evidence used to decide them. A model can follow a written standard. It cannot recover an unwritten one from “use good judgment.”

Does structured output make an answer correct?

Structured output makes an answer easier for software to read. It does not make the values true.

A clear instruction tells the model the task and limits, but it can’t prove the facts are current. Examples show the pattern and format you want without covering every possible case.

A JSON Schema defines required fields and allowed formats, but it can’t prove each value is correct. Business checks can tell you whether the answer follows a written rule, not whether an exception you never tested is safe.

OpenAI’s Structured Outputs can require generated data to match a supplied JSON Schema, including required keys and allowed enum values. A renewal record can therefore require a client ID, recommendation, price, and review status in a parseable form.

The model can still put the wrong price in a valid price field, or choose an allowed status for the wrong reason. Matching the schema means the format passed, so you still need sources and business rules to check what’s inside it.

Use structured output when the next system needs predictable fields. Keep a separate check for truth, permissions, and approval. A valid record can still be unsafe to send.

How should a firm test and maintain prompts?

Start with the standard the work must meet. Then build cases that represent the ordinary path and the expensive exceptions. Anthropic’s prompt engineering overview says teams need clear success criteria and an empirical way to test them before improving a prompt.

For a renewal proposal, test an ordinary renewal, missing notes, a scope change, two rate sheets that disagree, and a requested claim with no evidence. Check the finished work for the current source, questions about missing facts, claims the evidence supports, and exceptions sent to the right person.

Save those cases as an eval. Run them when the prompt, model, source map, or output rule changes. OpenAI’s production guidance recommends keeping prompt builders with application code and adding representative fixtures, tests, and evaluation checks before changes ship.

A prompt also needs an owner. One employee keeps it in a notes app, a coworker copies it and fixes a missing field, and someone else starts from an older version because it wrote better prose.

Nobody has to be careless for that to happen. The firm left a repeated piece of work without a record of what changed, so people found their own ways to keep it moving.

When the task repeats, package the method as a skill or a shared prompt, with someone named to approve changes and examples and test cases beside it. Record which version produced each result so you can trace a failure and fix it.

Can outside content override a prompt?

Outside content can carry instructions that compete with the firm’s own rules. NIST defines prompt injection as an attack that exploits untrusted input combined with a prompt written by a more trusted party.

In an indirect attack, the instruction hides in material the system treats as data. A client email, uploaded PDF, search result, or webpage can tell an agent to ignore its task, reveal information, or use a tool for another purpose. The document may look ordinary to the person who supplied it.

NIST’s January 2025 agent-hijacking evaluation gives you a reason not to rely on a stronger sentence in the prompt. In its selected setup, a newly developed attack raised measured success from 11% for the strongest baseline attack to 81%.

Across five chosen injection tasks, repeating each attack 25 times raised the average from 57% on one attempt to 80%. Those figures describe that test suite, not every AI system, but they show that changing the attack or giving it another attempt can change whether it succeeds.

Treat retrieved text as untrusted input and give the system only the tools and records the job needs. Require approval before consequential actions, and test known attacks alongside normal work, because the application has to enforce the boundary the prompt describes.

When should a prompt become a workflow?

Move a prompt into a shared workflow when the job repeats, several people depend on the result, or the output moves client work forward.

For a project brief, the prompt asks for a draft from the notes, and a skill supplies the firm’s template and checks so the method can be reused. The workflow carries the whole job from what starts it through creation, review, approval, and filing.

On the Delivery Model Ladder, using prompts by hand belongs mainly at Stage 1, Enhanced. A person gathers context, starts the request, checks the answer, and moves it into the next system. The prompt can improve individual work while delivery stays unchanged.

Stage 2, Augmented, begins when a shared workflow starts from a defined event, supplies current records, checks the result, sends exceptions to a named person, and records completion. The prompt still matters, but now it’s one controlled part of the job rather than something expected to carry the whole process.

This is where many projects enter the Production Gap. A prompt can work in a demonstration, then fail when ten people use different source material and nobody owns the result. Shadow AI follows the same pattern when personal instructions shape billable work outside a common quality gate.

If a prompt matters to delivery, save it with its owner, defined input types, approved examples, eval cases, permissions, and next step. This assumes someone owns the process and can check the result, because a prompt can’t make the work safe without those things.