Client AI agent launch checklist

Use this worksheet when an agency or independent builder prepares an AI agent for a client. Complete it for one workload at a time. It works as a document or spreadsheet; it does not assume the hosting platform supplies every control listed here.

Start with the client's expected result. A successful deployment is evidence that something started. The acceptance record below establishes whether the intended task works, reaches the right person and stays within its agreed permissions.

The checklist and decision rule are a proposed operating method. Tailor them to the actual workload and agreement. Store references to credentials, never secret values.

1. Name the workload and its owners

• ☐ A named person can approve changes to the task and its permissions.
• ☐ A named person receives and acts on operating failures.
• ☐ The client knows how to use the human fallback.

2. Define exactly what the agent may do

• ☐ Required approvals are reflected in connected-service controls where available.
• ☐ A prompt change alone cannot silently expand the agreed authority.
• ☐ The output is useful enough for the client to evaluate without reading runtime logs.

3. Record the actual deployment boundary

• ☐ The team has identified which component provides the workload's actual security boundary.
• ☐ Separate names, profiles or folders have not been treated as proof of access isolation.
• ☐ Authorized and unauthorized access cases appear in the acceptance matrix.
• ☐ The access arrangement is appropriate for the client and any other workloads sharing infrastructure or administration.

For cloudrun, the isolation guide distinguishes the engine boundary from Hermes profiles and explains the limits of the dated evidence.

4. Assign account and credential ownership

• ☐ Connected-account ownership matches the client agreement.
• ☐ Only required permissions are enabled where the service supports them.
• ☐ Renewal and authorization failures have an owner.
• ☐ Revocation is documented in the external service as well as the hosting configuration.
• ☐ The worksheet contains no API keys, tokens, passwords or recovery codes.

The BYOK guide explains the difference between removing a key from configuration and revoking it at the provider.

5. Record cost and stop decisions

• ☐ The client has an understandable estimate of the complete workload cost.
• ☐ Someone can observe usage in the relevant services.
• ☐ A documented action exists when usage reaches the agreed threshold.

Use the always-on agent cost guide to distinguish hosting from model usage, other services and operating work. The budget fields above are for your actual agreement; no default amount is implied.

6. Freeze the configuration to be accepted

• ☐ The accepted configuration can be identified later.
• ☐ Required files and tools exist on the target host.
• ☐ The test environment uses harmless fixtures or appropriately authorized data.

7. Run the client acceptance matrix

Write expected behavior before testing. In each evidence field, keep the run ID, timestamp and destination reference that let an operator verify the outcome. Keep confidential payloads in their authorized system.

Mark a case Pass, Fail, Not run or Not applicable. Explain each Not applicable decision. Do not count a skipped case as a pass.

Acceptance tests concern behavior under the conditions tested. They are not an exhaustive security audit or a promise about every future model response.

8. Prepare the operating handoff

• ☐ The operator knows where to see the last successful task and any pending work.
• ☐ Alerts identify the workload, failed stage and action owner without exposing secret or client content.
• ☐ A missed expected run has a detection method.
• ☐ The incident procedure identifies how to stop new actions and preserve relevant evidence.
• ☐ Before retrying a failed action, the operator checks whether it already changed the destination.
• ☐ A model, prompt, tool or runtime change triggers the relevant acceptance cases again.
• ☐ Support hours, escalation and exclusions match the actual client agreement.

9. Rehearse recovery

• ☐ A configuration template and an installation image are not being represented as a complete customer backup.
• ☐ The team knows which required state is omitted from each export.
• ☐ Recovery was tested in a disposable destination with outbound actions controlled.
• ☐ The recovered setup passed a representative acceptance case.
• ☐ Any stated recovery time or acceptable data loss follows the agreement and tested procedure.

Read the backup and recovery guide before relying on a platform or runtime export.

10. Make launch a recorded decision

Proposed decision rule: Launch only when every required acceptance case has passed, the client has accepted the output, and the operating and offboarding owners are assigned. Resolve failures or reduce the scope and rerun the affected cases. Record a reason for every case excluded from the agreed scope.

11. Plan offboarding before you need it

• ☐ The agreement says what the client receives and in which format.
• ☐ Pending tasks and external changes will be reconciled before shutdown.
• ☐ Only the intended destination remains active after a transfer.
• ☐ The recipient verifies that the delivered material is usable.
• ☐ Agency access is removed from each relevant external account.
• ☐ Resource deletion, subscription cancellation and external credential revocation are checked separately.
• ☐ Retained copies have an agreed purpose, owner and removal date.

The agent migration guide provides a more detailed cutover and rollback sequence.

Fictional worked example: a weekly draft brief

This example is fictional and has not been executed. It illustrates how to fill the worksheet. “Example Client,” the role names and the workflow are invented. No test result, customer outcome or cloudrun integration capability is implied.

Workload: Prepare a weekly draft summary from an approved project-notes folder. Deliver the draft to the client's reviewer. The agent must not publish it or change the source records.

Example acceptance cases

Example decision: Hold. The budget is unapproved, the integration path has not been validated and acceptance cases have not run. The next step is to configure a harmless pilot, verify the source and delivery connections, agree on cost and execute the matrix.