AI Agent Hosting vs. AI App Hosting: Know What Must Stay Online

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

AI agent hosting keeps an autonomous worker available to receive tasks, use tools, and continue work. AI app hosting keeps the product that an agent or person built available to users. Many teams need app hosting first: the coding agent can stop after deployment, while the web process, database, domain, and recovery path remain online.

Ask one question before choosing infrastructure: what must keep working after the coding session closes? If users only need the application, host the application. If a worker must watch events and act without a person starting a session, you also need an agent runtime with its own limits and controls.

Host the app when users need a stable product

An application host runs a known revision behind an address. It supplies compute, health checks, runtime values, durable backing services, logs, and a rollback path. The coding agent may return for the next release, but it does not need to stay alive between requests.

This is the usual shape for an AI-built website, internal tool, API, or customer portal. You built an AI app. Now where does it run? lists the production decisions that a working local demo leaves open.

Host the agent when work must continue without a session

An agent runtime keeps a worker available to consume a queue, schedule work, call tools, and preserve task state. It needs limits on time, spend, retries, tool permissions, and concurrency. It also needs a clear owner for work the agent cannot finish or should not attempt.

Do not keep a coding agent online just to serve the application it wrote. That couples user traffic to a tool with broader repository and deployment access than the request needs. Package the product as an ordinary service, then give the agent a separate path to propose and release changes.

Some products need both, with a hard boundary

An application may accept a customer request while an agent handles the long-running work behind it. The public API should validate and store the request first. A queue can hand bounded jobs to the agent worker, and the worker should write results back through a narrow application or data interface.

Separate their credentials and failure policies. The web app needs customer-facing uptime; the agent needs task deadlines, retry limits, and a dead-letter path. You probably do not need a queue yet helps decide when that extra moving part has earned its place.

Size each runtime for its own failure mode

A web process usually waits for requests and must answer within a short deadline. An agent worker may hold a larger context, run tools, and spend minutes on one job. Combining them in one process makes memory spikes, deploys, and retries affect both customer traffic and background work.

Measure them separately. How much server does your app actually need? explains why memory is a wall while CPU is a queue. An agent loop adds another limit: task cost and elapsed time.

A hosting decision card

Fill one card for every process you expect to keep online.

HOSTING DECISION CARD
Process name:
Who or what sends it work?
Must it run after the coding session closes? yes / no
Does it serve a public request or consume a background job?
Maximum acceptable response or task time:
State that must survive a restart:
Repository and release owner:
Credentials and tools this process may use:
Health signal and failure destination:
Retry limit, stop rule, and human owner:
Can this process fail without taking user traffic down? yes / no

FAQ

Is an AI-built app the same as an AI agent? No. An AI-built app is ordinary software whose code came from an AI-assisted workflow. An agent is a running worker that chooses actions and uses tools. The app can run without the coding agent that created it.

When do I need AI agent hosting? You need it when an agent must receive work and act after every interactive session has ended. Scheduled research, queue consumers, and monitored automation fit that shape. A website or API that only runs generated code usually needs app hosting instead.

Can one container run the app and the agent? It can, but the shared failure boundary is costly. A long agent task can exhaust memory or delay requests, and an app release can interrupt unfinished work. Separate them once both workloads matter and exchange bounded jobs through a durable interface.

Which kind of hosting is aidrop.it? aidrop.it hosts applications and backing services while a coding agent controls deployments over MCP. It does not keep Claude Code or Codex running for you. The agent may end its session after the application reaches its public address.