← All articles

ENGINEERING · AI VM SETUP BLUEPRINT

How skills turn an AI agent into a structured server setup workflow

An AI agent can produce a working server quickly. The harder part is knowing which environment it changed, why it made each decision, and whether you can rebuild the result. That is the problem this blueprint is designed to address.

  1. 01Discover
  2. 02Adapt
  3. 03Execute
  4. 04Verify
  5. 05Hand over
Each stage records its state and evidence. Missing evidence stays visible.

A skill is an instruction package, not a new model

The blueprint is built around Markdown skill files. They describe what the agent should inspect, the changes a stage owns, the checks it must perform and when it needs to stop. The agent still uses its own tools and reasoning to carry out the work.

This is not a deterministic installer. Different providers and existing environments need different implementations. The instructions structure that adaptation; they do not make the underlying model infallible.

One coordinator, twelve stages

The coordinator routes work from intake and planning through provider networking, Linux hardening, private access and storage, k3s, ingress and TLS, a private registry, backups, status endpoints and handover. Full-machine recovery is a separately selected rehearsal.

The agent loads the current stage, its inputs and the selected provider reference. This keeps the active context focused. Dependencies are explicit: a stage cannot claim success just because a later command happened to run.

Adapt the run, preserve the standard

The standard skills remain unchanged during customer execution. Environment-specific decisions and implementation live in a private runs/<run-id>/ directory. An adapted stage records its source reference, decisions, validation and rollback plan.

Discovery identifies the actual account, VM, domains and backup destination. Existing CLI defaults are not treated as authorization. For an existing server, the workflow starts with inventory and an explicit decision about what to preserve.

Run state makes interruption recoverable

A chat transcript is a poor operations handover. The run records requirements, decisions, a plan, stage status and evidence in files. Stages can be pending, in progress, blocked, passed or skipped, with reasons for gaps.

On resume, the agent reconciles saved state with the live environment before continuing. It must not blindly repeat creation, formatting or restore commands. Recovery-critical configuration belongs in the customer’s private stack repository; credentials remain in the operator’s secret store.

Access boundaries are part of the design

The target is a workload-ready, single-node k3s VM. Private human administration, separate public and private ingress paths, namespace isolation and scoped identities are part of the workflow. Synthetic probes check routing before real applications are introduced.

Fast mode authorizes a reviewed list of resources up front. Guided mode uses smaller batches and more explanation. Neither grants permission to delete unrelated resources or replace an existing server without an explicit decision. These instructions support operator control; they are not a security sandbox around the AI agent.

A backup check and a rebuild rehearsal prove different things

The backup stage checks protected off-VM backups and bounded restore behavior, including decryption and integrity. Finding an archive or seeing a successful backup command is not enough evidence on its own.

The optional full-machine rehearsal goes further: rebuilding the selected platform on authorized disposable resources. If it is skipped, the handover must say so. The base blueprint prepares the platform; it does not deploy the buyer’s applications. Application-specific recovery still needs verification once workloads are added.

The output is an environment you can understand

The handover ties the platform to its configuration, stage evidence, recovery instructions and remaining gaps. Workload deployment, migration and day-two operations are follow-up activities.

The useful promise is a repeatable process with visible checks and decisions. Setup duration and recovery time depend on the environment and must be measured in the actual run, not inferred from a successful demonstration elsewhere.