A Reusable Prompt Kit for Agent Teams

PLANNER (kit v4)
Decompose the task into independent sub-tasks a specialist can own.
For each: the goal, the input it needs, the output it must produce.
Do NOT do the work yourself — plan only.
# rationale: planners that start working produce shallow plans;
# forcing plan-only keeps decomposition clean (added v2 after
# planner kept half-solving tasks and misleading downstream agents)

A team I know rebuilt their agent role prompts from memory at the start of every project. It seemed harmless — you know what a good planner prompt looks like, so you type one out. But every rebuild dropped a hard-won detail: the refusal clause someone added after an incident, the output format the downstream agent depended on, the one instruction that fixed a subtle failure three projects ago. Each project's prompts were a little worse than the last, and nobody noticed because the drift was gradual. That slow decay is exactly why a multi agent prompt kit matters, and this case study is about building one.

What was quietly going wrong?

Raj's team shipped multi-agent systems for different internal clients — a research pipeline here, a review workflow there. Each started fresh, and each reinvented the same roles: something that plans, something that does the work, something that checks it, something that routes. The prompts were always "good enough," so nobody flagged a problem.

The problem surfaced when a system Raj built failed in a way an earlier system had already solved. The earlier project's checker prompt had a specific instruction — verify claims against sources rather than trusting the writer's paraphrase — that the new project's checker lacked, because Raj had rebuilt it from memory and forgotten that detail. The team was re-encountering solved problems because their solutions lived in individual projects, not in a shared, reusable kit. Institutional knowledge was evaporating between projects.

The wrong fix: a folder of old prompts

Raj's first attempt was to copy the prompts from the last good project into each new one. It helped a little and created a new problem: which old project's prompts were the good ones? Different projects had different versions, some with fixes and some without, and copying meant sometimes importing an older, worse version. The team now had prompt sprawl — many divergent copies with no source of truth, and no way to know which copy carried which fix.

The deeper issue was that ad hoc copying doesn't capture why a prompt is written the way it is. A checker prompt copied without its rationale gets "cleaned up" by the next person, who removes the awkward-looking verification clause not knowing it was load-bearing. Without the reasoning attached, the fixes erode even when the prompts are reused. Copying text isn't the same as preserving knowledge.

⚠️ Common mistake: treating reusable prompts as a folder of text files to copy between projects. Without versioning, a single source of truth, and the rationale for each instruction, copied prompts drift, fork, and lose their hard-won fixes. A multi agent prompt kit is a maintained library with history and reasoning, not a directory of snapshots — the difference is whether the knowledge compounds or evaporates.

The correct approach: a maintained kit of role prompts

The rebuild treated the agent roles as a proper library — a small set of well-tested role prompts, each versioned, each carrying the rationale for its instructions, all in one place every project pulls from. The core roles turned out to be remarkably stable across projects. Here's the planner from the kit:

PLANNER (kit v4) Decompose the task into independent sub-tasks a specialist can own. For each: the goal, the input it needs, the output it must produce. Do NOT do the work yourself — plan only. # rationale: planners that start working produce shallow plans; # forcing plan-only keeps decomposition clean (added v2 after # planner kept half-solving tasks and misleading downstream agents)

What this does: it captures a stable, reusable planner role along with the reasoning behind its key constraint, so anyone who reuses or edits it understands why "plan only" is there and won't strip it out — turning a prompt into preserved knowledge rather than copyable text.

The checker prompt carried the exact fix Raj had lost, now permanently, with its rationale:

CHECKER (kit v4) Verify each claim against its cited SOURCE, not against the writer's paraphrase. Delete any claim you cannot verify and log the deletion. You do not care whether the output reads well — only that it's true. # rationale: writers launder paraphrases into "facts"; checking # against the source (not the writer's text) is the only thing that # catches it (added v1 after fabricated stats shipped)

What this does: it preserves the source-verification instruction and the incident that motivated it, so this fix can never again be lost to a from-memory rebuild — the exact failure that started this whole story.

⚡ Pro tip: attach the rationale — ideally the incident — to every non-obvious instruction in your kit. The reason a prompt is written a certain way is as valuable as the prompt itself, because it's what stops the next person from "simplifying" away a load-bearing clause. A kit with rationales compounds knowledge across projects; a kit of bare prompts slowly loses it as well-meaning edits strip out fixes nobody remembers the reason for.

Results and what changed

Once the kit existed, new projects started from tested, fix-carrying prompts instead of from memory. The class of failure Raj had hit — re-encountering a solved problem — stopped, because the solutions now lived in the kit and every project inherited them. Setup time for new systems dropped too, since the roles didn't have to be reinvented each time.

The compounding benefit was the real win. When someone improved a role prompt — added a refusal, sharpened an output format, fixed a failure — that improvement went into the kit and every future project got it automatically. Knowledge accumulated instead of evaporating. The team's tenth multi-agent system was meaningfully better than its first, specifically because the prompts had been improving continuously instead of resetting to "good enough" every project.

⚡ Pro tip: version your kit and note what changed and why in each version, like any codebase. When a role prompt improves, bump the version and record the change, so projects can adopt updates deliberately and you can trace which version carries which fix. Treating your multi agent prompt kit as versioned code rather than living text is what makes the improvements safe to propagate — you always know exactly what you're pulling in.

What belongs in the kit, and what doesn't?

A prompt kit that tries to be everything becomes useless, so the boundary matters as much as the contents. The rule that held up across Raj's later projects was simple: the kit holds what's stable across projects, and each project holds what's specific to it. A checker's core instruction — verify against the source, not the writer's paraphrase — is stable; it's true on every project and belongs in the kit. The exact list of fields that particular project's checker must validate is specific; it belongs in the project, layered on top of the kit's role prompt. Confuse the two and you either bloat the kit with project trivia or strip it down to platitudes too vague to help.

This is why the best kit entries are role skeletons plus rationale, not finished prompts. A finished prompt bakes in one project's specifics and forces the next team to unpick them. A skeleton captures the durable spine of the role — its purpose, its non-negotiable instructions, the failures it must avoid — and leaves clearly marked slots for project-specific detail. The rationale travels with the skeleton so nobody removes a load-bearing clause while filling in the slots. The team that gets this boundary right ends up with a kit that shrinks over time toward a tight set of well-understood roles, rather than one that sprawls into a junk drawer of half-relevant old prompts.

There's a maintenance cost to state honestly: a kit is a shared dependency, and shared dependencies need an owner. Without someone responsible for merging improvements and resolving conflicts, a multi agent prompt kit fragments back into per-project copies within a few cycles — exactly the drift it was meant to cure. The ownership doesn't have to be heavy; it needs to be real. One person who reviews proposed changes and keeps the version history coherent is usually enough to keep the kit a living source of truth rather than another abandoned snapshot.

⚡ Pro tip: mark each kit entry as either "skeleton" (stable spine, fill in the slots) or "reference" (a worked example to copy from, not reuse verbatim). Conflating the two is how project specifics leak into the shared spine. Labeling the intent of every entry stops contributors from editing a reference as if it were canonical, or treating a skeleton as a finished prompt.

How to apply this to your situation

Identify the roles that recur across your multi-agent projects — usually some form of planner, worker, checker, and router. Write the best version of each you can, then attach the rationale for every non-obvious instruction. Put them in one versioned place every project pulls from, and update that place, not individual copies, whenever a role improves.

Then enforce the discipline: new projects pull from the kit, improvements go back to the kit, and nobody rebuilds a role from memory. That single rule — one source of truth, improved in place — is what turns your agent prompts from something that decays each project into something that compounds.

⚠️ Common mistake: building the kit once and letting it go stale as projects diverge from it. A kit that isn't actively maintained becomes just another old snapshot, and teams drift back to copying and rebuilding. The kit only delivers its compounding value if improvements flow back into it and projects genuinely pull from it — a kit nobody updates is a kit nobody trusts, and it quietly returns you to the from-memory drift it was meant to end.

Next steps

List the agent roles your projects keep reinventing this week, write the best version of each with its rationale attached, and put them somewhere every project can pull from. That single act stops the slow decay that made Raj's tenth system almost repeat his first system's mistakes.

A multi agent prompt kit is exactly what PromptABCD is built for — a versioned, shared home for the role prompts your agent teams reuse, with the history and reasoning that keep hard-won fixes from evaporating. Save your planner, worker, checker, and router prompts there as a maintained kit, and let every future agent team start from your best work instead of rebuilding it, a little worse, from memory.