An agent that works on delivery day tells you nothing about whether it still works six months later. It tells you even less about who can fix it when it breaks. If your engagement with a forward-deployed team doesn't name an owner, produce a runbook, and hand you an evaluation suite you can run without the vendor on the call, you haven't finished the project. You've paused it.
This is a buyer decision, not a vendor promise. One source framed it well: an AI agent works on delivery day, but what decides whether it still works six months later is who owns it afterward, and whether that person has what they need.
Who maintains the agent after you hand it over? - DEV Community
Fixed-scope delivery vs. retainer: different incentives, not just different prices
Before you negotiate deliverables, decide what kind of relationship you're buying. A fixed-scope build-and-hand-over engagement has a clean end date and a vendor incentive to document well, because the documentation is how they prove they're done. A retainer has the opposite incentive structure: the vendor gets paid to keep showing up, which can mean less pressure to make the system maintainable by someone else. One practitioner's framing of this tradeoff is to keep fixed-scope arrangements for implementation and reserve retainers for genuine ongoing operations, not open-ended support that never quite transfers.
Why Your AI Consultant Hopes You Never Graduate - DEV Community
Neither model is wrong. A retainer makes sense if you genuinely don't plan to build internal AI capability and want someone else to own operations long-term; that's a legitimate choice, as long as it's made explicitly rather than defaulted into because handover never happened. The mistake is signing a fixed-scope SOW that implicitly assumes ongoing vendor availability, or signing a retainer because nobody pushed for a real handover plan at the start.
Prerequisites to negotiate before the engagement starts, not after it ends
Handover is a design requirement, not a wrap-up task. If you wait until the last sprint to think about who owns the system, you'll get documentation written for whoever happened to be in the room, not for the person who inherits the pager. Three things need to be settled before build work begins.
First, name an internal owner and a deputy. Not a role to be filled later, an actual person, ideally someone who sits in on build reviews during the engagement so they aren't reading the runbook cold. Second, write the deliverables into the statement of work explicitly. "Support" and "training" are not deliverables; they're placeholders that let both sides avoid the harder conversation about what gets handed over and in what format. Third, settle who holds legal rights to the code, prompts, fine-tuned weights, and orchestration logic the vendor builds. Document the agreed rights and applicable third-party license restrictions with the people responsible for the contract; possession of a repository does not by itself establish those rights.
A clearer definition of ownership separates four distinct things: legal rights to the code and configuration, possession of the data and evaluation sets, knowledge of why the system behaves as it does, and the practical ability to change it. You can have the first without the other three, and that's functionally the same as not owning anything.
What goes in the SOW: a concrete list, not a paragraph
Easyflow's knowledge-transfer checklist identifies seven deliverables beyond working code: architecture documentation, a plain-language explanation of decision logic, a failure-mode runbook, the evaluation suite, monitoring with alert thresholds, a maintenance calendar, and a named internal owner who can demonstrate competence without the vendor on the call. Use that list as a starting point, then specify the files, access, and acceptance checks your own engagement requires.
AI Development Partner Knowledge Transfer: Handover Checklist - Easyflow
Worth noting: that framing comes from a consultancy whose own commercial interest is in selling structured handover as a service. That doesn't make the checklist wrong, but read it as an industry pattern to adapt, not a neutral standard to copy verbatim. The same caveat applies to most of the sources in this space; handover checklists are frequently published by vendors who benefit from clients worrying about vendor lock-in.
Best Practicify's handover guide emphasizes operational documentation: the architecture, business rules, confidence thresholds, runbook, audit trail, disaster recovery procedures, and source code package. Its claim that one document determines survival is an argument for documentation, not evidence that documentation alone is sufficient. Test the receiving team's ability to use it.
The handover document every production AI engagement should leave behind - bestpracticify.co
What a usable runbook actually contains
A runbook that lists API endpoints and deployment commands is not a runbook, it's a reference doc for someone who already understands the system. A usable runbook is written for the on-call person, not the original developer, and it answers a narrower set of questions under pressure: what is this agent allowed to do, what must it never do, which systems can it write to, and what happens when it's wrong.
Concretely, that means the runbook should specify the escalation path when something looks off, the rollback procedure for a bad model or prompt update, and the blast radius of each action the agent can take. If the agent can send customer-facing emails, place orders, or write to a production database, the runbook needs to say so explicitly and describe how to pause that capability without taking the whole system down. None of this is exotic engineering; it's the same discipline that's existed in on-call practices for distributed systems for years, applied to a component whose behavior is probabilistic rather than deterministic.
The acceptance test for handover itself: run the drill while the vendor is still reachable
Documentation that nobody has tested is a hope, not a handover. The only reliable way to find out whether a handover package actually works is to run it while the forward-deployed team is still on the contract, not after they're gone. That means picking a date before the engagement ends, telling the vendor they're observing only, and having your named internal owner do the following without vendor input: notice that a run failed, pause new agent actions, inspect current state, and restore a known-good version using only credentials and access the client already controls.
If your internal owner can't do all four steps unassisted, the handover isn't done, regardless of what the SOW says was delivered. This drill also surfaces gaps that documentation review alone misses: access that's still scoped to the vendor's accounts, dashboards that only the vendor's monitoring tooling can read, or a rollback procedure that technically exists but takes four hours to find.
One detail that's easy to miss: rollback restores the system to a known-good state, it does not undo actions the agent already took. If the agent sent an email, placed an order, or wrote a record before the bad version was caught, rolling back the code doesn't reverse any of that. Reconciliation, figuring out what already happened and fixing it, needs to be part of the drill itself, not an afterthought discovered during a real incident. Build a reconciliation step into the fire drill: given a list of actions the agent took in the last hour, can the owner determine which ones need to be manually corrected?
Failure cases worth naming before they happen to you
- Orphaned automations: ownership gets reassigned on paper when a project ends, but understanding the system means reconstructing its purpose and dependencies from the artifact itself rather than from the person who built it, which is slow and error-prone when done under pressure.
- Evaluation sets and prompt histories that live only in the vendor's environment or on an engineer's laptop, invisible until the day you need to re-run a regression test and can't.
- SOWs that name "support" and "training" with no cadence, no defined triggers, and no clarity on who pays for ongoing monitoring once the embedded engineers roll off.
- A named owner who exists on an org chart but was never actually involved in the build, so the handover training session is their first real exposure to the system's internals.
Inheriting an AI Agent With No Owner - Kovrr
A checklist to take into the negotiation
This is a starting point to adapt to your own engagement, not a universal standard. None of these items guarantee the system will run flawlessly forever, and no runbook or eval suite eliminates every future failure mode; the goal is to shrink the gap between "something broke" and "someone who understands it can respond," not to claim the system becomes unbreakable.
- Named internal owner and deputy, identified before build starts, not after launch
- Runbook written for the on-call responder, not the original builder, covering permitted actions, prohibited actions, and escalation paths
- Client-owned evaluation suite that can be re-run without vendor involvement
- Pinned versions with a documented, tested rollback procedure
- Data source map describing what the system can and cannot see or write to
- Monitoring dashboard with defined alert thresholds and a named alert owner
- Legal clarity on who holds rights to code, prompts, configurations, and fine-tuned models
- A pre-exit handover drill completed while the vendor is still reachable, including a reconciliation step for already-executed actions
The common thread across all of this is sequencing. Every item on that list is cheap to negotiate before a contract is signed and expensive to retrofit after the embedded team has moved on to the next engagement. The buyers who get this right treat the handover package as part of the system being built, evaluated with the same rigor as the agent's accuracy or latency, rather than as paperwork to collect at the end.