An AI agent client handoff checklist should answer a practical question: can the client keep this particular agent useful when the builder is unavailable? A working demo, a shared folder, and an invitation to the workspace are the beginning of that answer.

I would call the project delivered when the receiving team can run the agreed task, recognize a failure, control access and spending, and find the right person for the next decision. Each of those abilities needs evidence.

Below are the 12 things I would deliver, followed by a copyable acceptance record. This is a proposed operating method for agencies and consultants, with a fictional example throughout; it is not a report of a customer deployment or a universal contract.

Keep one row per deliverable: artifact, receiving owner, verification result, open issue, and event that requires a recheck. A document marked “sent” and a capability marked “verified” should have different statuses.

1. Start the AI agent client handoff checklist with account ownership

Deliver an account register covering the agent platform, model provider where separately used, hosting, domain, connected applications, and code repository where applicable. Name the organization that controls each account and the person who can recover it.

Separate administrative control, billing responsibility, and rights to the delivered material. An administrator invitation does not settle all three, and a managed service may intentionally leave infrastructure with the agency.

I would write the agreed arrangement beside each resource: client controlled, agency operated, or third-party subscription. Confirm transfer options with the actual vendor before selling a promise of complete portability.

For example, GitHub's repository transfer documentation lists prerequisites and notes that the original owner becomes a collaborator after transfer. Moving the repository therefore still needs an access review.

Acceptance exercise: have the incoming administrator sign in through their own account, locate the production resource, and identify the recovery route. Record what they could actually administer, without exercising destructive controls on production.

In our fictional example, an agency delivers a facilities request agent to Cedar Property Services. The operations manager owns the workflow; an IT administrator owns account recovery, and neither role silently defaults to the agency developer.

Recheck when: the administrator leaves, the workspace moves, the managed-service arrangement changes, or a recovery address becomes inaccessible.

2. Hand over the bill and the spending decision

Deliver a cost register with the payer, billing interval, renewal date, usage meter, included allowances, and approval owner for each charge. Keep platform subscriptions, model usage, connector charges, and your support fee on separate lines.

“The agent costs about this much” is too vague for acceptance. The client should understand which charges continue with no traffic, which grow with activity, and which can increase after a change.

Use an ordinary workload and a busy workload to build a clearly labeled estimate. Include retries, background tasks, document processing, and review labor where they apply; do not copy a token price into a per-completed-task promise.

For Cedar, I would ask who can approve increased usage during a maintenance emergency. The person receiving the invoice may be different from the person who can authorize that operational decision.

Acceptance exercise: the payer finds the actual billing screen and latest applicable plan terms, identifies the renewal, and explains the response to a usage alert. Record whether a configured limit actually stops execution or only sends a notification.

Do the limit test in a controlled environment or with a harmless workload. If no reliable hard stop exists in the chosen stack, document that gap and the compensating operating process before acceptance.

Our guide to agent operating costs explains why repeated steps matter. Use its cost categories here, then obtain current rates from the services the client actually uses.

3. Deliver a credential register without delivering exposed secrets

The handoff document needs credential references, purposes, owners, scopes, rotation procedures, and revocation procedures. It should not contain live passwords, recovery codes, private keys, or copied authorization headers.

OWASP's secrets guidance treats creation, rotation, revocation, and expiration as distinct lifecycle stages. I would make the client's operating instructions address the stages relevant to each connection.

Use the supported connection or credential-management process for the service. Google Cloud's service-account key guidance, for example, recommends avoiding user-managed keys when suitable authentication alternatives exist.

That recommendation is specific to its authentication context; it is not an instruction to replace every integration with a new key. Identify what the delivered system supports before planning a change.

For Cedar's ticketing connection, the register might say “approved connection, facilities queue, client IT owner,” with a restricted reference to its management location. A reader of the ordinary handoff pack should not acquire ticketing access merely by opening it.

Acceptance exercise: rehearse replacement and revocation in a test connection, verify the new connection, and verify that the retired access fails. Plan the production sequence so the change does not strand queued work.

Recheck when: a credential owner changes, a secret is exposed, the vendor changes authentication, or the connection gains new privileges.

4. Prove permissions with the receiving users

Deliver a permissions matrix showing who may use the agent, edit it, approve actions, inspect activity, and manage billing. Include the external systems the agent can read or change.

These are separate boundaries. Permission to open a portal should not be treated as permission to see every source document or write to every connected application.

OWASP's authorization guidance recommends least privilege, denial by default, and permission checks on every request. The useful handoff evidence is a set of allowed and denied cases against the implemented controls.

In Pickaxe, access groups govern end-user access, including public, member, and invite-only arrangements. I would document the selected group and test its deployed experience separately from administrative access and connector permissions.

For Cedar, a maintenance coordinator may submit a request, a supervisor may approve a vendor dispatch, and an administrator may change the integration. The agent should not infer that one role inherits the others.

Acceptance exercise: use representative test identities to verify an allowed request, an unauthorized request, and access after membership removal. Include a cross-client check if the service handles multiple clients.

Keep these exercises inside an approved test scope with synthetic records. A prompt saying “respect permissions” is not evidence that the application enforces them.

5. Transfer source ownership and the rule for updates

Deliver a source register with the document owner, authoritative location, approved version, audience, and update method. Include the instructions and templates that influence the agent, alongside its searchable knowledge.

The receiving team needs to know which person decides that a policy is correct. The agency can maintain an integration while the client's policy owner remains responsible for the approved content.

Pickaxe's Knowledge Base documentation distinguishes workspace availability from the sources actually connected to an agent. I would include both in the inventory, then verify the agent's actual retrieval behavior.

For Cedar, use an approved facilities policy and an outdated copy with a deliberately different escalation contact in a controlled test. The useful result is whether the agent uses the current rule and handles the obsolete source as intended.

Acceptance exercise: the incoming owner updates a harmless test source, verifies the resulting answer, and checks what happens when a source is removed or unavailable. Record observed timing rather than promising an unverified refresh deadline.

Also decide who owns unanswered questions. If the agent cannot find the rule for an unusual request, the handoff should identify the policy decision-maker instead of encouraging the operator to improvise one.

Recheck when: the policy changes, a source moves, its sharing permissions change, or a new audience starts using the agent.

6. Give the client a repeatable acceptance test set

Deliver the test inputs, expected behavior, grading rules, environment, configuration reference, and results. Tie the evidence to the version actually being accepted, including relevant prompts, model selection, sources, and integrations.

I would include ordinary requests, missing information, denied actions, unavailable integrations, duplicate requests, and uncertain outcomes. The exact set should follow the agreed workload; a universal count would create false precision.

Anthropic's evaluation guidance distinguishes the agent's transcript from the final state in the environment. For handoff, that means checking the resulting ticket or record rather than accepting “done” as proof.

For Cedar, a test passes when the facilities queue contains the intended request with the right fields and approval status. A polished response paired with a missing ticket is a failed delivery case.

Acceptance exercise: the receiving operator reruns the agreed cases and can locate their evidence. Record failed, inconclusive, and excluded cases separately, with an owner and next action for anything still open.

Use our agent evaluation guide for the test-set design. The handoff pack should contain the usable cases and instructions, rather than only a link to a general tutorial.

Choose which failures block acceptance before reviewing the results. Otherwise the standard can shrink to whatever the current version happens to pass.

7. Write down limitations and the human fallback

Deliver a short boundary sheet: supported tasks, unsupported tasks, uncertain cases, human approvals, and what the user should do when the agent is unavailable. Keep the language understandable to the people who will operate it.

I would distinguish a known limitation accepted within scope from an unresolved defect. “Cannot authorize emergency spending” can be intentional; “sometimes creates requests in the wrong client queue” needs a fix or a restricted deployment decision.

For Cedar, the agent might collect a maintenance report and prepare a ticket while urgent hazards go directly to the client's established emergency route. The workflow owner must approve the actual wording and escalation process.

Do not imply that the agent replaces specialist judgment or that a checklist grants regulatory approval. The boundaries should follow the particular service and the client's review requirements.

Acceptance exercise: present a request outside the agreed scope and observe the response, the external state, and the route offered to the user. Check that the agent does not quietly proceed after stating that approval is required.

Deliver the fallback where users can find it, including the deployed interface where appropriate. A warning buried in an administrator's folder does little for the person facing an unexpected answer.

Recheck when: a new capability, audience, channel, or business commitment expands what people expect from the agent.

8. Train the operator through a teach-back

Deliver role-specific operating instructions and a walkthrough of the actual system. The administrator, everyday operator, and business approver need different levels of detail.

My preferred acceptance exercise is a teach-back: the receiving person performs the work while the builder observes. Watching someone else click through a successful demo can conceal gaps in access, understanding, and documentation.

Ask the operator to run an ordinary request, locate its evidence, recognize an exception, and use the fallback. Ask the administrator to locate a supported change process and explain how that change is reviewed before release.

For Cedar, the coordinator should find a failed ticket attempt without asking the developer which screen contains it. The supervisor should distinguish a draft request from an approved vendor commitment.

Keep exercises reversible and use test records. Training should not become an excuse to alter real access, send customer messages, or dispatch a vendor merely to demonstrate a control.

Record where the operator needed help, then improve the instructions and repeat the affected task. A confused recipient is useful feedback about the delivery, rather than a reason to declare the training complete because the meeting ended.

Our client rollout guide covers the broader adoption process. Here, the deliverable is narrower: evidence that the named receiving roles can perform their operating responsibilities.

9. Deliver monitoring with an owner for each signal

Deliver the dashboard or activity location, review cadence, alert destinations, evidence-retention arrangement, and a named person responsible for responding. Explain which failures the available monitoring cannot detect.

The NIST AI RMF Playbook's Manage guidance connects post-deployment monitoring with feedback, incident response, recovery, and change management. Its suggestions are voluntary, and the resource says the framework is being updated.

I would translate that broad guidance into a small operating routine: inspect failed actions, review a sample of outputs, check usage anomalies, and follow unresolved exceptions. The cadence should match the workload and agreed support coverage.

In Pickaxe, the Users documentation describes conversation and action summaries in Activity, with conversation insights and downloads. Verify the receiving role can access the information required for its job.

For Cedar, “ticket creation failed” and “ticket created in the wrong queue” are different signals. An integration-success count can miss the second problem, so the review needs some attention to resulting business records.

Acceptance exercise: create an approved test failure and follow it from the agent's record to the receiving alert or review queue. Confirm that a person can see, interpret, and acknowledge it.

Use restricted evidence and appropriate redaction. Giving everyone complete conversation histories is not a necessary consequence of giving one operator a useful failure report.

10. Rehearse escalation, pause, and recovery

Deliver a runbook for stopping affected work, preserving relevant evidence, involving the client, and resuming under control. Include primary and backup contacts, operating hours, and an alternate route if the normal channel is unavailable.

Spell out what “pause” actually stops. Disabling a chat entry point may leave a schedule, queue, webhook, or external workflow running.

For Cedar, rehearse a ticketing timeout in a test environment. Before retrying, the operator should check whether the external ticket exists, because an uncertain response does not establish that nothing happened.

Acceptance exercise: the incoming operator follows the runbook through detection, containment, reconciliation, and a controlled restart. Keep the evidence of what stopped and what remained active.

Do not promise that restoring an old prompt reverses external actions. A sent message, changed record, or vendor dispatch needs its own reconciliation process and an authorized decision about any correction.

Our guide to long-running agents covers checkpoints and recovery patterns. The handoff should identify the controls implemented in this system, including any manual steps.

When the exercise exposes a missing control, assign a fix or narrow the accepted scope. Document the actual support arrangement instead of treating an agency's daytime inbox as round-the-clock incident coverage.

11. Separate included support from future changes

Deliver the agreed support period, channels, operating hours, response expectations, included work, exclusions, and change-request process. Assign an owner to decide whether an issue is a defect, a source update, or a new requirement.

A response expectation is different from a resolution promise. An agency may acknowledge a broken integration promptly while still depending on the client or an external provider to repair the underlying access problem.

For Cedar, distinguish correcting a ticket field that fails the accepted specification from adding another property portfolio or a new dispatch provider. Both may require work, but they are different commercial decisions.

I would attach an example request to each category so the operating team can apply the boundary. Also say what happens if the client does not provide a required policy decision or reviewer.

Acceptance exercise: walk through a source correction, a failed connector, and a new-feature request. The client should know where each goes and who authorizes additional work.

If ongoing maintenance is part of the service, define its recurring evidence and limits. Our retainer service guide provides package examples; the handoff records the particular agreement already made.

Leave a clear transition date between project delivery and ongoing operations. That avoids a successful launch becoming an indefinite, unpriced obligation through ambiguity.

12. Finish the AI agent client handoff checklist with an exit test

Deliver an exit inventory covering instructions, source material, configuration, agreed history, test cases, domain arrangements, connected accounts, and anything that must be rebuilt on another platform. State the recipient and usable format for each item.

Exportable is not the same as portable. A transcript file, prompt document, or workflow definition does not necessarily reproduce permissions, model behavior, knowledge retrieval, or billing elsewhere.

For Cedar, the receiving team might need the approved facilities policies, request schema, acceptance cases, and an inventory of external connections. Decide separately whether historical conversations should transfer, remain restricted, or be removed through an agreed process.

Acceptance exercise: open an actual permitted export, inspect its contents, and confirm that the recipient can use it for the agreed purpose. If rebuilding is necessary, identify the missing pieces and responsible party.

Then document the order of access removal, credential revocation, scheduled-work shutdown, and subscription cancellation. Check each separately; completing one does not establish that the others happened.

Reconcile queued requests and external side effects before closing the old operating path. Avoid leaving both old and new automations processing the same requests during a transition.

This is an operational acceptance record, not a finding about legal ownership or retention duties. Put unresolved rights, data-handling, or contractual questions with the people authorized to decide them before treating the exit arrangement as agreed.

Copy this handoff record into the project

Keep one versioned record for the accepted system and a row for each of the 12 deliverables. Link to restricted evidence where necessary rather than duplicating sensitive material into a widely shared pack.

The following blank template is intentionally small. Add workload-specific fields when they change a decision; remove nothing that would leave the operating responsibility unclear.

Agent and agreed workload:
Production location and configuration reference:
Business owner / technical owner / backup:
Receiving operator and acceptance decision-maker:
Accepted scope and excluded tasks:

For each deliverable, record:
Item number and artifact location:
Receiving owner:
Check performed, environment, and date:
Expected behavior / observed result / evidence:
Status: Verified | Open | Accepted limit | Recheck
Open issue, owner, next action, and review date:
Event that requires another check:

Overall decision: Accept agreed scope | Hold
Mandatory cases still unresolved:
Accepted limitations and their operating boundaries:
Support arrangement and start/end dates:
Client decision-maker, decision, and date:
Technical owner, decision, and date:
Next operating review:

How I would use it: the builder prepares the artifacts, the receiving roles perform their checks, and the decision-maker reviews the evidence against the previously agreed acceptance rules. An unavailable system produces an inconclusive result that stays open.

For Cedar, a successful ordinary ticket would not override a failed permissions case. I would hold the affected capability or scope until the mandatory failure is resolved and rechecked.

Keep accepted limitations specific enough to operate around. Name the restricted task, the human route, and the condition for reconsideration, rather than writing “AI can make mistakes” beside an otherwise unlimited promise.

Make the final meeting an operating rehearsal

The strongest handoff meeting lets the client do the work: find the system, run a representative task, inspect the resulting record, identify an exception, and explain the next action. The builder can then fix the remaining gaps while the context is still fresh.

I would leave that meeting with a bounded acceptance decision and named owners for open items. Future changes to prompts, models, sources, permissions, or operating scope should reopen the affected checks instead of inheriting an old sign-off automatically.

If you are building with Pickaxe, use the deployed agent and its actual access arrangement for that rehearsal. You can start with one focused client workflow, then make the handoff evidence part of the product you deliver.

The useful finish line is operational independence within the agreed scope. Give the client the artifacts, the ability to use them, and a clear route for the decisions that still need a person.