A prompt is an instruction. A workflow is a controlled sequence with inputs, evidence, validation, authority, escalation and a record of what happened.
A useful AI experiment can begin with one prompt. A reliable AI workflow cannot end there.
The prompt may produce an excellent result on the example used to design it. Real work introduces missing fields, old documents, conflicting instructions, unusual cases, malicious content, and users who interpret the same output differently.
Reliability comes from the system around the model. That system needs to define when work begins, which inputs are accepted, which sources have authority, what the model may produce, how the result is checked, what the system may do, when it must stop, and what gets recorded.
If those decisions live only inside a prompt, they are difficult to inspect and easy to break.
The eight-layer stack
A production workflow needs an explicit answer at every layer.
1. Trigger
The event that starts the workflow. A form is submitted. A file enters an approved folder. A record changes status. A metric crosses a threshold.
A reliable trigger must be observable, unique enough to prevent duplicate runs, recorded, and connected to an owner. “Whenever someone needs it” is not a trigger. It is a hope.
Test it: can the same event start the workflow twice? Can it start before required information exists? Can an unauthorised person trigger it? What happens if the trigger arrives while the previous run is unfinished?
2. Input contract
What the system accepts. For each input specify required fields, permitted formats, size limits, language, date range, source, sensitivity and validation rule.
If a workflow analyses a project brief, “upload the brief” is not enough. The contract might require a project identifier, approved brief version, market, deliverable list, due date, named reviewer, and a file in PDF or structured text.
Reject or escalate incomplete inputs before asking a model to infer what is missing. This is the same discipline as briefing a designer properly: the cost of an ambiguous input is paid downstream, by someone else.
Treat external content as untrusted. Documents, websites, emails and retrieved records can contain instructions that attempt to redirect an AI system. OWASP identifies prompt injection as a primary risk, including indirect instructions hidden inside external content.
The workflow must separate data to analyse from instructions the system may follow. A supplier document should not be able to redefine the system’s authority because it contains the sentence “ignore previous instructions.”
3. Approved context
The information the system may use. Define a source hierarchy: current approved policy, current signed agreement, verified system-of-record data, reviewed internal guidance, historical examples, then general model knowledge.
The hierarchy matters when sources conflict. A retrieved answer should expose source title, version or date, relevant excerpt, and retrieval time.
Retrieval-augmented generation gives a model access to current internal knowledge without retraining it. It does not guarantee the correct passage was retrieved or that the model represented it accurately. NIST’s Generative AI Profile recommends reviewing and verifying sources and citations during testing and ongoing monitoring.
4. Transformation
Define the exact work. Not “analyse this and help.” Instead: “classify the enquiry against the approved criteria, identify missing information, cite the criterion used, and draft a response without sending it.”
Separate complex work into visible stages: extract, classify, retrieve, compare, draft, validate. This makes failures diagnosable. If the final answer is wrong, the team can see whether the system extracted the wrong date, retrieved an old policy, or applied the wrong rule.
5. Output contract
What a valid result looks like: required fields, permitted labels, maximum length, source citations, confidence expression, missing-information flag, prohibited statements, machine-readable structure.
The workflow should fail validation if required fields are absent. Do not ask a person to notice structural errors in free text every time.
6. Validation
Four checks, not one. Structural: is the output complete and correctly formatted? Evidence: does every factual conclusion connect to an approved source? Business rule: does the recommendation comply with limits, exclusions and policy? Human: does a competent person agree the result is appropriate in context?
The first three can often be partly automated. The fourth stays where judgment or consequence demands it.
7. Authority and escalation
State what the workflow may do after validation: save a draft, add a tag, create a review task, recommend an action, prepare an action for approval, or execute an approved low-risk action.
Then define stop conditions: required evidence missing, sources conflict, confidence below threshold, value above limit, sensitive category detected, user asks for an exception, repeated system failure, external tool unavailable.
An escalation must name the recipient, the information supplied, the response deadline, and the state of the unfinished workflow. “Send to a human” is not an escalation design.
8. Record
Every meaningful run leaves an audit record: workflow version, time, trigger, input identifiers, sources retrieved, model and configuration, result, validation outcome, action taken, approver, escalation, correction.
Do not store sensitive input or model reasoning merely because storage is easy. Retain what is needed for accountability, diagnosis and applicable obligations.
Worked example: inbound enquiry triage
Trigger. A complete website form receives a unique enquiry ID.
Input contract. Contact details, organisation, requested service, market, approximate timing, free-text context.
Approved context. Current service definitions, current geographic scope, minimum project criteria, conflict exclusions, contact-routing rules.
Transformation. Extract supplied facts, check required information, compare the request with criteria, cite the criteria, draft the appropriate response.
Output contract. One of three labels: ready for human review, request missing information, or outside current scope.
Validation. The workflow must be configured and tested not to use protected personal characteristics as classification criteria. It must flag budget or urgency as missing rather than infer them. Every conclusion must cite supplied facts and current criteria.
Authority. Version one saves a draft and assigns it to a person. It does not send.
Escalation. Potential conflict, unclear service fit or unusual contractual language goes to a founder.
This produces more than a faster reply. It creates evidence about which enquiries arrive, which information is usually missing, and where service definitions remain unclear.
Build an evaluation set before connecting an action
We use a 30-case split as a pilot heuristic, not as statistically sufficient evidence of production reliability: 20 normal historical cases, 5 legitimate edge cases, 5 adversarial or malformed cases. Expand it according to workflow diversity, consequence, expected failure frequency and legal requirements.
Remove unnecessary personal data before testing. Where remaining personal data is necessary, document the testing purpose, lawful basis, access controls, retention period and any required privacy review.
Measure input rejection accuracy, classification agreement, citation correctness, unsupported-claim rate, escalation recall, correction time, and total human effort.
An answer can sound excellent and still cite the wrong rule. Evaluate components, not impression.
Release authority in stages
Shadow. The workflow runs without affecting live work. Compare its results with actual decisions.
Draft. The workflow prepares output for review.
Assisted action. A person approves each action.
Bounded action. The workflow acts only in cases that have shown stable performance and low consequence.
Monitored operation. The system samples completed cases for human review, tracks drift, and retains an immediate stop control.
Do not skip from a good demo to bounded action. The stage names map directly onto the authority levels in automation, assistance and delegation.
How we build it
We do not sell a prompt as a workflow. The implementation is the eight layers: trigger, input contract, approved context, transformation, output contract, validation, authority and escalation, record.
The model may change. The operating structure should remain intelligible. In practice these workflows sit around Scale, where an unvalidated action spends money, and start from the observed process rather than the diagram.
A prompt tells a model what to produce. A workflow tells a business what happens when it does.
If you have a prompt that works and you are about to connect it to something real, tell us what it will be allowed to touch.
Sources
NIST Generative AI Profile.
NIST definition of retrieval-augmented generation.
NIST AI Risk Management Framework Core.
OWASP Top 10 for Large Language Model Applications.
CISA and NCSC, Guidelines for Secure AI System Development.
Current to 30 July 2026. This article provides an operating framework, not legal advice.
