Where Should Your Agency's Prompt Library Live?

These are different documents, even though agencies often merge them into one messy page. A prompt library is reference material, here's a structure that works for extraction tasks. A decision log is historical, here's why we stopped using function calling for this client's workflow and switched to structured output. Notion's databases handle the library well, since you can tag prompts by task type, model, and last-tested date, and filter by any of them.

Slite is the stronger fit for the decision log, because a decision that mattered six months ago, before the underlying model changed, needs to be either reconfirmed or retired, not left sitting as if it's still current advice.

A prompt structure that was necessary to control a model's output can become unnecessary, or actively counterproductive, after a model update. This is the single biggest documentation hazard specific to this industry: unlike most operational knowledge, technical AI advice has a shelf life measured in months, not years.

Slite's mandatory recheck cadence is a genuine fit here, arguably a better one than for almost any other industry in this comparison, because it forces someone to reconfirm a prompt pattern is still needed rather than letting it fossilize. Notion has no equivalent unless you build one, and building one requires the discipline that a fast-moving agency rarely has spare time for.

Every client's agent workflow has some shared foundation, your standard retrieval pattern, your standard error handling, and some genuinely custom logic layered on top. Notion's relational databases let you link a client's workflow doc back to the shared component library it's built on, so an update to the shared pattern is visible everywhere it's used instead of copy-pasted into a dozen client pages that drift apart.

Slite's flatter structure makes that kind of reuse harder to model, which is the clearest case where Notion's extra complexity earns its keep for this specific industry.

R&D-equivalent spend, the engineering and prompt-development work that is this industry's core product, runs at a median 22% of ARR for B2B SaaS-style businesses¹, and an agency repeating a debugging cycle that was already solved and documented, then forgotten, is burning exactly that budget line. CAC payback sits at a 16-month median across the sector², which leaves an agency little slack to also be relearning solved problems on every new client build.

An operations lead coordinating delivery across client builds, at a median salary of $105,770³, is usually the one who notices the pattern of repeated mistakes before anyone formalizes a fix.

The agencies that document well tend to separate three layers: a reusable component and prompt library, a client-specific implementation layer that references it, and a decision log that captures why something was built a certain way and when it was last confirmed still true. Reviewing that decision log every time a core model updates, not just on a calendar, keeps it from becoming a museum of outdated workarounds.

For a broader look at where a heavier wiki like Confluence fits by comparison, see the three-way breakdown.

A documentation structure built for a fast changing stack includes these parts:

• A reusable component and prompt library, kept as reference material separate from any single client build.
• A client specific implementation layer that references the library, so an update flows through to every client build.
• A decision log capturing why something was built a certain way and when it was last confirmed still true.
• A model version and last tested date on each prompt, with workaround entries retested soon after a major model release.
• Write ups of failures, such as a prompt that failed silently in production, not only the demos that worked.

Agencies are naturally biased toward writing up what worked. A prompt structure that nailed a client's extraction task on the first try gets screenshotted, shared in a Slack channel, and eventually copied into a template library. A prompt structure that failed silently in production, returning a confident but wrong answer instead of erroring out clearly, rarely gets the same treatment, because nobody wants to write up their own mistake and it's genuinely less fun to document.

That imbalance is backward for what actually protects the next client build. A documented failure, here's a prompt pattern that looked fine in testing but hallucinated under a specific edge case, here's the guardrail we added, is worth more to a new hire than another success story, because it's the failure pattern that's most likely to recur on the next client's workflow. Success stories tend to be somewhat client-specific and don't transfer directly. Failure patterns, model X tends to invent plausible-sounding numbers when the source document is ambiguous, transfer almost exactly.

Building a habit of writing a short postmortem for every production failure, not just the client-facing ones, and tagging it by failure type rather than by client, turns an agency's hardest-won lessons into something searchable instead of something that lives only in the memory of whoever debugged it at 11pm.