What should you own after an AI implementation?

If firing the person who built your AI system breaks the system, the handoff isn't finished.

The demo works. The files are organized. Then someone on your team tries to run next Tuesday's work and discovers that the useful instructions were mostly inside the builder's head.

You own the repository. Congratulations. The repository needs to call Dave.

This is an expensive way to buy independence. And it happens easily when “you'll own everything” stays a reassuring sentence in a proposal instead of becoming something the receiving team can demonstrate.

The handoff should be part of the purchase from the beginning. Here's what I'd want to see before calling it done.

A folder is a small part of ownership

“Own the system” can mean source files, an administrator account, reusable instructions, or access to a service someone else operates. Those are different purchases. The contract needs to establish the rights; the handoff needs to show what those rights let you do.

The practical questions are straightforward:

• Can your team inspect how the work happens?
• Can it change the things it is supposed to maintain?
• Can it control the accounts and recover access?
• Could another qualified person take over?

That last question exposes a lot. A system can have excellent documentation and still depend on a personal account, an undocumented judgment call, or a connection nobody knows how to replace.

Our impressive-folder diagnostic asks whether the operating layer survives a new person using it. At purchase time, turn that into a deliverable list.

What you receive	What makes it useful
Company knowledge	Sources, owners, and a way to resolve conflicting facts
Workflow logic and instructions	Clear inputs, outputs, permissions, and completion conditions
Account inventory	Access, billing, credential locations, and recovery owners
Evaluation examples	Representative inputs, expected behavior, and known failures
Operating guide	How to start, inspect, pause, recover, and escalate
Recovery package	The version, data, and configuration needed to restore the agreed work

Keep the knowledge readable. Someone should be able to understand why an approved product record outranks an old pricing deck without reverse-engineering a visual workflow.

That is part of context strategy. Information needs a job and an authority level. “We uploaded all your stuff” doesn't establish either.

Readable pieces are also easier to replace. You might change the model while keeping the approved facts and evaluation examples. You might rebuild a connector without rewriting the voice guide.

Ask which pieces transfer cleanly, which need conversion, and which need rebuilding. “Portable” becomes useful when it describes those differences.

The accounts are where the fine print gets a login screen

Have the intended owner sign in with their own identity. Open the settings. Follow the chain from the repository through hosting, model accounts, workflow software, databases, and the publishing destination.

A company-owned repository can still run on a contractor's personal model account. That may be an arrangement you've deliberately chosen. It shouldn't be a surprise you discover when their card expires.

GitHub provides a good example of why a transfer isn't the end of the inspection. Its repository-transfer documentation explains that collaborators, secrets, and deploy keys can remain associated with a transferred repository.

Receiving the files doesn't settle who should retain access. Review the connections and decide what stays, what moves, and what gets replaced.

Billing needs its own check. GitHub's organization handoff instructions separate changing owners from updating payment information. Apply the same curiosity to the rest of the stack:

• Who gets charged?
• Who can see usage?
• Who receives service and billing alerts?
• Who can recover access or rotate credentials?

Record credential locations and responsibilities. Don't turn the inventory into a spreadsheet of passwords.

Backups deserve equally literal questions. GitHub's backup options have different coverage and restoration limits. A copy of the source files doesn't prove that application data or external configuration can be restored.

Ask the builder to demonstrate recovery for the work you're buying. A draft-producing workflow and a workflow that changes customer records have different recovery problems. “It's in Git” is an answer to only some of them.

Let the receiving person drive

Watching the builder run a workflow tells you the builder can run it. For a handoff, the interesting person is the one who didn't build it.

Put that person at the controls. The builder can watch and help. Every instruction supplied from memory is a gap to close before the session ends.

Use next Tuesday's work

Consider a transcript-to-brief workflow. This is an illustrative acceptance exercise: an approved interview goes in; a draft marketing brief, source references, and unresolved questions come out. The workflow cannot publish.

The receiving editor understands the product but didn't build the automation. Give them an ordinary input and an awkward one, including an obsolete product name or an unsupported claim.

Agree on what a usable brief means before running it. It should preserve the interview's meaning, distinguish a participant's opinion from an approved product claim, and flag missing support.

Our approach to agent workflows starts with that end state. A completed sequence of steps can still produce work nobody should use.

Hold some examples back from development. Otherwise the acceptance session becomes another performance of the builder's favorite demo, complete with the part where everyone already knows what happens next.

Then open the actual result. Anthropic's evaluation guidance distinguishes an agent's account of its work from the state it produced. Check the saved brief, its sources, and its destination.

“Successfully completed” is very easy text to generate.

Try the boring failure

The dramatic failure gets attention. The connection timeout is probably more useful to rehearse.

Did the brief fail to save, or did it save before the response disappeared? Can the operator tell? What happens if they hit retry?

AWS explains the duplicate-effects problem in its guidance on safe retries. The builder should demonstrate the workflow's actual prevention or reconciliation behavior. Optimism is a poor duplicate-detection strategy.

The receiving person should also be able to:

• Correct an allowed source issue and rerun the affected work.
• Pause new runs and see what happens to work already underway.
• Restore the test environment to a known version.
• Escalate a problem outside their authority or expertise.

Be specific about recovery. Restoring yesterday's instructions won't remove a duplicate draft already written into another service. Microsoft's compensating-transaction guidance explains why undoing distributed work can require separate, application-specific actions.

The operator doesn't need to memorize the engineering. They need a procedure that tells them what happened and what they can safely do next.

Keep the evidence small enough to use

Save the tested version, inputs, expected behavior, actual outputs, open gaps, and receiving operator's decision. Include the pause and recovery results, not just the nicest brief.

Separate mechanical checks from editorial judgment. Required fields and duplicate prevention are different questions from whether the brief is useful. Both belong in content QA.

If the exercise reveals missing instructions, fix them and rerun the affected part. The acceptance record should show what the team can operate, including where it needs help.

You can own it and still pay someone to maintain it

Ownership doesn't require becoming a full-time platform engineer. It requires enough control and understanding to choose who does the work.

Name an operating owner and a backup. Decide who handles content questions, broken connections, access recovery, and workflow changes. One person may wear several hats. The hats still need names.

GitHub recommends at least two organization owners to reduce the risk of losing access when one becomes unavailable. That doesn't mean every operator needs administrator permissions.

Test the backup person's access while the primary owner is around. A name in a runbook is encouraging. A person who can find the current version and the review queue is better.

Connect ownership to the change process, too. CODEOWNERS can request reviews from designated people; required approval depends on the relevant protection settings. Writing down responsibility and enforcing it are separate jobs.

Then have the support conversation using actual examples:

Situation	Conversation to have
The agreed source references start disappearing	Investigate a possible defect against accepted behavior
A connection needs rotating or a product name changes	Establish the maintenance arrangement
Marketing wants the workflow to send customer emails	Scope the new output, destination, and consequences

The agreement determines coverage and cost. “Message me if anything breaks” leaves too much of that conversation until something breaks.

Good agent governance should let ordinary work move. An operator may already have authority to correct a source and regenerate a draft. Adding a publishing destination is a different decision.

After handoff, watch accepted outputs, exceptions, review time, and service spend. If the same source ambiguity keeps coming back, fix the source. If the review queue keeps growing, more generation may be the last thing you need.

When you scope a workflow with Deadwater, ask who will run the acceptance exercise and what happens when we're unavailable. Ask what another qualified partner would need to take over.

Those are fair questions for us, too. If the answer still requires the original narrator, we have more handoff work to do.