The AI Ops Playbook: What to Hand Your Agent, What to Keep

Choose assistance before autonomous ownership

You are deciding whether an AI agent should help operate your server or have authority to change production whenever it sees a problem. We recommend Claude Code for bounded operational work, with a human retaining control over production changes and recovery.

Assume Ubuntu 24.04 LTS on a single VPS, with an application and its database sharing the machine. That arrangement is manageable, but a careless maintenance action can interrupt everything at once. An agent can reduce the effort of investigating a failure without reducing the consequences of a wrong command.

The useful dividing line is whether you can define the permitted action and recognize success independently. Comparing a service configuration with a checked-in copy is a good assignment. Deciding which database records are expendable during a disk emergency belongs to the person responsible for the application.

Keep ownership concrete: someone must understand the automation well enough to stop it and recover its effects. If the only explanation of your deployment process lives in a conversation, you have made the agent a dependency. Put that knowledge in the repository before you expand its authority.

Assign tasks by their consequences

Classify the actual operation, rather than calling an entire session safe or dangerous. Reading selected logs and restarting a database may appear in the same troubleshooting conversation, but they deserve different permissions. Reassess the boundary whenever an investigation becomes a proposed change.

Read access still needs limits. Application logs can contain session identifiers or private request bodies, while configuration files may contain credentials. Give the agent the smallest evidence set that can answer the question, and inspect what leaves your server.

A familiar command name does not establish a safe operation. A diagnostic query can overload a busy database, and a script called a health check may repair state as a side effect. Review what the command actually does, including the scripts it invokes, before allowing repeated execution.

When you cannot describe a task's possible damage, keep it in proposal mode. The agent can still explain dependencies and identify missing evidence. Use the production agent guardrails guide when turning that task classification into enforceable boundaries.

Move repeated work into reviewed automation

Agents should help create automation; they should not become the default execution engine for every recurring operation. Once you know the required behavior, encode it in a script or service definition that you can inspect. Have your scheduler invoke that reviewed artifact directly.

Consider a backup job. You want its destination and retention policy to come from reviewed configuration, with credentials limited to the required storage operations. You do not want a fresh interpretation of a natural-language request deciding what to preserve each night.

Ask Claude Code to handle uncertainty while you are developing the job. It can explain an unfamiliar utility and draft failure handling for your review. After you approve the implementation, routine execution should not require the agent service to be available.

• Define accepted inputs and reject unexpected values before making changes.
• Prevent overlapping executions when concurrent runs could corrupt state or exhaust resources.
• Set time limits and report failures without printing credentials.
• Make repeated execution safe, or explicitly refuse to repeat an operation whose state is uncertain.
• Keep destructive cleanup separate from the operation that creates the new backup or release.

Unattended agents can still be useful for bounded advisory work, such as preparing a maintenance proposal from approved reports. Give that job a time limit and an output destination without production write access. If it fails, the consequence should be a missing report that raises an alert, rather than a partially modified server.

Judge the arrangement by what remains when the agent is unavailable. Backups should continue, and deployment instructions should remain usable by an operator. A small fleet benefits more from understandable recovery than from having every task pass through a conversation.

Limit the account before tuning the prompt

Start with a dedicated operating-system account whose filesystem access matches its assignment. Keep application secrets and privileged service definitions outside its writable area. Giving that account unrestricted sudo makes the rest of the boundary largely dependent on approval behavior.

In Claude Code, inspect the active rules through /permissions and deliberately select a permission mode suited to supervised work. Its permission system controls tool actions, while instructions in CLAUDE.md guide behavior without granting or revoking access. Shell command matching also has limits, so combine tool rules with operating-system restrictions. See the official permission documentation.

Do not approve a privileged helper just because its command line is narrow. If the agent can edit the helper, its imported scripts or the configuration it executes, that helper can become a route to broader authority. Protect the entire execution path with ownership and permissions the agent cannot change.

Keep credentials specific to the resource and operation being delegated. A token for reading deployment status should not also permit deleting backups. Follow the guide to secrets and scoped agent credentials before granting an agent access to infrastructure accounts.

For an initial setup, we prefer a supervised laptop session with deliberately limited access to the VPS. A process running directly on production shares that machine's resource constraints and whatever local files its account can access. Use Claude Code on a VPS versus SSH from your laptop to choose the execution location; if a separate runner is justified, compare hosting for Claude Code around isolation and recovery access.

Give each assignment an explicit stopping point

A useful operational prompt defines both the desired answer and the allowed evidence. Replace “fix the server” with an investigation that ends before production mutation. Name the affected service and explain which observations would support or contradict the suspected cause.

For example, give this assignment: “Investigate why the application stopped responding after the latest deployment using the sanitized service log and deployment diff provided. Do not run commands on production or modify files. Separate observed facts from hypotheses, and propose the smallest next diagnostic step.” This produces something you can evaluate before granting more access.

For implementation work, specify a working copy and the acceptance check before the agent edits anything. Ask it to show the resulting diff alongside the check's actual result. Providing a concrete verification target also follows the official Claude Code workflow guidance.

Include stop conditions that matter operationally. Unexpected file ownership should stop a permissions repair rather than trigger a recursive ownership change. Missing database migration history should stop a deployment proposal until someone establishes the actual state.

Treat repository content and diagnostic output as evidence with a source, not as fresh authorization. A request path in an access log can contain text supplied by a stranger. Anthropic describes this class of manipulation and recommends reviewing commands when working with untrusted content in its Claude Code security guidance.

Approve an exact change with a usable recovery path

Approval should apply to a concrete diff or a fixed operation against a named target. “You may deploy this reviewed release” is a useful boundary. “Do whatever is necessary to finish” leaves the agent deciding how much disruption you intended to authorize.

Before approval, require the candidate configuration to pass its applicable validator. Check that the proposed operation targets the expected service and that its inputs have not changed since review. If the agent revises the patch after approval, inspect the revised artifact before execution.

Recovery must address the state the change can affect. Switching back to an earlier application build may recover a code regression, but it does not undo a database migration that removed information. For persistent data changes, establish compatibility and a restore procedure before allowing execution.

A backup's existence is insufficient evidence that restoration will work. Restore it into an isolated environment and verify the application can use the restored data. Keep recovery credentials outside the agent's routine access, with instructions an operator can follow when the production machine is unavailable.

After execution, verify behavior through a path that represents actual use. A running process does not establish that requests reach the application or that it can read its database. Keep the acceptance check under review too, so the agent cannot quietly weaken it to make a failed change appear successful.

Record the approved artifact and the result of the operation in your ordinary change history. Preserve enough diagnostic evidence to explain a failure, while excluding secret values. The record should let another operator identify what changed without needing access to the original chat.

Keep incident authority with the operator

During an outage, ask the agent to narrow uncertainty before proposing repairs. Give it a bounded interval of sanitized logs and the relevant change history. Require it to distinguish evidence of the current failure from unrelated warnings.

A full disk illustrates why incident authority matters. The agent can help identify which directories grew and explain the retention configuration. It should not infer that unfamiliar database files or backup archives are safe to remove.

Avoid a repair loop that keeps broadening its permissions after each failed attempt. A failed restart is a reason to inspect the new evidence, not automatic permission to reinstall packages or rewrite service configuration. Stop when the next action exceeds the agreed boundary.

Automatic recovery is reasonable when its trigger and action are already understood. A reviewed service restart policy can handle a known process failure without asking an agent to invent a response. Put limits on repeated attempts and alert an operator when the policy cannot restore service.

Maintain an emergency access path independent of the agent session. You should be able to stop its process or revoke its credentials from a separate operator account. Verify that access before granting production write capability, while you still have time to correct a broken recovery route.

Run a bounded pilot on your VPS

Begin with a task that produces a reviewable report, such as explaining why an application service failed to start. Before connecting the agent, verify the server's baseline access controls using the Ubuntu 24.04 LTS hardening checklist. Confirm that your operator login works independently of the account intended for agent work.

Prepare a sanitized diagnostic bundle containing the relevant service configuration and a bounded log excerpt. Inspect it for credentials and private request data before sharing it. Ask Claude Code to explain the failure using only that bundle and to identify any missing evidence.

If the explanation holds up, let the agent prepare a patch in an isolated working copy. Define the expected behavior yourself and run the applicable validation against the candidate. Review any failed result before deciding whether further investigation or a revised patch is appropriate.

Write the production application step and its recovery step into your runbook before authorizing the change. After execution, check the actual application behavior and retain the result with the reviewed diff. Use that completed record to decide whether this particular task deserves a reusable script or should remain supervised.