The company trained prompting and did not build a system

Meta description: Prompt libraries fail when prompts carry no business identity, purpose, or evidence — and every conversation begins from zero.

The training program was a success by its measures. Hundreds of employees through the curriculum, prompt libraries published, a champions network launched. A quarter later, I look at how the work actually runs: the official library has not been updated since launch, three teams maintain private variants of the “standard” prompt, and the prompt governing a customer-facing decision exists in a version nobody will vouch for. The company invested in a skill and needed an architecture. The two are not the same thing, and the difference shows up exactly where it hurts.

Many people think of prompt engineering as finding the right sentence. I see it as a discipline of precision. An LLM can respond to an astonishing range of instructions. Its response quality depends on how well the user supplies the relevant context.

What does prompt training actually transfer?

Training transfers craft: how to structure a request, how to iterate, how to get a better first draft. This is genuinely useful, and it is individual. It lives in the person who was trained and leaves when they do. What training does not transfer is the shared thing: which prompt the organization stands behind for which decision, who may change it, what it must never do. I have watched companies train hundreds of people to write prompts and have nobody able to say which prompt is load-bearing. Craft scales with headcount. Architecture does not, and nothing was built.

Why do libraries drift within a quarter?

The architecture I mean is a set of questions asked before the prompt is written: Who am I or what is the organization? What am I trying to achieve? Why does that result matter? What evidence or material should the system consider? What output would count as useful?

This structure has much in common with a business plan. It does not guarantee a brilliant response. It does reduce the chance that the model will produce something fluent but irrelevant. A person who cannot explain what they want is unlikely to receive a reliable answer simply by adding more adjectives to a prompt.

The drift mechanics are mundane. The workflow changes — a new field, a new policy, a new edge case — and the person closest to the work patches their local copy of the prompt, because patching the shared one requires a process nobody wants to invoke. The patch is sensible. Three months later the official library describes a workflow that no longer exists, and the real prompts live in personal documents. The library did not decay from neglect. It decayed because changing it was made harder than routing around it, and routing around it was free.

What decision has no owner inside the prompt?

This is the part I watch most closely. Somewhere in the prompt stack, an instruction shapes a consequential decision: how to phrase the answer to the customer, which policy to apply, what to refuse. In the companies I visit, I ask who owns that instruction — who decided it, who may amend it, who answers when it causes harm. The answers are gestures: the team that wrote it has reorganized, the vendor supplied the template, legal reviewed something once. The operating sentence of a consequential decision, owned by no one. Everyone learned to prompt. Nobody owns this.

What pattern marks the absence of architecture?

The markers are consistent. Prompts are treated as content — documents to be written — rather than as controls — instruments to be governed. Version history is informal. There is no test for whether a change improved anything; there is a vibe. Failure reviews, when they happen, examine the output, not the instruction that produced it. I have learned that a company without prompt architecture cannot answer a simple question after an incident: what did we instruct the system to do? The answer is scattered across personal files, and nobody can reconstruct it.

I sometimes compare a well-constructed prompt to a simplified neural network. The words that trigger the best results today may become outdated as models evolve. A rigid library of stock prompts decays because the library stores the wording and discards the context that made the wording work. The durable asset is the discipline behind the prompt: the identity, the intent, the reasons, the evidence, and the expected output. That discipline transfers across model generations; the incantation does not.

[AWAITING MIKLOS — scene: second scene]

What question is prior to prompt craft?

Prompt craft asks how to write the instruction well. The prior question asks what the instruction is for — what decision it governs, in whose name, with what accountability. Companies that skip to craft produce skilled individuals and unowned systems, which is the precise condition I keep finding. The prior question is organizational, not technical, and in most of these companies it has never been asked of a prompt at all.

The question a prompt library cannot answer for its users: can each person explain — in their own words — who they are, what they want, and why, before they open the library at all?

PR excerpt (80–120 words, Miklos’s own words): Many people think of prompt engineering as finding the right sentence. I see it as a discipline of precision. The quality of a response depends on how well the user supplies context: Who am I or what is the organization? What am I trying to achieve? Why does that result matter? What evidence should the system consider? What output would count as useful? A person who cannot explain what they want is unlikely to receive a reliable answer simply by adding more adjectives to a prompt.

Miklos Roth — founder of CRS AI Marketing & SEO Agency

By Miklos Roth — AI marketing consultant, Budapest. More: Miklos Roth — AI marketing consultant.