An agent will be wrong. Not often, if the build was done properly, but it will happen, and the interesting part is the twenty minutes afterwards. Someone in the department notices that a drafted reply used the wrong tone, or that an invoice line got filed as an exception when it should have cleared. They have two options. Open the file that holds the rule and change it, or write to whoever sold them the system and wait. Only one of those leaves the agent switched on.
So handover is not the ceremony at the end of a build. It is the part that decides whether the build survives its first mistake. Here is what goes into it, and why each piece is there.
A system nobody can change gets switched off
An automation the department cannot edit is a dependency, and departments are ruthless about dependencies that embarrass them. The mechanism is simple. A rule is wrong on a Tuesday. The person who noticed has no way to fix it, so they route around it, doing the work by hand for that case and telling a colleague to do the same. Two weeks later the agent is handling a third of what it was built for, and nobody has decided to turn it off. It just stopped mattering.
The vendor console is where this usually starts. A locked interface with a text box for instructions looks like control and is not. You can see the prompt, you cannot see its history, you cannot tell what it looked like during last month's bad run, and you cannot revert to the version that worked. You also cannot let two people change it, because there is nothing to merge and nothing to blame.
My view is that accuracy is the smaller half of trust. The larger half is correction speed. An agent that is right ninety-four percent of the time and can be fixed in an afternoon beats one that is right ninety-eight percent of the time and takes three weeks and an invoice to adjust. Handover is how you buy the afternoon.
The prompt library lives in your repository
Every instruction that drives an agent goes into plain text files in the client's own git repository. One file per agent for the rules specific to that workflow, plus a shared file for the rules every agent obeys. The files carry comments that say what each rule is for, because a rule without a reason gets deleted by the next person who finds it inconvenient.
Changes go through the same pull request flow as the rest of the client's code. That gives four things worth having. A diff, so you can see exactly what wording changed. A reviewer, so a rule change is not a private act. A revert, so a bad edit costs minutes. And a version number in the run log, so when a run looks wrong you can tell which version of the prompt produced it.
We also write the library so the edits people actually want are easy to find. The tone of a drafted reply, the threshold at which the agent escalates instead of deciding, the wording of a rejection, the list of people a certain case routes to. Those sit near the top of the file with their own comments. The plumbing sits lower down. If a department head has to read two hundred lines to change one sentence of tone, they will not change it.
Guardrails are enforced in code, not asked for in a prompt
Each agent carries a short list of things it may never do. Never send external mail without a human release. Never post to the ledger. Never delete a record. Those are not sentences in the prompt file. They are checks in the code around the agent, in the permissions on the credentials it holds, and in the tools it is allowed to call.
The reason is handover itself. The whole point of a prompt library is that people will edit it, including people who were not in the workshops and have never read the guardrail list. A constraint that lives in the prompt disappears the moment somebody rewrites the paragraph it was sitting in. A constraint that lives in code survives every edit, including the careless ones, and that is exactly what you want protecting the ledger.
Two workshops, both recorded
The first runs before go-live. It covers where the files are, how to change a rule and ship it, how to read the run log, how to put an agent back into shadow mode, and how to stop it entirely. That last one matters more than it sounds. A team that knows how to halt an agent is far more willing to let it run.
The second runs about three weeks after go-live, and it is the useful one. By then the team has hit real cases, has an opinion about the escalation threshold, and has usually found something the agent handles in a way nobody anticipated. Running that session before go-live would have produced polite nodding and no questions.
Both are recorded, and the recordings go to the client with the rest of the handover. The person who needs the answer in month seven was on holiday in month one. Without a recording, what they get is a colleague's half memory of what somebody said, and that is how a working system turns into folklore.
A named contact for ninety days
Not a support address. A person, with a name and a number, who answers for ninety days after go-live. At three clients at a time this is possible, which is a large part of why the limit exists.
Ninety days is not arbitrary. It covers one quarter end, which for most departments is when the unusual cases arrive. A system that has survived a quarter close has met most of what will ever be thrown at it.
A weekly thirty minutes while the numbers settle
One half hour a week, for the first stretch after go-live. It looks at four things. How many items landed in the human queue. Which ones the agent escalated and whether it was right to. What the team edited in the prompt library that week. And whether the volume the agent is handling matches what the map said it would.
Most of the tuning happens in the first month. Escalation thresholds set before go-live are guesses made against shadow-mode data, and shadow mode never quite matches production. Lowering a threshold should be a decision made with a week of real numbers in front of you, not a feeling that the queue looks long.
What ninety days does not mean
It does not mean indefinite support. At day ninety-one the named contact stops being on call, and if the client wants more than that it is a separate conversation with a separate price.
It does not mean nothing will break. Models get deprecated, APIs change their response shapes, and somebody in IT will eventually rotate a credential without telling anyone. What handover gives you is the ability to see what broke, because every action is logged, and the ability to fix the parts that live in the prompts yourself.
It also does not mean we keep a copy of the keys. The infrastructure definition, the prompt library, and the guardrail code all sit in the client's accounts and repositories. If the relationship ends badly, the system keeps running. A consultancy that has to stay reachable for the software to work has built itself a hostage, not a handover.
The test is narrow and easy to apply. When the agent is wrong for the first time, does someone in the department open a file, or open their mail client? Everything above exists to make it the file.