Prompt Engineering
The practice of designing the instructions given to an AI model to produce accurate, consistent, and useful outputs. In operational AI, prompt engineering determines whether a model extracts the right fields from an invoice, applies the right rules to an exception, or generates a response that matches your process requirements.
What is Prompt Engineering?
Prompt engineering is the practice of writing and refining the instructions — prompts — that guide an AI model's behaviour. The same underlying model will produce dramatically different outputs depending on how it is instructed. A well-engineered prompt produces consistent, accurate, structured outputs. A poorly written prompt produces variable, incomplete, or incorrect ones — regardless of how capable the underlying model is.
In production operational systems, prompt engineering is not a creative exercise. It is a design discipline: define the task precisely, constrain the output format, provide the right context, specify what to do when information is missing.
System Prompts vs. User Prompts
Modern AI systems use two layers of instruction:
System prompt: The persistent background instruction that defines the AI's role, rules, and constraints. It runs on every interaction. This is where you encode operational rules — always extract unit price as a number not a string, if the invoice currency differs from the PO currency flag as an exception, never infer a quantity if it is not explicitly stated. The system prompt is written by developers and operations managers once, then applied consistently.
User prompt: The specific instruction or query for a given task. In an automated workflow, this is usually generated programmatically — passing in the document content, the relevant context, and the specific question or action required for that transaction.
A reliable operational AI system has a carefully designed system prompt that encodes the business rules, and a dynamic user prompt that passes in the transaction-specific data. Together, they determine the output.
Before and After: Weak vs. Strong Prompt for Invoice Extraction
The difference between a weak and strong prompt is not subtle. It shows up directly in output quality and error rate.
Weak prompt:
Extract the invoice details.
This produces whatever the model decides to extract, in whatever format it chooses — sometimes a paragraph, sometimes a list, sometimes a JSON object. Field names vary. Missing fields are sometimes inferred. Currency symbols are sometimes included in numeric fields, breaking downstream parsing.
Strong prompt:
Extract the following fields from the invoice document provided. Return a JSON object with exactly these keys: invoice_number (string), invoice_date (ISO 8601 format), supplier_name (string), line_items (array of objects with keys: description, quantity as number, unit_price as number with no currency symbol, total_price as number). If any field is not present or cannot be determined with certainty from the document, set its value to null — do not infer or guess. Do not include any text outside the JSON object.
The second prompt produces structured, parseable output with explicit null handling, consistent numeric formatting, and no ambiguity about what should happen when data is missing. In a workflow processing 500 invoices per day, the difference in downstream error rate between these two prompts is significant.
Prompt Engineering in Operations
For operations teams adopting AI, the practical implication is this: getting the AI to work is not just about choosing the right model. The prompts that instruct that model are as important as the model itself, and they require the same rigour as any other process design. The extraction rules, tolerance thresholds, escalation conditions, and output formats you encode in your system prompts are the operational logic your AI runs on. They should be documented, version-controlled, and reviewed when process rules change — the same way you would treat any other critical process specification.