Traditional Hosting Is Broken for AI Agents

The cloud was built for web apps. A request arrives, a handler runs for a few milliseconds, a response goes out, and the process forgets everything. Thirty years of infrastructure work has been spent optimizing that one shape: stateless compute up front, durable state pushed down into a database.

AI agents are not that shape.

An agent keeps its working state in the process itself: conversation history, tool configuration, open connections, a task half finished. It runs for seconds or minutes, not milliseconds. It spends most of that time blocked on LLM calls and external APIs, does a burst of real work, then goes quiet for an hour. Stateful, long-running, bursty, and idle almost all the time. Every mainstream hosting model fails on at least one of those four properties.

Shove an agent into infrastructure built for web apps and the result is predictable. You overpay, you over-engineer, and you still ship something fragile.

VMs: Paying for an Empty Room

The simplest approach: spin up an EC2 instance, run the agent as a process. It works. The economics are terrible.

A t3.medium costs about $30 a month. Say your agent handles 100 requests a day at 30 seconds each. That is 50 minutes of work out of 1,440 minutes in a day, or 3.5% utilization. The other 96.5% of the machine's life is spent being billed.

The root problem is the billing unit. A VM bills for existence, not for work. The mismatch is invisible with one agent and ruinous with fifty: 50 agents at $30 each is $1,500 a month for a fleet of mostly sleeping processes.

And the invoice is only half the cost. You own OS patching, security updates, monitoring, restart-on-crash, capacity planning. None of that is agent logic. All of it is now your job.

Containers and Kubernetes: Solving the Wrong Problem

Kubernetes is built on one load-bearing assumption: replicas are fungible. Any pod can be killed, rescheduled onto another node, and replaced by an identical copy, because the state that matters lives somewhere else. That assumption is what makes bin-packing, rolling deploys, and horizontal autoscaling work at all.

An agent violates it. Kill an agent pod mid-task and you lose the conversation, the tool state, and the half-finished work. So teams reach for the escape hatches:

• StatefulSets, which buy stable identity at the price of ordered rollouts and operational ceremony designed for databases
• External state stores, which mean serializing agent memory to Redis or Postgres on every step and paying a rehydration tax on every wake
• Over-provisioned node pools, sized for peak load and idle the rest of the day

Then add the complexity tax: Deployments, Services, Ingress, ConfigMaps, PersistentVolumeClaims, resource requests and limits. All of it to run a process that wakes up 100 times a day. Teams end up spending more time on YAML than on the agent.

Serverless: Close but Fundamentally Wrong

Lambda looks right on paper. Pay per invocation, scale to zero, no servers. But a cold start is not one delay, it is a pipeline of them: pull the code, boot the interpreter, walk the import graph (a modern ML stack faults in hundreds of megabytes of shared objects before your first line runs), reopen every connection, reload every index. For an agent, that pipeline costs 10 to 30 seconds before the first token of useful work.

Then the rest of the model bites:

• The 15-minute execution cap. Research tasks, code generation, and multi-step workflows blow through it
• No persistent state. Every invocation starts from zero, so you bolt on DynamoDB or Redis to fake continuity, and now you are maintaining a state machine on top of a state machine
• Package and memory ceilings. Big dependency trees and model weights fight the 10 GB limit
• Per-millisecond pricing that punishes a workload which is mostly waiting on I/O

Serverless got the billing model right and the execution model wrong. Agents need both.

PaaS: Better DX, Same Physics

Heroku-style platforms fixed the developer experience: git push, TLS, logs, done. Underneath, you are still renting an always-on container, so the utilization math is unchanged. Sleep-capable tiers exist, but their "wake" is a full process restart: 10 to 30 seconds of boot with all in-memory state gone. And there are no agent primitives. Triggers, invocation billing, tool-call logging: you build all of that yourself, again.

What Agents Actually Need

Write down the actual runtime profile and the requirements fall out on their own:

1. Stateful sleep and wake. Suspend the full process state to disk when idle, restore it in about a second when a trigger fires. Not a cold boot. A resume, with memory, context, and connections intact

1. Event-driven activation. Webhooks, cron, API calls, messages. The agent should not exist between events

1. Elastic execution time. A task takes five seconds or five minutes. No artificial ceiling

1. Hard isolation. One agent per container or microVM, with its own volume, its own network, its own credentials. One compromised agent stays one compromised agent

1. Per-invocation billing. Pay for the 50 minutes, not the 1,440

1. Built-in observability. Every tool call, token count, and state transition logged by the platform, not by a sidecar you maintain

Agent-Native Infrastructure

This is the gap Maritime was built to close. When your agent goes idle, the platform checkpoints it. On our Firecracker hosts that means guest memory, vCPU registers, and device state serialized to local NVMe. When a trigger fires, the snapshot is mapped back and the vCPU resumes at the exact instruction it paused on. The agent does not know it was gone. We measured that resume at a median of 674 ms across a 62-hour continuous run.

maritime create my-agent --template openclaw
maritime deploy my-agent

One command gets you an endpoint, encrypted secrets, structured logs, and trigger wiring. The platform owns the lifecycle. You own the agent.

The Infrastructure Shift

Every computing paradigm eventually gets infrastructure shaped like it. Web apps got Heroku. Microservices got Kubernetes. Functions got Lambda. Agents are still running on hand-me-downs, and the teams shipping them pay the mismatch tax in both dollars and engineering time.

That is not a DevOps problem. It is a missing layer, and it is buildable. We built it.