Long-running AI agents behave differently from regular web workloads, and the platforms built for regular web workloads show that the first time you deploy one. A single agent turn can take minutes rather than milliseconds, connections stay open while a tool call decides its next step, in-process state builds up across a session, and the whole thing runs better on a warm process than on one that just cold-started to answer a single question.

This post covers what changes when your workload is an agent rather than an API endpoint, what a platform needs to run that workload well, and how it fits together on Suga.

What "long-running" actually means for an agent

A single user turn on an agent can trigger a chain of model calls, tool invocations, retries, and structured output parsing that adds up to minutes rather than milliseconds. Between those steps the process holds state that would be expensive to recompute: the running conversation, memoised tool results, an open connection to a vector store, and whatever middleware you've added for tracing. Most modern web frameworks and hosts expect your code to behave differently from that, and the mismatch shows up the first time you deploy.

The workload is the opposite of what serverless was designed for. Serverless assumes stateless request handlers that finish in a few hundred milliseconds and get discarded once they return. An agent turn takes minutes, keeps state around, and is much cheaper to serve from a warm process than to rebuild from cold every time.

Platforms that scale to zero between requests hurt an agent in three specific ways. First, the cold start on the next turn drops the entire in-memory conversation, forcing a rehydration from persistent storage that defeats the point of keeping state in memory. Second, tool calls that outlive the platform's per-request ceiling get killed mid-stream, which for LLM providers means losing a response you're already paying for. Third, streaming a response over SSE or WebSockets needs a connection that stays open longer than the platform's idle timeout, and a wrong timeout drops the user mid-answer.

What you actually need from a host

Once you treat an agent as a resident process rather than an API endpoint, here's what you need from the host.

Always-on containers. A warm process holds your state across turns, so you don't cold-start every time a user finishes typing.

Long request lifetimes, or a stream idle timeout that's forgiving enough for real tool calls. A single call to a frontier model can take a minute or more, and a chain of tool calls stacks on top. Anything under a few minutes runs out mid-turn.

Streaming that stays open. Server-sent events and WebSockets both break when a load balancer or edge proxy decides the connection has been idle "too long". You want an idle timeout you can design around, and one you can look up ahead of time.

Persistent storage that survives redeploys. Agents accumulate three kinds of state that all benefit from persistence: conversation history for later reload, tool result caches to save downstream calls, and long-lived embeddings if you're doing retrieval.

Private networking between services. A production agent usually runs alongside a vector store, a Postgres for conversation history, and maybe a queue for background jobs. Each of those services should be reachable by hostname on a private network, kept off the public internet.

Secrets injected at runtime. Model provider API keys, tool credentials, and downstream service secrets go in at runtime, not baked into the build.

A pricing model that matches an always-warm process. Per-invocation pricing is punishing for agents, since a workload that spends most of its wall-clock time waiting on model calls still gets billed for the whole duration.

Deployments that keep live sessions alive. Rolling deploys, graceful shutdown windows, and predictable connection draining matter more when a request lasts minutes than when it lasts a hundred milliseconds.

How this sits together on Suga

Suga runs each service as a resident, always-on container that stays warm across turns. There's no scale-to-zero to work around.

Pro and Enterprise have no total-request cap on the container itself. The Cloudflare edge in front of a service has its own five-minute idle timeout for streaming connections, which covers a typical model call plus tool chain and fits an agent that emits tokens continuously while it works. For a step that sits silent for longer than five minutes, heartbeat the stream, or move the long-idle portion into a background worker container that reports back when it's done.

Storage lives on a persistent volume per container, mounted at whatever path you want. In practice this is where you park SQLite for a small agent, checkpoint files for a bigger one, or a local vector index if that's simpler than running a separate vector store. For anything you'd rather run as a proper service, Suga has container templates for Postgres, Redis, and MariaDB with volumes pre-attached, and you can deploy any other database as a container with a volume attached the same way.

Private networking is default-deny per environment. The vector store, database, and queue your agent talks to sit inside the same environment on a private network, addressable by hostname, and stay private unless you explicitly expose one. Cross-container references let you pull a downstream service's connection string into your agent's environment without duplicating the value.

Secrets are per-container and marked sensitive. Once set from the dashboard or the MCP, the value is write-only, and referenced back into the environment at runtime.

Every deploy captures a commit message and the full environment definition, so you can roll back to any previous state with a single click. Forking an environment clones the services, images, resource allocations, volume definitions, and networking wiring into a new one — useful for testing an agent change against an exact copy of production. Volumes come up empty in the fork, so if you want the agent's persisted state (conversation history, embeddings, checkpoint files) to come along, seed them from a backup after.

At the edge, every service sits behind Cloudflare's global network by default, so L3/L4/L7 DDoS protection and TLS termination apply to every agent endpoint without any per-service configuration. That matters more for agents than for regular APIs, since agent endpoints tend to attract adversarial traffic (rate-limit probing, prompt-injection sweeps, tool-abuse attempts) that is much easier to shed at the edge than inside your application.

Pricing is per-seat with hosting credits bundled into each Pro seat, and workloads are metered on compute and storage rather than per-invocation. For an always-warm agent process this tends to be significantly more predictable than a serverless bill, since the wall-clock time your agent spends waiting on model calls is priced the same as time it spends serving requests.

A quick recipe for deploying one

Push your agent as a container to a Suga environment, where auto-detected source builds handle the image so there's no Dockerfile in your repo unless you actively want one, then add a persistent volume mounted where your agent writes its state and stand up whichever data services you need (Postgres for conversation history, Redis for tool result caching, and any other database as a container with a volume attached) as sibling containers on the private network. Set your model provider keys and any tool credentials as sensitive environment variables on the agent container, and reference them from the code the same way you would locally.

For the streaming path, keep your response chunks flowing so the edge sees regular activity inside its five-minute idle window. If a step genuinely takes longer to think, either emit a keepalive event or push the long-idle portion onto a background worker container that reports back over the private network. For debugging, Suga surfaces per-container logs and resource metrics in the dashboard, and for anything deeper you can layer your own APM on top since the container is a normal Node, Python, or Go process from your side.

If you'd rather drive the deployment from an agent instead of clicking through it, the Suga MCP server exposes the same primitives to whichever coding agent you're using, so create_environment, add_container, add_volume, set_secret, and connect_build_repository are enough to stand up an agent workload from a conversation.

Where to start

If you want to try this yourself, sign up for Suga and use the quickstart as a starting point. If you're evaluating a specific agent workload and want another pair of eyes on how to lay it out, reach out and we're happy to walk through it.