A small team launches an always-on AI agent and quickly discovers that the hard part isn't the model. It's the host. Someone rebuilds a server after a node failure, another person searches for the right SSH key, and everyone hopes the expected Python version, secrets, volumes, and network rules survived the last deploy.
That's an infrastructure provisioning problem. The work turns blank cloud capacity or physical hardware into a known runtime, then keeps that runtime reproducible as agents, applications, and policies change. For long-lived agents, provisioning also determines whether sessions stay isolated, memory survives replacement, and data remains in the required region.
Table of Contents
What Infrastructure Provisioning Actually Means Today
Infrastructure provisioning is the disciplined process of preparing and activating the compute, storage, networking, identity, and configuration a workload needs to run predictably. A provisioned host isn't merely a virtual machine that exists. It has a defined operating system, runtime dependencies, permissions, storage attachments, observability, network placement, and lifecycle policy.
That distinction matters for an AI agent that runs continuously. If one host has a different dependency version, a broader credential scope, or a missing volume, the agent may behave differently from its peers. A configuration mistake can break a memory layer, expose a session, or leave a process running without the monitoring and restart behavior the team expects.
Cloud adoption has made this discipline central to infrastructure operations. Worldwide end-user spending on public cloud services is projected to reach USD 723.4 billion in 2025, compared with USD 595.7 billion in 2024, according to StartUs Insights' cloud infrastructure outlook. Provisioning is the mechanism that turns that expanding pool of infrastructure into usable application capacity.
Provisioning is not deployment
The terms overlap, but they describe different layers:
Provisioning creates or prepares the host and its foundational resources, such as machines, networks, disks, identities, and regions.
Deployment places an application or agent onto infrastructure that already exists.
Configuration management installs packages and keeps operating-system or application settings aligned.
Orchestration coordinates many running workloads, scheduling them, replacing failed instances, and managing service relationships.
A simple agent example makes the boundary clear. Terraform might create a machine, attach a volume, place it in a private network, and assign an identity. An image or Ansible playbook might install the agent runtime and system services. A deployment pipeline might publish the agent configuration. Kubernetes or another controller might keep the workload running after a failure.
Practical rule: Provision the trust boundary first. Deploy the workload only after the host, identity, storage, and network behavior are explicit.
Manual work becomes costly when every host is slightly different. HashiCorp's 2024 State of Cloud Strategy survey found that 91% of respondents said they were wasting money in the cloud, with skills shortages, overprovisioning, and idle or underused resources among the most common causes. Infrastructure provisioning evolved toward automation because human operators can't reliably reconcile rapidly changing resources, dependencies, and policies by hand.
Comparing the Main Provisioning Approaches
There isn't one correct provisioning method. The right choice depends on how often infrastructure changes, how damaging a mistake would be, how many people operate it, and how much audit evidence the organization needs.
| Approach | Control | Speed | Repeatability | Best Fit |
|---|---|---|---|---|
| Manual consoles and SSH | Very high locally | Fast for one host | Low | Experiments, emergency repair, legacy systems |
| Ad-hoc shell scripts | High, if understood | Fast after setup | Moderate | Small fleets and narrow workflows |
| Declarative Infrastructure as Code | Strong through reviewed definitions | Efficient at repeatable scale | High | Shared foundations, multi-environment teams |
| Policy-driven orchestration | Indirect, through controllers | Fast for recurring changes | High when the platform is mature | Elastic workloads and self-healing fleets |
Manual provisioning
Console clicks and SSH sessions give an operator immediate control. That's useful when diagnosing a broken machine or exploring an unfamiliar service. The cost is hidden state. A command typed once may never make it into documentation, and the next host may miss a package, firewall rule, or secret.
For a single disposable experiment, that trade-off can be reasonable. It becomes dangerous when several agents need the same environment or when a rebuild must happen during an incident.
Scripts and golden images
Shell scripts reduce repetition. A script can install a runtime, create a service account, fetch an agent package, and start a process. Golden images move more work earlier by baking the operating system and common dependencies into a reusable artifact.
Scripts still depend on execution order, environment variables, external services, and assumptions about the starting host. They can produce a fast result while leaving the final state difficult to inspect. They're a practical bridge, not automatically a source of truth.
Declarative Infrastructure as Code
Terraform, Pulumi, and OpenTofu describe the intended infrastructure in machine-readable files. A plan can be reviewed before changes apply, and the state model helps the tool understand what it created. The price is operational discipline. Teams must manage state, provider versions, secrets, imports, module boundaries, and changes made outside the workflow.
A comparative study of automated infrastructure provisioning describes Infrastructure as Code as a way to manage resources through definition files rather than interactive configuration, and reports that automation reduces manual effort, human error, and inconsistency. That makes IaC particularly useful when an agent host must be recreated, audited, or rolled back without relying on someone's memory.
Controllers and orchestration
Kubernetes operators and cloud-native controllers continuously compare desired state with observed state. They can replace failed workloads, attach services, and react to changes without a human starting each action. This gives up some direct control in exchange for a stronger automation loop and a larger abstraction layer.
Most production environments combine these approaches. A team might use Terraform for networks and machines, Packer for base images, Ansible for host configuration, and Kubernetes for elastic services. The useful question isn't “Which tool wins?” It's “Which layer owns each decision, and can the team explain the resulting state?”
Hosting Always-On AI Agents on Isolated Machines
The one-agent-per-machine pattern treats isolation as a provisioning decision. It gives each always-on agent its own compute boundary, identity, process supervision, and storage rather than placing unrelated agents on a shared host.
That separation helps when agents have different dependency graphs or workload patterns. One agent may spend its time processing messages, while another runs repository tasks and consumes bursts of CPU, memory, or disk. A noisy neighbor can affect response time, and a failed upgrade can disturb every process on a shared machine.
Make the host contract explicit
Start with the agent's actual behavior, not a generic machine size. Context handling, tool calls, local indexes, log volume, concurrency, and model endpoint behavior all affect the host contract. Size for the workload you can observe, then make resource limits and alert thresholds part of the definition.
A host usually includes:
A dedicated identity: Give each agent only the permissions its tools require. Keep API keys and credentials outside the image, inject them through a secrets system, and make rotation independent of host replacement.
An immutable base image: Pin the operating system, runtime, and system dependencies. Build a new image for a deliberate upgrade instead of mutating a production host until it happens to work.
Explicit lifecycle defaults: Restart a crashed process, but don't auto-upgrade the agent runtime or model integration. Automatic recovery and automatic change are different policies.
Separate boundaries: Use network placement for reachability, a dedicated
systemdunit or equivalent for process supervision, and a per-host volume or remote store for state.
The agent should be replaceable. If a machine becomes suspect, the operator ought to be able to preserve the required memory and logs, revoke its identity, and rebuild the host from declared inputs. That's safer than treating local disk and manual shell history as permanent infrastructure.
For teams operating support agents, the host boundary also affects how conversations, integrations, and operational access are managed. A deployment that connects an agent to customer workflows should define who can inspect it and how credentials are separated. The Sokko customer support automation overview provides a product-context example of the kinds of agent workflows that may need this treatment.
Design against quiet failures
A process that stays alive isn't necessarily healthy. Watch for silent model or runtime drift, stuck sessions, exhausted disk, broken memory mounts, and credentials that appear in logs or become accessible to another agent. A restart policy can recover a crashed process, but it can't decide whether the process is producing correct results.
Isolation is useful only when the surrounding identity, network, storage, and observability boundaries are isolated too.
Shared Memory and Regional Residency as First-Class Concerns
An always-on agent can lose more than uptime when its host is replaced. Conversation history, embeddings, and operational notes stored only on local disk disappear with that machine. A shared object store, NFS volume, or managed vector database separates compute from state, allowing the team to rebuild the host while retaining the context that makes the agent useful.
The pattern resembles a shared filing room behind several isolated offices. Each agent machine accesses a controlled memory service, while that service provides durability, access policy, backups, and replication. Local disk remains suitable for caches and temporary files, but it should not hold the only copy of information needed after a rebuild.
Local-only storage gives a smaller failure boundary and can provide fast reads. Replacement and scaling expose its cost. A new machine may start without the previous agent's context, and two hosts created from one template can diverge as each writes different local state.
Shared storage preserves continuity, while extending the blast radius. A permission error, accidental deletion, or incompatible schema can affect several agents. Use separate namespaces, access policies, versioned records, and tested recovery procedures. “Shared” should describe a service boundary, not unrestricted access.
The same design discipline applies to regional residency. Region selection belongs in the provisioning contract, not as a late runtime preference. Machines, storage, encryption keys, backups, logs, and model inference may all process sensitive data, so their locations and permitted paths need explicit rules.
A region-bound deployment might include:
A global control plane that routes requests to region-specific agent clusters.
Region-pinned machine pools with no fallback to an unauthorized location.
Dedicated KMS keys and region-local backup policies.
Pre-warmed capacity where cold provisioning would create unacceptable latency.
Separate operational access and audit scopes for each residency boundary.
European sovereign cloud spending is projected to rise from USD 6.9 billion in 2025 to USD 23.1 billion by 2027, as noted earlier in the article. The practical consequence is that regional choices increasingly shape provisioning architecture, rather than remaining a procurement detail.
The shared memory design for multi-agent systems shows why memory placement belongs in the same design decision as machine placement. Latency, compliance scope, recovery behavior, and operational blast radius are connected. A team that chooses one without examining the others can create an agent that is available but difficult to recover or govern.
A video can help teams visualize the relationship between isolated runtimes and shared state:
A Step-by-Step Provisioning Workflow With an Agent Loop
A useful workflow begins with a request, not with a server. A developer asks an agent for a devbox, perhaps to run a branch with its application, database, and queue. The agent converts that intent into a structured provisioning request, and an API starts a workflow that can be retried safely.
1. Detect the requested stack
The request should carry the repository, branch, target region, access mode, expected lifetime, and any declared resources. Automated stack detection can inspect repository files and select an approved path for a Docker Compose application, a framework project, or another supported runtime.
Detection should produce a decision that an operator can inspect. If the repository is ambiguous, the system should ask for clarification or use a safe default rather than inventing a production dependency.
2. Select an IaC module and inject variables
A module defines the machine, network placement, storage, identity, firewall policy, and runtime attachments. Variables supply environment-specific values such as region, image version, repository reference, memory class, and expiry policy.
Keep this step idempotent. A retry shouldn't create a second volume or a duplicate identity because the first API response timed out. Stable names, ownership tags, state locking, and reconciliation rules matter more than clever prompts.
3. Apply residency and capacity rules
The provisioning engine chooses a machine pool in the permitted region and checks quotas, capacity, and policy. A human approval gate belongs here when the request crosses a cost threshold, accesses sensitive data, or asks for permissions outside the normal role.
Routine development environments shouldn't require an operator to approve every low-risk action. High-impact changes should produce a reviewable plan and an explicit decision.
4. Attach the agent and memory layer
Once the host exists, install or start the agent runtime, inject secrets through the approved channel, and attach shared memory using a region-compatible endpoint. Health checks should validate more than process existence. Test storage access, required tool permissions, network reachability, and the agent's ability to read its configuration.
5. Return a usable preview
The result should include a live preview URL, access instructions, logs, expiry information, and an identifier that ties the environment back to the request. A developer shouldn't need to search through a cloud console to learn whether the branch is ready.
The feedback loop continues after delivery. Telemetry can show a memory leak, a capacity mismatch, or a failed dependency. The agent or controller may trigger a rebuild or capacity adjustment within policy, while an operator is paged only when the remediation budget or approval boundary is exceeded.
Every step that can be retried must be idempotent. Every step that can spend money or widen access needs an explicit policy boundary.
Tooling Landscape From Scripts to Managed Agent Platforms
Teams usually assemble provisioning from several categories rather than selecting one product for everything.
| Category | Representative Tools | Best Fit | Trade-Off |
|---|---|---|---|
| Scripts and golden images | Shell, Packer, cloud-init | One-off or legacy hosts | Fast to start, harder to audit and reconcile |
| Configuration management | Ansible | Existing fleets and host configuration | Practical control, but depends on inventory and execution discipline |
| Declarative IaC | Terraform, Pulumi, OpenTofu | Cloud foundations and multi-environment resources | Reviewable state, with state and provider complexity |
| Cloud-native orchestration | Kubernetes, operators, Crossplane-style control planes | Elastic agent workloads | Self-healing and scalable, with significant abstraction overhead |
| Managed agent hosting | Platforms that bundle machines, previews, secrets, and memory | Teams buying the hosting layer | Less platform work, with platform-specific boundaries |
Shell scripts and images remain appropriate for a narrow legacy estate or a controlled one-off box. They're also useful as building blocks for image creation. The team should know exactly where the script runs, what inputs it needs, and how it reports failure.
Ansible fits fleets where machines already exist and need consistent package, service, and configuration management. It's particularly useful for the handoff after a provisioning tool creates a host. Terraform's own role is stronger at moving from no infrastructure to a declared architecture, while configuration tools manage the contents of that architecture.
Terraform, Pulumi, and OpenTofu earn their place when teams need reviewable changes across networks, storage, identities, and compute. A 2023 worldwide survey cited in HashiCorp's State of Cloud Strategy material reported Terraform usage among 33% of respondents, ahead of Ansible, Puppet, and Chef at 22%, supporting the view that IaC is a mainstream provisioning approach.
Kubernetes and controller-based platforms make sense when workloads need scheduling, service discovery, replacement, and elastic capacity. They can host agents effectively, but the team must be comfortable debugging controllers, manifests, operators, and layered networking.
A managed agent platform can be sensible when the team wants isolated always-on runtimes, live previews, shared memory, and operational access without building every control plane component. Sokko is one example that provisions isolated machines for supported agent runtimes and devboxes, with shared persistent memory, regional hosting options, dashboard access, and preview URLs. The choice should follow team size, required control, compliance pressure, and agent count, not tool fashion.
Security Compliance Cost and Operations Trade-Offs
Provisioning patterns move costs and risks rather than eliminating them. One-agent-per-machine isolation can reduce noisy-neighbor effects and narrow the blast radius of a compromised process, but it usually consumes more infrastructure than placing several agents on one host. Shared memory can reduce duplicated state and simplify continuity, while a shared store also becomes a high-value target that needs stronger access controls and recovery procedures.
Regional residency adds infrastructure boundaries. Region-pinned machines, storage, keys, backups, logs, and inference paths make compliance easier to reason about, but they can reduce scheduling flexibility and require capacity planning in each permitted location. Teams handling European workloads can use regional data-residency requirements as a design input before choosing host and memory topology.
| Pattern | Security and Compliance | Cost Impact | Operational Signal |
|---|---|---|---|
| One agent per machine | Smaller process blast radius and clearer identity boundaries | More hosts and potentially lower utilization | Host health, resource saturation, and per-agent availability |
| Shared persistent memory | Central policy and audit point, but wider impact from store errors | Less duplicated state, with storage and backup overhead | Read or write failures, replication health, and access anomalies |
| Region-bound pools | Easier residency enforcement and scoped audit evidence | Extra regional capacity and less placement flexibility | Regional capacity, routing failures, and residency policy violations |
| Declarative provisioning | Reviewable changes, traceable ownership, and repeatable evidence | Tooling and state-management overhead | Plan drift, failed applies, and unmanaged resources |
| Controller-driven recovery | Automated remediation within policy | Control-plane complexity and monitoring cost | Reconciliation errors, retry loops, and remediation frequency |
IaC makes several compliance tasks tractable. Teams can review image provenance, record who changed a module, constrain secret references, produce audit logs, and show that a machine's identity and network placement came from an approved definition. It doesn't make the infrastructure compliant by itself. A permissive policy expressed perfectly in code is still permissive.
Operations need signals tied to action. Page someone when an agent loses access to required memory, when a region violates a placement rule, or when remediation loops without progress. Send capacity warnings before a pool can't satisfy approved requests. Track drift when a console edit, manual package change, or unmanaged resource causes reality to diverge from the declared system.
HashiCorp's survey found that 66% of organizations increased cloud spending in the last year, compared with 56% in 2023, while only 8% qualified as highly cloud mature, as reported in the 2024 State of Cloud Strategy survey. Those figures reinforce a practical point: cost visibility and operational maturity need to grow alongside provisioning automation.
Best Practices and Questions to Ask Before You Provision
A host is ready for service when another operator can rebuild it, understand its limits, and restore its agent during an incident. Review the design with these questions:
Codify every machine: Can the team recreate the host without SSH history or undocumented console steps?
Version-lock the base: Which operating system, runtime, agent package, and model integration does it use?
Treat lifecycle as code: What happens after a crash, expiry, rollback, image change, or regional capacity failure?
Centralize secrets: Who can retrieve each credential, where is it injected, and can rotation avoid rebuilding the fleet?
Design for replacement: Which data must survive host loss? Does it live in shared memory, a backup, or nowhere?
Define residency before routing: Which region may receive requests, store memory, write logs, or run inference?
Instrument drift and cost: How will the team find an unmanaged resource, manual change, idle machine, or unexpected storage growth?
Test recovery deliberately: Can the team revoke an identity, rebuild a host, restore memory, and return the agent to service without improvising?
These checks connect provisioning choices to specific agent-hosting jobs. One-agent-per-machine isolation needs repeatable host images and clear replacement rules. Shared memory needs an explicit durability and recovery plan. Regional residency needs placement rules that apply to requests, logs, memory, and inference, not only to the machine's location.
A 2025 IaC maturity survey reported that only 3% of organizations had fully transitioned all infrastructure to code, while 13% described their provisioning or deployment process as fully mature, according to StackGen's IaC maturity analysis. The same source found lower adoption in mixed cloud and on-premises environments than in cloud-only setups. Hybrid estates therefore need named ownership boundaries and a defined transition path.
Choose the approach according to the operating problem. Scripts can suit a stable legacy host. IaC fits fleets whose machines and changes need repeatable review. Orchestration earns its added control-plane work when agents are elastic and recovery must be automatic. A managed platform can fit teams focused on running agents and devboxes instead of building that control plane.
Sokko provides managed, isolated machines for always-on AI agents and disposable devboxes, with shared persistent memory, regional hosting options, live terminals, and branch preview URLs. Visit Sokko to evaluate whether its provisioning model fits your agent-hosting and infrastructure operations needs.