Start with a specific pain
The workflows that ship start with a named person and a named pain — 'Priya spends 4 hours a week triaging support tickets' — not with 'we should use AI for support'.
Write the problem in one sentence, name the owner, and quantify the cost. If you can't do this in ten minutes, the workflow isn't ready to prototype.
Prototype in 3 days
Day 1: manual walk-through of the workflow with a real example, no code. Prove the LLM can produce the output you want at all.
Day 2: wire the happy path in n8n, Make, or a Python script. Solve for demo, not scale.
Day 3: run it against 10 real examples and show the owner. Their feedback is the spec — everything before this is guesswork.
Build the eval before scaling
Before you invest in the second version, build a 30-case eval set from real examples. This is the safety net that lets you iterate without breaking what already works.
Every prompt change gets rerun through the eval. Every production failure adds a case. The eval set becomes the artifact — more valuable than any single prompt.
Rollout patterns that work
Shadow mode first: run the workflow in parallel with the human process, don't act on the output. Compare for two weeks.
Draft mode second: produce output but require human approval. This is where 60% of workflows should stay permanently.
Autonomous mode last, if ever. Only for workflows where the failure cost is bounded and observable.
Kill it if it doesn't work
Set a kill criterion on week one. If the workflow isn't measurably better than the baseline after 6 weeks, retire it. Zombie automations are worse than no automation.
The most senior lesson in AI workflows: it's fine — and correct — to kill things. Teams that ship 3 workflows and kill 2 outperform teams that ship 5 and maintain all of them.