Prompt

A prompt is a job brief for one AI request. It can name the task, provide current facts, set limits, show examples, and define the shape of the answer. That can improve one result. It does not replace the AI model, current records, permissions, review, or ownership. OpenAI advises teams to keep production prompt builders in code with typed inputs, fixtures, tests, and eval checks. Anthropic says prompt work should start with a clear success measure and a way to test it. A service firm that keeps its best prompt in personal notes has a useful individual tool. A firm that versions and tests the prompt has a repeatable method. When the prompt drives client work, the surrounding process still needs to show which source was used, who can approve the result, and what happens next.

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. It says which facts may be used, names the approval rule, shows one accepted proposal, and asks for fields covering the recommendation, evidence, price, and unresolved questions. The instruction becomes a small job brief.

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. One accepted project brief can teach tone and structure faster than another page of adjectives. The example must represent today’s standard. 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. The surrounding application still decides what the business allows. A line that says “never send without approval” is weaker than software that withholds the send action until an approver records a decision. Permissions, approval gates, and account access belong 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.

This boundary explains why a careful prompt can still produce bad work. It cannot recover a fact the firm never recorded. It cannot know which of two rate sheets is current unless the firm marks one as authoritative. It cannot turn three partners’ different ideas of a good proposal into one 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.

Control	What it can establish	What it cannot establish
Clear instruction	The requested task and constraints	That supplied facts are current
Examples	The desired pattern and format	That one example covers every case
JSON Schema	Required fields and allowed value shapes	That each value is correct
Business validation	Whether output meets a written rule	That an untested exception 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. It can choose an allowed status for the wrong reason. Schema conformance checks the container. Source checks and business rules check the contents.

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, the cases might include an ordinary renewal, missing notes, a scope change, two rate sheets that disagree, and a requested claim with no evidence. Score the finished work. Did the prompt use the current source? Did it ask about missing facts? Did it keep claims inside the evidence? Did it route the exception 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. Someone else starts from an older version because it produced nicer prose. Nobody has to be careless for the method to split. The firm has left a repeated piece of work without a change record.

When the task repeats, package the method as a skill or shared prompt module. Name who approves changes. Keep examples and test cases beside it. Record which version produced each output so a failure can be traced and repaired.

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 shows why a stronger sentence is a weak defense. 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. They show that attacks can succeed differently when the method changes or gets another attempt.

Treat retrieved text as untrusted input. Give the system only the tools and records needed for the job. Require approval before consequential actions. Test known attacks beside normal work. A prompt can state the boundary. The application must enforce it.

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.

Part	Main job	Service-firm example
Prompt	Ask for one result	Draft a project brief from these notes
Skill	Reuse one method	Apply the firm’s brief template and checks
Workflow	Carry work from trigger to record	Create, review, approve, and file every brief

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 supplies current records, starts from a defined event, runs checks, sends named exceptions to a person, and records completion. The prompt still matters. It becomes one controlled part of the work instead of carrying 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, store it with its owner, typed inputs, approved examples, eval cases, allowed authority, and next step. This assumes the firm owns the process and can check the result. No prompt makes an unowned or uncheckable process safe.