Your Client Will Edit the Prompt. Plan for It.

There is a moment in every AI consulting project where the work is done, the invoice is paid, and the consultant hands over the source code and the prompt strings.

Then the client changes one word in the system prompt. To soften the tone, usually. And at 8 PM on a Tuesday the consultant gets the text: it's broken.

A consultant described exactly this in a thread I was in recently. Their conclusion stuck with me: handing over prompts alone is handing someone a car with no dashboard. The client can steer, but they have no way to know whether what they just did helped or hurt. So every change feels like sabotage, even the reasonable ones.

The fix is not to forbid editing. Your client owns the thing now. They should be able to change how it speaks without booking you for a change request. The fix is to make the handoff bigger than the prompt.

The best consultants I've seen ship a bundle with three parts.

Part one: an eval suite

A curated dataset built from real production traces, plus scorers for the behaviors that matter. Did it follow instructions? Did it keep the tone? Did it refuse what it should refuse? Pass or fail, not vibes.

This turns "I think it got worse" into a number. The client edits the prompt, reruns the suite, and sees the regression themselves. No frantic text needed, because the dashboard already answered the question.

Braintrust, LangSmith, and Promptfoo are all good homes for this. Hjarni is not. We do nothing for evals, and a knowledge base pretending to be an eval harness would be worse than nothing. Keep scoring in a tool built for scoring.

Part two: a shared source of truth

Here is the question that decides whether the handoff survives: after you leave, where does the prompt live?

If the answer is "in the codebase", the prompt is frozen. Your client will not clone a repo, edit a string constant, and open a pull request to change one sentence. So either they never touch it, and every tweak becomes a paid ticket, or they paste edits into some untracked doc and the deployed prompt drifts away from the one anyone can read.

The prompt is a document now, not a string constant. It belongs somewhere the client can actually edit. And it should not live alone. The tone guide, the retrieval config, the escalation rules, the reasoning behind each decision: everything that shapes behavior goes in the same place. One of the replies in that thread admitted the retrieval config was the thing nobody had versioned. It broke things just as silently as the prompt did.

Part three: a change trail

The line that stuck with me most came from the original poster, after someone suggested clients should be free to experiment: "I'm fine with them editing prompts, I just need the changes to leave a trail."

That is the requirement they were reaching for. Changes attributed. Who changed it, when, what changed, and a way back to any earlier version. Without the trail, the eval suite can tell you that something regressed but leaves you guessing at what caused it. With the trail, a bad score has a starting point: open the history, read the recent changes, and the edit that landed just before the drop is the first one to test.

How I'd set this up

This is the part Hjarni was built for, so here is the honest version of the pitch: we cover parts two and three, and only those.

Create a shared folder for the client project. Put the living documents in it as notes: the system prompt, the tone guide, the retrieval config, an eval playbook that links to your eval tool and explains what each score means, and a decision log.

Now the properties you actually need:

• The client edits without git. It's a note. They open it, they change the sentence, done.
• Changes leave a trail. Notes keep an attributed revision history with provenance. You can see whether you, the client, or an AI made each change, read any earlier version, and revert in one click. Reverting writes a new revision, so nothing is ever lost.
• You and the assistants read from the same place. With Hjarni's built-in MCP server, the client can ask Claude or ChatGPT "what did we decide about tone?" and get it from the actual tone guide. One honest caveat: this is the read-and-edit home for the prompt, not a config store your production app pulls from at runtime. Wiring the live app stays your job. What it does end is a quieter gap: the prompt everyone reads is the one that was actually last edited, not a stale copy. A chat-app project can't do this: it lives in one person's account, not a shared handoff.
• It holds up when the client is a company. For teams that need "who saw what" and not just "who changed what", there's an audit log on the enterprise plan.

The loop after handoff looks like this. The client edits the tone guide. They rerun the evals. If the scores hold, great, ship it. If they drop, the note's history shows the change that landed just before, and one click rolls it back. When the client changes one thing at a time and reruns, that first suspect is usually the culprit. You find out about all of this at the monthly check-in, not at 8 PM on a Tuesday.

The deliverable is the system, not the prompt

A prompt without evals is a settings file with no warning system. A prompt without a home is a string constant waiting to drift. A prompt without a trail is a mystery every time it changes.

Consultants who ship the bundle are selling something different from "I wrote some prompts for you." They are selling a system the client can change without flying blind. That is easier to price, easier to hand over, and much easier to walk away from with your evenings intact.