# 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 | Field | Fill in | | -------------------------------------------- | ------- | | Client name | | | Workload name and stable internal ID | | | Business outcome | | | Business owner and acceptance contact | | | Technical owner | | | Backup operator | | | Client escalation contact and channel | | | Expected operating hours and timezone | | | Human fallback when the agent is unavailable | | | Target launch date | | | Document owner and last reviewed date | | - [ ] 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 | Decision | Fill in | | ------------------------------------------- | ------- | | Accepted inputs and their source | | | Required output and delivery destination | | | Allowed reads | | | Allowed writes | | | Actions requiring human approval | | | Actions the agent must refuse | | | Expected behavior when input is incomplete | | | Completion deadline or delivery expectation | | | How the destination confirms completion | | | What happens when a request arrives twice | | - [ ] 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 | Component | Identifier or reference | Owner | Who can access it? | | -------------------------------- | ----------------------- | ----- | ------------------ | | Hosting account and organization | | | | | Project and engine/runtime | | | | | Machine/container, where exposed | | | | | Agent/profile | | | | | Workspace and state locations | | | | | Connected services | | | | | Human access roles | | | | - [ ] 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](https://www.usecloudrun.com/blog/how-cloudrun-isolates-ai-agents) distinguishes the engine boundary from Hermes profiles and explains the limits of the dated evidence. ## 4. Assign account and credential ownership | Service/account | Business owner | Authorized scope | Secret-store reference | Renewal owner | Revocation procedure reference | | ----------------- | -------------- | ---------------- | ---------------------- | ------------- | ------------------------------ | | Model provider | | | | | | | Source system | | | | | | | Delivery channel | | | | | | | Other integration | | | | | | - [ ] 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](https://www.usecloudrun.com/blog/byok-hosted-ai-agents) explains the difference between removing a key from configuration and revoking it at the provider. ## 5. Record cost and stop decisions | Cost or decision | Approved amount, rule or reference | Owner | | ----------------------------- | ---------------------------------- | ----- | | Hosting | | | | Model usage | | | | Connected-service usage | | | | Setup and operating time | | | | Notification threshold | | | | Stop threshold and action | | | | Where actual usage is checked | | | | Review frequency | | | - [ ] 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](https://www.usecloudrun.com/blog/always-on-ai-agent-cost) 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 | Configuration | Version or reference | | -------------------------------------- | -------------------- | | Runtime | | | Model/provider configuration | | | Instructions/prompt | | | Skills and custom tools | | | Integration permissions | | | Input/output schema, if applicable | | | Schedule and timezone | | | Channel routing | | | Known working configuration to restore | | - [ ] 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. | Case | Input or condition | Expected behavior | Observed result and evidence | Status | Reviewer | | ------------------------------------ | ------------------ | ----------------- | ---------------------------- | ------- | -------- | | Ordinary task | | | | Not run | | | Missing required input | | | | Not run | | | Incorrect or conflicting source data | | | | Not run | | | Unauthorized requester | | | | Not run | | | Other client's data or credential | | | | Not run | | | Action requiring approval | | | | Not run | | | Disconnected/expired integration | | | | Not run | | | Model/provider unavailable | | | | Not run | | | Duplicate request or delivery | | | | Not run | | | Scheduled run and timezone | | | | Not run | | | Destination receives the result | | | | Not run | | | Usage threshold or stop rule | | | | Not run | | | Restart with pending work | | | | Not run | | | Pause and controlled resume | | | | Not run | | | Recovery of required state | | | | Not run | | 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. | Operating item | Procedure or reference | Owner | | -------------------------------------- | ---------------------- | ----- | | Health/outcome check | | | | Failure alert | | | | Stop new work | | | | Inspect external actions before replay | | | | Restore known configuration | | | | Approve and roll out a change | | | | Incident communication | | | ## 9. Rehearse recovery | State needed | Included in which export/backup? | Last verified copy | Restore procedure | Test result and date | | ---------------------------------------- | -------------------------------- | ------------------ | ----------------- | -------------------- | | Instructions/configuration | | | | | | Skills/custom tools | | | | | | Required files | | | | | | Memory/history required by the agreement | | | | | | Credentials or reauthorization steps | | | | | | Schedules and channel routing | | | | | | External-system records | | | | | - [ ] 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](https://www.usecloudrun.com/blog/backup-recovery-always-on-agents) 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. | Launch decision | Record | | -------------------------------------------------- | ------ | | Required cases and any excluded cases with reasons | | | Open issues and effect on the agreed scope | | | Accepted configuration reference | | | Final decision: launch / hold | | | Client acceptance contact, decision and date | | | Technical owner, decision and date | | | First post-launch review date | | ## 11. Plan offboarding before you need it | Handoff item | Recipient | Export/transfer procedure | Access to revoke | Completion evidence | | -------------------------------------- | --------- | ------------------------- | ---------------- | ------------------- | | Instructions, skills and configuration | | | | | | Required files and agreed history | | | | | | Model account | | | | | | Connected services | | | | | | Channels and schedules | | | | | | Hosting administration and billing | | | | | | Backups and retained copies | | | | | - [ ] 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](https://www.usecloudrun.com/blog/migrating-local-agent-to-managed-hosting) 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. | Field | Example entry | | ----------------- | --------------------------------------------------------------------------------------------- | | Client | Example Client | | Workload ID | example-weekly-project-brief | | Business owner | Client project lead | | Technical owner | Agency automation engineer | | Backup operator | Agency duty operator | | Input | Approved sample project notes in a test folder | | Output | Draft summary with source references and a missing-information section | | Allowed actions | Read the approved folder; deliver the draft to the reviewer | | Approval boundary | Reviewer decides whether and where to publish the draft | | Account ownership | Client owns source and delivery accounts; agency receives the approved access | | Credential record | References to the client's chosen secret store; no values in this worksheet | | Schedule proposal | Monday morning in the client's agreed timezone; exact trigger to be configured and tested | | Failure fallback | Notify the named operator; reviewer prepares the brief manually if needed | | Recovery approach | Keep a reviewed configuration copy and verify the host's export/restore support before launch | | Budget | Awaiting client agreement; no launch budget approved in this example | ### Example acceptance cases | Case | Input or condition | Expected behavior | Status/evidence | | --------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------------- | | Ordinary task | Harmless notes with three completed project updates | Draft identifies all three updates and links to their sources | Not run; no evidence | | Missing information | A note lacks an owner | Draft flags the missing owner without inventing one | Not run; no evidence | | Unauthorized source | Request to read an unrelated client's folder | Access denied; no unrelated content in the draft | Not run; no evidence | | Publication request | Message asks the agent to publish the brief | Agent leaves publication to the reviewer; write access remains unavailable | Not run; no evidence | | Duplicate trigger | The same scheduled task arrives twice | Behavior follows the agreed duplicate rule; reviewer receives no unintended duplicate | Not run; no evidence | | Disconnected source | Source authorization is revoked | Failure is visible to the operator; agent does not present a stale brief as current | Not run; no evidence | | Delivery | Draft generation succeeds | The intended reviewer receives the draft once | Not run; no evidence | | Offboarding rehearsal | Agency access is removed | Client retains agreed artifacts; agency can no longer use the connected accounts | Not run; no evidence | **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.