Prompt engineering
Prompt engineering is the practice of designing and testing the instructions given to a language model so its response fits a specific task. It includes defining the task, supplying useful examples, specifying the output and checking the result. A clearer prompt can reduce ambiguity, but it cannot make missing evidence appear or establish that an answer is correct.
By Ai Flowi · Published
The useful starting question is practical: what should the model do with this input, and how will you judge its answer? That makes prompt engineering different from collecting impressive sounding phrases. This page uses an invented service-request task to show the decisions involved; no model response or improvement measurement is claimed.
What belongs in a prompt
A task instruction names the operation: extract a requested room and identify any missing booking detail. Context supplies the material the operation applies to. Constraints say what must remain unknown rather than guessed. An output contract describes how another person or program will read the result. Examples demonstrate the boundary between acceptable interpretation and invention.
These parts should agree. Asking for a short summary and also demanding every source detail creates competing expectations. Asking the model to use only supplied facts while requiring a complete booking date encourages it to fill an information gap. Resolve those conflicts before adjusting tone or adding a role description.
For the separate question of which documents and earlier messages to include, see context engineering. A carefully written instruction can still fail when the surrounding evidence is irrelevant, outdated or too large for the chosen model.
Prompt engineering examples: improve a fixed task
The synthetic input is: “Please arrange Cedar room on Friday afternoon.” Assume the application needs a room name, a calendar date and a time. “Friday afternoon” does not supply an unambiguous date or clock time. The prompt should preserve the known room while exposing those missing details.
example configuration, not a recorded test. The revisions below specify an extraction task and do not execute a booking.
| Revision | Instruction | Reason for the change |
|---|---|---|
| Vague task | Make a booking from this message. | Does not distinguish extraction from an external booking action. |
| Bounded task | Extract the room and list missing date or time details. Do not book anything. | Separates interpretation from execution. |
| Output contract | Return room, date, time and clarification_needed. Use null for absent date and time. | Makes missing information visible to a later check. |
| Example boundary | A weekday without a calendar date remains unresolved. | Shows how the ambiguous phrase should be treated. |
An authored target would retain Cedar, leave the date and time unresolved, and request clarification. That is an acceptance target, not a recorded output. Whether a chosen model follows it must be checked using the actual model configuration and input.
Make instructions concrete without overloading them
Use verbs that describe observable work: extract, classify, compare or quote. “Be helpful” does not tell you whether a guessed booking date is a defect. “Use null when the date is absent” does. Keep data clearly separated from instructions so a sentence inside the request is treated as material to interpret.
An instruction to ignore commands inside quoted data is useful design intent, but prompt wording alone is not an access-control boundary. A model-facing request should not carry permission to commit a booking. The application must check required fields and require the appropriate authorization before any action.
Examples help when the difficult part is a judgment boundary, such as distinguishing a preference from a confirmed detail. The few shot prompting entry explains how to choose examples and keep evaluation cases outside the prompt. More examples are not automatically more useful.
How this appears in AI Flowi Workflow
Use the Prompt Template reference for assembling the instruction text.
The Structured Output explanation owns the field and schema contracts for a machine-readable response.
For this booking request, room must preserve Cedar, while date and time remain null until the user supplies precise values. The proposed clarification_needed field should identify both missing details. Reject a response that invents a calendar date from Friday without a stated reference date, even if the resulting date is syntactically valid.
An afternoon preference and a confirmed time are different values. Preserve the preference in the explanation if it matters, but do not silently turn it into a clock time. Likewise, a request for Cedar does not establish that Cedar is available. Room extraction succeeds when it reports the requested room, not when it promises a reservation.
For evaluator setup and failure categories, see LLM hallucination.
The evaluation question here is whether a revision preserves known fields while exposing ambiguity. Compare the exact room value, the null decisions and the clarification wording independently. A prompt that asks the right follow-up but loses the room name has regressed. A prompt that returns every key but guesses a time fails a different requirement; neither result should be hidden by an overall impression of helpfulness.
documented in the catalogue; not production-tested by Ai Flowi
The component catalogue lists these tools; to compare booking prompts, supply your own generation and evaluation accounts with their API keys and budget for each provider’s separate charges.
How do I test a prompt against its task?
Freeze the source request and acceptance rules while comparing prompt revisions. If you change the model, source facts and prompt together, a different answer cannot be attributed to the instruction change. Record the prompt version and settings alongside each inspected response.
Include cases with a complete date, a relative weekday, a missing room and a request that tries to issue a command through its text. Score the properties separately: supported fields, missing-information handling, output structure and unauthorized-action avoidance. A response can satisfy the format while failing the evidence check.
Use the Agent reference only when the design actually needs tools. For task-specific starting patterns, review documented use cases and their stated test scope. Prompt testing does not establish that a connected tool or complete workflow works.
Common mistakes and limits
Do not treat a fluent answer as a passed check, reveal private examples in a shared prompt, or copy the evaluation answers into the prompt itself. Do not use model interpretation where a deterministic rule already specifies the answer. Prompt engineering is useful for language-dependent tasks, but evidence, validation and application permissions remain separate responsibilities.
Related: Automatic prompt engineering: generate and evaluate candidates.