From prompt to process: when AI stops working in the chat window
A prompt you paste in by hand three times a week is a process that has not been built yet. Getting there is less technical than organisational: it requires naming the trigger, the inputs and the stop conditions.
In short
- A prompt is ready for a process when it has worked the same way three times, its inputs can be named, and a mistake would be visible.
- Four building blocks belong to it: trigger, inputs, instruction, output destination — plus a stop condition.
- A human stays in exactly two places: at judgements, and at anything with outward effect.
- The most common mistake is a process with no emergency stop and no log — then nobody notices when it tips.
In the chat window every mistake is harmless: you read the answer and discard it. A process runs with no audience — and that is precisely what separates the two forms.
When a prompt is ready for a process
Three conditions, all at once:
- It has worked the same way three times. Not similarly — the same. Automate a prompt that had to be adjusted every time and you automate away the adjusting, not the work.
- The inputs can be named. What exactly goes in, and where does it come from? If the answer is "it depends", the process is not yet describable.
- A mistake would be visible. If a wrong result looks like a right one and nobody is looking, what is missing is the control, not the automation.
The four building blocks
1. Trigger
What starts the process? A time ("every Monday at 8"), an event ("new enquiry in the form") or an action ("file placed in a directory").
Common mistake: a trigger that fires too often. Every change to a record is usually too much; once a day is enough.
2. Inputs
Which data goes in, from which source, in what quantity? A volume limit belongs here — otherwise a list of 5,000 entries goes in eventually.
Common mistake: no upper limit. That does not show up in testing and shows up immediately in production.
3. Instruction
The prompt, now hard-wired: starting point, numbered tasks, rules, output format. With placeholders for the inputs.
Common mistake: no ban on invention. In the chat window an invented figure gets noticed; in a process it does not.
4. Output destination
Where does the result go? A draft, a note, a file, a message to a person. Preferably somewhere a human looks anyway.
Common mistake: straight outward. Sending, publishing or changing records with no intermediate step.
One process in detail
As an example, the weekly review of incoming enquiries — a process that makes sense in almost any company.
| Building block | Setting |
|---|---|
| Trigger | Monday, 7 am |
| Inputs | enquiries of the last 7 days, at most 100, fields: date, source, request, status |
| Instruction | group by request, name the three most common, note anomalies against last week, invent no figures |
| Output destination | email to management, at most 200 words |
| Stop condition | fewer than 3 enquiries: do not send |
| Log | time, number of inputs, success or error |
Worth knowing
The stop condition is the building block most often missing — and the one that prevents the most trouble. Without it the process runs even when there is nothing there, and produces a report about nothing.
The damage is not the one pointless report. It is that a weekly report often containing nothing stops being read after two months — including on the occasion when it does contain something important. A process that only reports when there is something to report stays useful for years.
Where the human stays
Two places, and they are not negotiable:
At judgements. Whether a contact is seriously interested, whether a text hits the right tone, whether an anomaly is a problem or a coincidence — such judgements rest on connections that are not in the data.
At anything with outward effect. Sending, publishing, deleting, paying. Not because a model would be incapable, but because a mistake there cannot be retrieved.
A recurring pattern: the process runs well for three months, then a small thing changes in the data source — a field is renamed, a view is rebuilt. The process keeps running and produces results that are wrong but look right.
Only one thing helps against that: a plausibility check inside the process itself. "If fewer than three fields are populated, stop and report." Five minutes when building, and the difference between a process that halts on a problem and one that writes wrong reports for months.
What goes wrong
- No emergency stop. Every process needs a place where it can be halted immediately — known before you need it.
- No log. Without a record it cannot be reconstructed what happened when, with which data.
- Nobody responsible. Processes age quietly. Without a quarterly review, a process does more harm than good after a year.
- Injected instructions. If the process reads text from foreign sources — emails, forms, documents — a request can sit in there that reads like a command. The effective defence is mainly a narrow permission.
I want to turn a recurring prompt into a fixed process. Check the plan and write the process out. The prompt I currently use by hand: [paste prompt] Starting point: - How often I do this: [frequency] - Where the inputs come from: [source] - What happens to the result: [description] - Have I had to adjust the prompt each time? [yes / no] - Does data from foreign sources flow in (emails, forms)? [yes / no] Tasks: 1. Check the three readiness conditions: worked the same way three times, inputs nameable, mistake visible. Say clearly if one is not met – then the process is not ready. 2. Write out the four building blocks: trigger, inputs (with a volume limit), instruction with placeholders, output destination. 3. Phrase a stop condition and a plausibility check that prevents wrong results from looking right. 4. Name the places where a human has to decide. 5. Name what has to be logged and how the process gets halted. If the plan is not sound in this form, say so clearly and name the smaller version.
In closing
The step from prompt to process is not a technical hurdle but a question of describability. Anyone who can write down trigger, inputs, instruction and destination has the hard part behind them.
What makes the difference afterwards are the unspectacular parts: stop condition, plausibility check, log, emergency stop. Together they cost twenty minutes and decide whether a process is still useful after a year or quietly doing damage.
Common questions
How do you automate workflows with AI?
By turning a proven prompt into four building blocks: a trigger (time or event), inputs (with source and volume limit), the instruction with placeholders, and an output destination — preferably somewhere a human looks anyway. A stop condition, a plausibility check and a log belong with them.
When is a prompt ready for a process?
When three conditions hold at once: it has worked exactly the same way at least three times, its inputs can be named, and a wrong result would be visible. Doing a task often is not enough — frequent tasks that run differently every time are the worst candidates.
What has to be in every process?
A stop condition so the process does not run when there is nothing there; a plausibility check that halts when the inputs look unexpected; a log with time, volume and result; and a known way to halt it immediately.
Where does a human have to stay?
In two places: at judgements resting on connections not present in the data — whether a contact is seriously interested, for instance — and at anything with outward effect: sending, publishing, deleting, paying. A mistake there cannot be retrieved.
Why does a process produce wrong results after months?
Usually because the data source changed unnoticed — a field renamed, a view rebuilt. The process keeps running and produces results that are wrong but look right. A plausibility check inside the process and a fixed quarterly review are what help.
Marketing that sets itself up
The Studio Engine beta is live. Claim your spot and help shape it from the start.
Join the beta →