Prompt Libraries or Written Procedures: Which One to Build First

Your team wants a shared prompt library. Everyone is writing their own instructions, the results are inconsistent, and a central set of approved prompts sounds like the obvious fix.

Build the written procedure first. A prompt library is a set of instructions for a process, and if the process itself was never written down, the library becomes the only place the rule exists. That is a bad place for it, because prompts are hard to review, easy to fork and invisible to everyone who does not use that tool.

What agents expose about your process

Most teams find out how undocumented their work is on the day they try to hand a task to an agent.

You go to write the instruction and discover the rule has three exceptions nobody mentioned, two of which contradict. Or that the "standard" version of a document exists in four variants and the one people actually send is none of them. Or that the approval step everyone describes as mandatory is skipped when the client is in a hurry, and nobody can say who decides that.

None of that is caused by the agent. The agent just needed the rule stated, and the act of stating it made the gap obvious. That is genuinely useful information, and the wrong response is to paper over it by writing a very detailed prompt.

Why a prompt is a bad home for a rule

A prompt looks like documentation. It behaves differently in four ways that matter.

• It is not read by people who are not using the tool, so half the team follows a different rule.
• It gets forked. Someone copies it, changes one line for their case, and now there are two rules with no record of which is current.
• It is hard to review. A procedure written for a person can be checked by a manager. A prompt mixes the rule with instructions about tone, format and structure, and the rule gets buried.
• It is tied to a vendor. Change tools and your process knowledge is in a format you now have to migrate.

Write the rule where a person can read it. Then reference it from the prompt.

What a written procedure gives you

Three things a prompt library does not.

It gives you something to argue about. A written procedure can be wrong in a way people can see and challenge. That argument is the useful part, and it usually happens once rather than repeatedly.

It gives you a place to record exceptions. Real processes have them. A procedure can say "normally X, except when Y, in which case ask Z". A prompt that tries to encode every exception becomes long, fragile and untestable.

It gives you something to check output against. When an agent produces something odd, the question "does this match the procedure" has an answer. Without the procedure, the review is one person's opinion against another's.

When the prompt library is the right first build

There is a real case for the other order, and it is narrower than vendors suggest.

If the task genuinely has no process because nobody has done it before, writing a procedure in advance is guessing. Better to work through a few real cases, keep the prompts that produced good output, and write the procedure from what you learned. That is prototyping, and it is fine as long as it is time boxed.

The other case is formatting and tone. How a document is laid out, how formal a message should be, what a summary includes. Meeting summaries are the exception worth watching, because automated notes can change what people say in the room. These are conventions rather than rules, they change often, and they do not need to be governance documents. Keep them in the prompt library and let them evolve.

The test is whether a mistake here has a consequence outside the document. If the answer is no, prompt library. If the answer is yes, procedure first.

A practical order of work

• Pick the task you most want to hand over.
• Write the procedure as if a new colleague were doing it by hand. Note every place you had to ask someone.
• Resolve the contradictions you found. This is usually a short set of decisions, not a project.
• Now write the prompt, referring to the procedure rather than restating it.
• Keep the review step, check output against the procedure rather than against taste, and spend some time training the team to reject agent output well.

Something to raise with any vendor before you commit: ask where prompts are stored, who can edit them, whether edits are versioned and whether you can export them. A prompt library you cannot audit or take with you is a liability dressed as an asset. Terms differ by provider, so get the answer in writing.

Writing the procedure down is also the moment to be straight with people about which part of their job the agent is doing. The teams that get the most out of agents are usually not the ones with the best prompts. They are the ones who finally wrote down how the work is meant to be done.