Our earliest prototype worked the way most people assume an AI workflow builder should: describe the automation, the model writes the workflow. It worked well enough on the demo prompt and badly enough on almost every real one to tell us the approach itself, not the prompt wording, was the problem.
Two nearly identical requests would resolve to two completely different workflows depending on which keyword happened to be present. "Send a WhatsApp message when a new lead comes in" and "send a message when a new lead comes in" — a difference of one named app — produced results that didn't just differ in that one detail, they picked entirely different underlying templates. No amount of rewriting the system prompt made this go away, because the instability wasn't a wording problem. It was a retrieval problem: the model was reasoning over whatever templates a keyword-similarity search happened to surface, and small wording changes moved which templates that was.
The real fix wasn't a better prompt — it was treating this as two separate problems. First, retrieval needed to distinguish an explicitly named requirement (a specific app the user stated) from vocabulary that just happened to score similarly, so a stated constraint couldn't be silently dropped. Second, generation needed a validation pass afterward that could catch a mismatch before it reached the user, rather than trusting the first result. That split — better retrieval, then independent validation — is the architecture that eventually held up under real, messy, inconsistently-worded requests. Prompting alone never would have.
This was the moment "prompt engineering" stopped being our primary reliability strategy. Every reliability improvement since — schema grounding, deterministic validation, retrieval benchmarking — follows from the same conclusion reached here first: you can't prompt your way to consistency in a system whose failure modes live in retrieval and validation, not in the wording of the instruction.
