Operating an AI agent fleet for an agency

Operating an AI agent fleet for an agency means giving every client workload an owner, a defined permission boundary, a budget, and a recovery procedure. Start with an inventory and one repeatable operating routine. Add automation after you can tell whether a request succeeded, who it affected, and how to stop it.

This is a proposed operating playbook. It does not describe features available in every hosting service or claim that cloudrun currently provides a complete fleet-management system. You can implement the routine with a small registry, your provider's controls, and documented manual steps.

Make the client boundary explicit

Treat each client as a separate trust boundary unless the clients have explicitly agreed to share access. Keep client credentials and workspaces separate, and test that the agent for one client cannot read another client's files or use its integrations.

For OpenClaw, this distinction follows the runtime's documented model: a gateway serves one trusted boundary, while mutually untrusted users should use separate gateways and credentials, ideally with separate OS users or hosts. A conversation label does not establish isolation. OpenClaw security model

Write down the boundary before picking how many agents fit on a machine. A server arrangement that is convenient for billing can still give the wrong people access to client material.

Use a representative access test with harmless sample data. Give Client A a distinct test file and credential, then verify that Client B's agent cannot retrieve the file or perform an operation with that credential. Repeat after changes to mounts, shared tools, or runtime configuration.

Keep a fleet register that answers operating questions

Give each running workload a stable internal name. A client can have several agents, and an agent can change hosts; do not make the server address its identity.

These example entries are fictional. Fill the register with your actual owners and evidence. Store references to secrets, never the secret values themselves, and restrict access to the register if it exposes sensitive infrastructure details.

Build each workload's budget with the always-on agent cost model, including usage and operator time alongside the hosting invoice.

Agree on what a successful job means

Define success around the client's outcome. For an inbox agent, success might mean reading a new message, creating a correctly attributed draft, and leaving it in the expected mailbox folder. A green server indicator cannot establish that outcome.

Write a small acceptance set before onboarding: an ordinary request, missing information, an unauthorized request, an unavailable integration, and a duplicate delivery. Record the expected behavior for each. These cases become the checks you repeat when changing a model, prompt, tool, or runtime.

Make consequential actions explicit. An agent allowed to draft a reply should not acquire permission to send because someone changed a prompt. Keep approval requirements in the application's controls and connected-account permissions wherever possible.

Choose a service objective the client understands, with its observation window and exclusions. For example, you might propose that eligible messages receive a draft within ten minutes during agreed operating hours. That is a proposed objective to test and negotiate, not an uptime promise established by installing monitoring.

Put the first client workload into a workspace

Start with one agreed task and test data. In cloudrun, create a workspace and a project, then use its Hermes agent to check the instructions, connected tools and expected output. Add a schedule only after a manual test produces the result you agreed with the client.

Keep the client boundary explicit. Profiles within an engine share its environment; a profile name does not establish isolation. Your agency still owns the service scope, client permissions, acceptance checks and handoff.

Use the client-agent launch checklist to record those decisions before the pilot. The cloudrun guide for agencies connects that operating routine to the workspace setup.

Create your agency workspace, or follow the workspace and project setup guide.

Monitor the job and the machine

Google's SRE guidance groups service monitoring around latency, traffic, errors, and saturation. For agents, translate those signals into waiting time, accepted jobs, failed outcomes, and resource or concurrency pressure. Google SRE monitoring guidance

Add workflow-specific observations: the age of the oldest unfinished job, time since the last expected scheduled run, and whether the destination acknowledged the result. Associate each run with its client and configuration version so an operator can investigate without reconstructing the deployment history.

Keep sensitive content out of routine alerts. An alert can identify the client, failed stage, and log reference without pasting a private email or API key into a shared channel.

Route an alert only when someone has an action to take. A single retried request may need a record; repeated delivery failures need an operator. Set the distinction using the workflow's tolerance for delay and duplicate actions.

Roll changes through a small group first

Maintain a known working configuration and change record. Include the runtime version, model identifier, prompt revision, tool permissions, and dependency changes. An update to any of them can alter behavior.

Use a test workload first, then a consenting low-risk client, before extending a change to the fleet. Google describes canary releases as evaluating a change against a limited part of production before broader rollout. The agency version can be small, provided the acceptance criteria and rollback decision are explicit. Google SRE canary guidance

Compare the acceptance set, completion rate, latency, and spend with the previous configuration. Decide how long to observe based on how frequently the relevant jobs run. A monthly reporting agent needs a deliberate test; waiting an hour will reveal little.

Check whether rollback is possible after a state migration. Restoring an older executable may be insufficient if the new version changed stored data. Keep a recovery route for that case before rollout.

Give incidents a safe first action

For each workload, document how an operator stops new actions while retaining logs and state. A failed research job and an agent sending duplicate client messages need different urgency, but both need a known way to pause.

Use this incident sequence:

1. Confirm which clients and actions are affected.
2. Pause the affected work or revoke the relevant integration when needed.
3. Preserve the run identifiers, timestamps, and configuration version.
4. Check the host, model provider, and destination separately.
5. Recover using the documented procedure and a harmless verification job.
6. Resume gradually and reconcile unfinished or duplicated work.

Do not blindly replay a failed job that may already have changed an external system. Check the destination's receipt or operation identifier first. Where the integration supports idempotency, use it; otherwise build a reconciliation step around the destination's actual state.

Practice recovery before promising it

Record what a backup includes: workspace files, configuration, databases, credentials, and external records can have different recovery paths. Restore a disposable copy and run an acceptance case against it with outbound actions disabled.

DigitalOcean's backup documentation, for example, describes system-level backups for reverting a Droplet or creating another one. That provider capability is useful evidence about infrastructure recovery; the agency still needs to verify that its agent's required state and integrations recover together. DigitalOcean backups

Agree on acceptable data loss and recovery time with the client after testing the procedure. Record the measured result and the conditions. Do not turn an untested retention setting into a recovery commitment.

Make offboarding part of onboarding

Decide who owns the model account, connected accounts, and exported state at the start of the engagement. Explain which state can move and which integrations need reauthorization.

Use the inventory and cutover steps in the agent migration checklist when moving a client's existing local setup onto managed hosting.

At offboarding, pause schedules, reconcile pending jobs, deliver the agreed export, and verify that the recipient can use it. Revoke agency access to client accounts and close hosting resources according to the agreed retention procedure. Record completion separately for each system; deleting the agent does not necessarily revoke an external credential.

Review the fleet register weekly for ownerless alerts, unexplained spend, overdue changes, and failed recovery tests. Put each issue with a named person and due date. The register becomes useful when it drives those decisions.