Prompt management as an asset

Target audience: everyone | Prerequisites: 2.5 Your first end-to-end automated workflow

What you'll learn

After this document you will be able to:

• explain why a prompt (the instruction given to the model) is a company asset, not one employee's notes;
• create a prompt bank (a shared, organized repository) and write down six core data points for every prompt;
• number prompts into versions and record for every change what was changed, why, and who approved;
• reuse one prompt template in several uses, knowing what may be changed and what may not.

In plain terms

A good prompt is the company's experience put into writing: which lessons came the hard way, how the clients talk, which rules apply. If those sentences live in one employee's e-mails or on their laptop, the company doesn't own them — the person owns them and takes them along when leaving. A prompt bank means that all the prompts are in one agreed place where everyone can find them, and every more important change is recorded. Nothing more is needed: a shared document holds up.

Why prompts are an asset

1.6 Roles and responsibility in a project said that the prompt is a company asset. Why? Because a good prompt has knowledge written into it that exists nowhere else:

• Lessons learned. “When one day has several transactions, the summary puts every one of them on its own line, not into one record” — behind that sentence there are most likely wrong monthly summaries that someone learned from.
• The client language and the tone. How your clients are talked to — what sounds familiar, what too formal — only your company knows.
• The rules and the boundaries. What the result may contain and what not; where a human must step in.

These records were bought at a high price — with the test cycle (test, fix, test again) and work hours. And they are perishable: a prompt that sits only on the computer of the person who wrote it disappears with them — an illness or a departure is enough.

The boundary line: knowledge becomes the company's asset only when it is written down in a place that others can access too. Keeping prompts is as ordinary work as keeping reports and contracts.

Where to keep prompts: the prompt bank

In plain terms: the prompt bank is the company's recipe collection — not in every cook's head, but in the cookbook that anyone can go look at. Next to every recipe a note: who makes it, when it was last tried, whether it is in use.

The simplest variant, enough for a small company: a shared document or a folder structure that everyone has access to. In the bank, every prompt carries six core data points:

• the name — such that another person understands what this is about;
• the purpose — one sentence: what it does;
• who / where used — who uses it and in which workflow;
• last tested — a date, not a memory;
• the status — in use, in testing, or in the archive; the archive is not deleted, because an old variant is history, too;
• the version number — e.g. v3: which tested state is currently in use.

The date “last tested” is the most important: 2.1 teaches that the test cycle is what confirms quality — the date states the knowledge's age.

One sentence for the technical reader: git works, because the history of every change is kept by itself — but a non-technical team can manage with a shared document; it is not mandatory.

When the team grows, the edit rights and the review flows go into the standards — see 5.2 Team workflows and standards.

The basics of version control

In plain terms: the prompt is handled like variants of a form: v1, v2, v3. With every new number, it is recorded what was changed, why, and who approved. A new version is not made on a whim, but when testing shows that the old one no longer works.

A version (one fixed state, distinguished by a number, e.g. v1, v2) means this: a change is not written over the old one, but made with a new number. The old ones stay — if the new one fails, you can step back in one move.

Three records with every new version:

1. what was changed — exactly which sentence or rule;
2. why — not “a little better”, but a concrete reason: which test case (a fixed input for which you know what the answer must be) failed;
3. who approved — who put the new version into use. Here too, human-in-the-loop applies (a workflow where a human approves the result before it is used): a change reaches use only by a human's decision.

When to update? Only when testing shows the need — not on every whim. “I feel it could be done better” is not a reason for a change, but a test: it shows the need — the version is justified; it doesn't show — the old one stays. When there are hundreds of prompts and many users, these basics grow into standards and review flows — see 5.2, and responsibility and governance questions in 5.7 Responsibility, ethics, and governance.

Reuse and adaptation

In plain terms: the prompt template is like a form with gaps: you fill the gaps with new data every time, but you don't polish the form itself. The gaps are yours — the form is the whole team's.

One and the same prompt template (a reusable prompt in which the variable data is separated) can be used in several cases: “the monthly summary of transactions” works with every client, when the data changes. The rule has two parts.

May be changed:

• the placeholders (a placeholder — the spot in the template that is replaced at use, e.g. [CLIENT_NAME] or [AMOUNT]) and their content;
• the context — the client's data, a specific invoice, a description of the situation.

May not be changed without going through a new test cycle (see 2.1):

• the tested core — the task, the rules, and the examples on the basis of which the prompt has been tested;
• the format requirements — the output's shape, length, and structure.

The logic comes from the test cycle: what is input to the AI model is interchangeable; what steers how the model answers is part of the prompt, and changing it is a new prompt. This way you never use a prompt that nobody has tested anymore after a “small fix”.

A step-by-step example: the Number Bureau's prompt bank

The fictional Number Bureau — the same company whose roles we walked through in 1.6: the owner Anu, five accountants, and Jaak.

The starting state: 12 prompts, 4 people, no single place

The invoice automation produced 12 prompts that emerged across four people. Two are half-finished in the accountant Kaja's e-mail drafts, five on Jaak's laptop, the rest scattered across chats and notes. Kaja asks for the same prompt for the second time already; Jaak fixes one version, but Merle still uses the old one; nobody knows whether “the monthly transaction summary for the client” is the thing that was tested yesterday.

The prompt bank goes up

Jaak creates one shared document and all 12 prompts get their core data. An excerpt:

The remaining seven in the same form.

One version control case

On October 3, Kaja finds during testing that one test case doesn't work: a month in which one day has several transactions gives a wrong transaction count and total in the summary — the template merges a day's transactions into one record. Kaja, who knows what a correct monthly summary looks like, fixes the template and records the change — what, why, when. Anu, as the owner, approves:

A small case, but exactly what you expect from an asset: years later, everyone can see why the summary is made row by row and who approved it. To be clear: the variants tested in document 2.1 (A, B, C) are experiments; only an approved winner gets a version number, a v-number, in the bank.

Jaak leaves

A year later, Jaak gets an offer from another employer. 1.6 reminded: when someone leaves, the knowledge must not leave with them — now the bank shows what that means:

• all 12 prompts are in the bank — none on the laptop that goes along;
• recorded is who uses what, who approved what, and when each was last tested;
• the versions' history shows why every rule stands exactly as written — on the laptop there would only remain “ask Kaja” or guesswork.

The person leaves — not the knowledge: the new builder reads the bank and continues from there.

Summary

• The prompt is a company asset — the lessons learned, the client language, and the rules are written into it; unkept, they disappear with the person.
• The prompt bank is simple — a shared document or folder; for every prompt: the name, the purpose, the user, last tested, the status, and the version number. Git works, but is not mandatory.
• The versions keep the history — with every change: what, why (which test case failed), and who approved; update only when testing demands it.
• Reuse through the template — change the placeholders and the context, don't touch the tested core or the format requirements without a new test cycle.

What's next?

• previous → 2.5 Your first end-to-end automated workflow
• next level → 3.1 API integrations
• The test cycle → 2.1 Getting to a good prompt
• back → handbook index