How to Run an AI Agent 24/7: The Hosting Is the Easy Part

Every version of this question I have seen gets answered with a machine. Rent a small server. Buy a mini PC. Repurpose an old phone. Put it in a container. All of that is real advice and none of it is the hard part.

I have agents running unattended across roughly fourteen launched products. Five blog publishing routines fire on weekday schedules. A search-console sweep runs once a week across fourteen properties. None of those broke because I picked the wrong host. They broke because the laptop went to sleep, because the clock was in a different country than the schedule assumed, because a run finished cleanly and did absolutely nothing, and because a permission prompt sat there at three in the morning waiting for a human who was asleep.

So this is the version of the answer I actually needed: what "around the clock" means in practice, the four places an agent can live, and the five failures that show up only once nobody is watching.

What does it actually mean to run an AI agent 24/7?

Start here, because the phrase hides two very different things.

A continuous agent is a process that never exits. It sits in memory, watches something, and reacts. Chat agents, inbox watchers and monitoring agents work this way. The cost is that it is awake whether or not there is anything to do.

A scheduled agent wakes on a trigger, does one job, writes down what it did, and exits. Publishing, reporting, enrichment, outreach preparation and almost every back-office job work this way.

Most of what people describe as an always-on AI employee is the second kind. My publishing routines are not awake at four in the morning. They wake at noon, do one job, and stop. The blog still gets a post every weekday, which is the outcome anybody actually wanted.

This matters because the two shapes fail differently and cost differently. A continuous agent fails by drifting, leaking memory and quietly losing its connection. A scheduled agent fails by not firing, or by firing twice, or by firing into a state it does not recognise. Pick the shape that matches the job before you pick the box it runs in. If a job has a finish line, schedule it. Reach for a continuous process only when the trigger is genuinely an external event you cannot poll for cheaply.

Where can an AI agent actually run?

Four options, with the honest version of each tradeoff.

Your own machine on a scheduler

The scheduler already built into your operating system, pointed at a headless agent run. Zero hosting cost, your credentials are already there, and you can watch it work.

It also stops the moment the lid closes. Sleep, hibernate, a reboot after an update, a dropped connection, and a missed window is simply a missed window. This is where I started and where several of my routines still live, because the failure mode there is "a post is late", not "a customer is affected".

A cloud runner on a cron

Continuous integration schedules are close to free, versioned alongside your code, and they leave a log of every run. The agent can be invoked non-interactively straight from a workflow step. Anthropic's guide to running Claude Code programmatically covers the flags that matter here: the print flag for a single non-interactive turn, a permission mode so the run never stops to ask, structured JSON output so the next step can branch on the result, and a bare mode that skips locally installed hooks and plugins so the run behaves the same on every machine.

The catch is that a cron on a shared runner is a request, not a promise. GitHub's own reference on events that trigger workflows says the schedule event can be delayed during periods of high load, and names the start of every hour as one of those windows. It also says that in a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days. An agent whose only activity is its own commits can therefore switch itself off. I went deeper on that shape in running repos that update themselves on a schedule.

A small always-on server

A cheap virtual machine, or a mini PC in a drawer. This is the right answer for a genuinely continuous agent, and the only one of the four where you own the uptime end to end.

You also now own an operating system. Patches, a disk filling with logs, a runaway loop eating all the memory, and a set of API keys sitting on a box you will have forgotten about in four months. If you go here, set memory and disk limits before you set anything else.

A managed schedule next to your data

If the job is mostly database work, the scheduler can live with the database. Supabase runs scheduled jobs inside Postgres, which can call a database function or fire an HTTP request on a cron, with schedules ranging from every second to once a year. Their own guidance is to stay around 8 concurrent jobs and keep each one inside a ten minute window, which is a useful reminder that a scheduler is not a place to hide a long agent run. Trigger the work from there, then do the work somewhere with a longer leash.

The five things that break when nobody is watching

Hosting decided, here is what actually goes wrong. Every one of these has cost me a run.

1. The machine was asleep

The most common cause of a missed run is not a bug. Consumer machines sleep aggressively, and a schedule that fires while the machine is suspended does not politely queue itself for later by default. Before blaming the agent, check whether the scheduler is allowed to wake the machine, and whether it is allowed to run a missed job late. Those are two separate settings and both of them default against you.

2. The clock is not where you think it is

This one bit me hard enough that it became a written rule in my own setup: never trust a remembered timezone. I relocate. My machine has run on Bangkok time while my own notes and half my task files still said Singapore, and every session time I publish is quoted in Eastern. A schedule set to noon means noon in whatever zone the runner is in, which for a cloud runner is almost always UTC, and for your laptop is wherever you last landed.

The fix is boring and it works. Read the machine's zone before you convert anything, write the intended zone into the job itself rather than into your memory of it, and state the zone in any output a human will read.

3. The run has no idea what the last run did

An agent with no state file is not an employee, it is a goldfish. It will repeat yesterday's work, re-send yesterday's outreach, or write the same article twice in different words.

Every one of my unattended routines reads a state file first and appends to it last. The publishing routines read a topics log before choosing anything, and that single mechanism is the only thing preventing a duplicate post. Keep those files short. A state file that grows without a cap gets read in full on every run, so it quietly taxes every future run until somebody trims it.

4. A permission prompt with nobody in the room

An agent that asks before acting is correct, right up until it asks at three in the morning. Then the run has not failed, it is hung, which is worse, because nothing alerts on a process that is politely waiting.

The answer is to decide in advance which actions may run unattended and which get collected for a human, then set the run's permission mode to match so there is no third state where it waits. In practice that means the routine either holds explicit permission for the thing it needs, or it writes the thing into a queue for review and moves on. Nothing sends, publishes or spends without a rule that already existed before the run started. I walked through where I draw those lines in what to gate and what to let run unattended.

5. Silent success

The worst failure is the one that reports success. The schedule fires, the agent runs, the log says complete, and nothing happened. A source returned an empty list, a page structure changed, an interface quietly rate-limited the request, and the run handled all of it gracefully by doing nothing at all.

Nothing in the stack catches this for you, because from the outside it is indistinguishable from a quiet day. The only fix I have found is to make every run report a countable output rather than a status. Not "publishing complete" but "one post published, three internal links, hero image uploaded". When the number is zero, that reads as a problem instead of as a success. The rest of what I have learned about unattended failure modes is in what breaks when nobody is watching.

What does it cost to keep an AI agent running?

Two meters, and people usually budget for the wrong one.

The infrastructure meter is small and predictable. A small virtual machine is a few dollars a month. A scheduled cloud runner is often free at the volumes a solo operator hits. A machine you already own costs nothing extra at all.

The model meter is the one that matters, and it is driven by how often the agent wakes and how much context it drags in each time it does. A job that wakes hourly costs roughly twenty-four times what the same job costs daily, for work that is very often just as useful on the daily schedule. Before tuning anything else, ask whether the schedule genuinely needs to be that frequent, and trim what the run reads at startup.

That is also the honest argument against making everything continuous. An always-awake process bills you for the waiting.

Where I would start

Setting this up for the first time, in this order:

1. Decide whether the job has a finish line. If it does, schedule it and do not build a daemon.

2. Give it a state file before you give it a schedule.

3. Run it by hand five times and read the whole output every time.

4. Decide what it may do unattended, and set the permission mode so it never waits on a human.

5. Only then pick where it lives, starting with the machine you already own.

6. Make it report a number, and watch for that number going to zero.

Most people work this list backwards, starting at step five, and then discover steps two through four one incident at a time.

If you would rather have the install done for you

That is roughly what the Agent Ops Club exists for. Membership is $399 a month billed annually, so $4,788 for the year. It includes eight prebuilt agent employees covering GTM engineering, SEO, web development, social, ads, sales, customer satisfaction and chief of staff, a masterclass of 9 modules and 44 lessons on the operating model, a library of 22 systems with a resale license so you can deploy them for clients, one custom app built for you and owned outright, and monthly one on one time with me.

The part relevant to this article: the agent install and its hosting are done for you and covered for the first year, running around the clock on secure cloud infrastructure, so the schedule, the state file and the permission rules are set correctly the first time rather than after the first incident. There is also a first client guarantee. Land your first client within your first 90 days of joining, or I work with you one on one, at no extra cost, until you do.

If you would rather build it yourself, everything above is enough to do that. Both paths are fine.

Frequently asked questions

Do I need a server to run an AI agent 24/7?

No, and most people should not start with one. If the job has a finish line, a scheduler on a machine you already own gets you the same outcome with no host to maintain. You need an always-on server when the agent has to react to an external event within seconds, not when it has to produce something once a day.

Why does my scheduled agent skip runs?

In rough order of likelihood: the machine was asleep or powered off, the schedule is in a different timezone than you assumed, the previous run was still going and the scheduler refused to overlap them, or you are on a shared cloud runner where scheduled jobs get delayed under load. Check the wake setting and the run-if-missed setting first, because those are two separate switches and both tend to default to off.

How do I stop an agent from doing the same work twice?

Give it a state file that it reads before deciding anything and appends to after finishing. Then make the work itself repeatable where you can, so a double run is harmless rather than embarrassing. Keep the file short, because it gets read in full on every single run.

What happens if the agent hits a permission prompt overnight?

It stops and waits, and nothing tells you. Decide in advance which actions may run unattended, grant those explicitly, and route everything else into a review queue instead of into a prompt. A run that cannot ask is a run that cannot hang.

How much does it cost to run an agent around the clock?

The hosting is usually a few dollars a month, or free. The model usage is the real bill, and it scales with how often the agent wakes and how much context it loads each time. Halving the schedule frequency is almost always a bigger saving than changing anything about where it runs.

Can one person manage several agents running unattended?

Yes, as long as each one reports a countable result you can scan in under a minute. I run mine off a single morning read of what each routine produced overnight. The limit is not compute, it is how fast you can tell a real result from a quiet failure.

Come and see one running

I am covering this live on Saturday, September 5 at 10:00 AM Eastern, in Hire Your First AI Employee. It is a working session: installing an agent, giving it a job, putting it on a schedule and watching the first runs, including the parts that go wrong. If you are reading this after the date, the full replay is available instantly on that same page, so you can still watch the whole install start to finish.

The companion piece to this one, on what to hand an agent in its first week, is the onboarding nobody sells you. Read that one first if you have not hired anything yet. Come back to this one when you are ready to stop babysitting the runs.