AI agent hosting

  • Long-running processes, queues and schedules
  • Root access, so the runtime is your choice
  • A record of what it did and what it spent

An agent is a process that runs when nobody is watching

A website waits to be asked. An agent wakes on a schedule or a webhook, calls a model and two or three of your systems, retries the one that timed out, writes down what it decided and goes back to sleep. That is a different hosting problem from serving pages, and it is the one most agents get deployed onto the wrong thing for.

Tell us what your agent does How we build agents
Requirements

What an agent needs that a website does not

Four things, and shared hosting gets none of them right.

What the server has to provide

A process that stays up

Agents are not request-and-response. Something has to keep the loop alive between triggers, restart it when it dies, and not reap it for sitting idle while it waits on an API. Shared hosting kills long-running processes by design, which is why so many agents are still "working on my laptop" six weeks in.

Somewhere to keep state

An agent that cannot remember the last run repeats it. What it has already processed, what it tried and failed, the conversation so far - that is a database and a disk, not a variable. It has to survive a restart, because a restart is exactly when you need to know what it was in the middle of.

Outbound calls, and the keys for them

Every run reaches a model provider and whatever tools you gave it. That needs stable outbound networking, somewhere to keep API keys that is not the repository, and a retry policy: rate limits and timeouts are normal operation for an agent, not an incident.

A record of what it decided

An agent chooses. When somebody asks why it refunded that order, "the model decided" is not an answer. The run log - trigger, inputs, which tools it called, what came back, what it spent - is the difference between a system you can operate and one you quietly switch off.

Straight answers

Where agent hosting goes wrong

Four failures, said plainly, because three of them are cheaper to prevent than to find.

What actually breaks

It was put on shared hosting

Shared hosting is tuned for short requests: background workers are not permitted, processes are reaped, and cron is capped at a few runs an hour. An agent on it tests fine and then silently stops running overnight, which reads as a bug in the agent and is not one. It is the most common failure here and it is a hosting choice, made before anybody wrote a line of the thing.

Nobody capped the spend

A retry loop against a model API bills on every attempt. An agent that meets one malformed input and retries forever can cost real money by morning, and nothing about that looks like an outage - the server is healthy and the logs are full. A budget cap and an alert on spend per run are a day of work at the start, and the reason the bill never surprises you.

The keys were in the repository

Provider keys, a CRM token, a database password. They get committed because it was the fastest way to make the agent run, and then the repository is shared with a contractor or pushed to a host nobody audited. Keys belong in the environment, rotated on a schedule, with the agent holding the narrowest permission that still lets it do the job - which usually turns out to be much narrower than the one it was given.

It outlived the person who built it

Six months on, the provider has moved a model version, a tool API has changed its response shape, and the one person who understood the prompt has left. An agent is not a thing you install and leave: somebody has to read what it got wrong and update what it knows. If that is not going to be anybody, the honest advice is not to run one, and we would rather say so now than invoice for it later.

Questions

AI agent hosting: common questions

Not reliably. Shared hosting reaps long-running processes, does not permit background workers and caps how often cron fires, so an agent that works while you are watching it stops when you are not. An agent wants a cloud server or VPS with root access, where you control the process manager.

Smaller than most people expect, as long as the model runs at a provider - the agent spends nearly all its time waiting on network calls, so it is steady uptime and RAM rather than CPU. Running the model yourself is a completely different question and it is GPU territory. Tell us which of the two you mean and we will size it.

Usually only the agent, with the model called at a provider, because that is what most builds need and it keeps the server small and cheap to run. Self-hosting an open-weight model is possible on the right hardware, and we will say plainly whether your use case justifies the difference.

Yes. We will want to see how it starts, what it expects in the environment and what it talks to. If it has no deployment story at all - it runs from a developer's terminal - then giving it one is the first piece of work, and it is usually a short one.

A log per run: what triggered it, what it called, what came back, what it spent. Where the agent records its own reasoning we keep that too. This gets set up at deployment rather than added after the first argument about something it did, because reconstructing a decision you did not log is not possible.

The agent should fail visibly - stop, log it, tell somebody - rather than retry in silence or carry on with half an answer. Which of those it does is a design decision, and it is worth making before the outage rather than during one.
Where to next

Related work

What runs on it, and what it runs on.

Get started

Tell us what the agent does

What triggers it, what it touches and how often it runs. That is enough for us to say what it needs and what keeping it up will cost.

Tell us what your agent does