A prompt is one component of a workflow, not the whole system

The workflow owns the result that a prompt only influences

A prompt supplies instructions and context to a model invocation. The delivered result also depends on model and version, system instructions, sampling and reasoning settings, retrieved documents, tool definitions, permissions, conversation state, parsing, retries, post-processing, and human decisions. Calling the prompt the system hides these dependencies and makes failures hard to reproduce. The workflow contract records the reader or business task, allowed inputs, prohibited data, expected output schema, evidence standard, tool authority, reviewer, and terminal state. OpenAI and Anthropic publish vendor-specific prompting practices, while NIST provides broader risk-management outcomes. None makes a text instruction a guarantee of truth or safe action.

Evidence: OpenAI; Anthropic

Success criteria come before wording experiments

Define representative cases, required fields, factual or source constraints, acceptable abstention, style boundaries, latency and cost envelope, privacy conditions, accessibility, and failure consequences. Include ordinary, ambiguous, adversarial, missing-data, and high-risk examples. Decide which properties can be checked automatically and which need qualified human judgment. Anthropic's overview explicitly starts prompt work with clear success criteria and empirical tests; this principle transfers without assuming identical syntax across providers. A prompt that produces one impressive demo but fails the task set is not optimized. The evaluation set should remain stable enough to compare changes while evolving when real failures expose missing cases.

Evidence: Anthropic; National Institute of Standards and Technology

Inputs need provenance and trust boundaries

Separate trusted policy instructions, user requests, retrieved content, tool outputs, prior model text, and untrusted external text. Label source, date, permissions, sensitivity, and allowed influence. Retrieved web pages can contain instructions aimed at the model; tool output can be malformed; a user may omit required context. Do not paste secrets or personal data merely to make the prompt comprehensive. Apply data minimization and access control before invocation. The prompt should state how to handle missing or conflicting evidence and when to ask, abstain, or escalate. Delimiters improve readability but do not create a security boundary by themselves. Real enforcement belongs in permissions, validation, and orchestration code.

Evidence: National Institute of Standards and Technology; Vanderbilt University researchers

Outputs become interfaces when another step consumes them

If a person reads prose, specify audience, decision, evidence, uncertainty, and prohibited claims. If software consumes output, use a structured schema, enumerated actions, field constraints, and validation; never execute free-form text as code or a command. Give the model only tools and parameters needed for the task, then validate arguments and results outside the model. State what a no-answer or review-required response looks like. Examples can clarify difficult distinctions but should not imply facts about the current case. Version the prompt, schema, tool contract, model, and evaluator together so a later change does not silently break a downstream consumer.

Evidence: OpenAI; Vanderbilt University researchers

Authority and recovery must exist outside persuasion

A sentence telling the model to be careful is weaker than a read-only credential, spending cap, iteration limit, approval gate, idempotency key, sandbox, or kill switch. Classify actions as read, draft, reversible write, external communication, financial, destructive, or privileged. Require human approval and stronger controls as consequence rises. Preserve traces that show inputs, tools, outputs, decisions, and failures without logging sensitive content unnecessarily. Define timeout, retry count, duplicate prevention, rollback, and escalation. NIST's human-AI and third-party risk framing supports explicit roles; the workflow contract makes those roles executable rather than aspirational.

Evidence: OpenAI; National Institute of Standards and Technology

Improve the smallest component that explains a failed case

The next action is to choose one recurring AI task and document its contract from input through terminal state, then run five representative cases before editing prompt language. When a case fails, classify the cause as task definition, context, instruction, model capability, retrieval, tool, schema, permission, evaluator, or human handoff. Change one relevant component and rerun the same set. Limits remain: model behavior can change, tests never cover every context, vendor advice is provider-specific, and prompt patterns are not security controls. A mature workflow is reproducible, bounded, observable, and stoppable even when the generated answer is wrong.