Scheduled work
A report every Monday, a stock check every hour. A schedule needs a process awake at the moment it fires. Nothing queues a missed one for later.
Comparison
The short verdict: running an agent on your own machine is a genuinely good way to start, and for a single technical person it may be the whole answer. What it is not is a service. A laptop is a session - it exists while you are there - and almost everything people actually want from an agent is a service property: work that fires on a schedule, a message answered at 3am, a connector that renews its own authorisation, a task that survives you closing the lid. This page is about where that line falls, what moving to a server fixes, and the part it does not fix.
They fail independently, which is why "is it running?" is the wrong question.
A report every Monday, a stock check every hour. A schedule needs a process awake at the moment it fires. Nothing queues a missed one for later.
"Tell me if a customer mentions a refund." Something has to be reading, on an interval, for that to mean anything.
A customer writes on WhatsApp at midnight. If nothing is listening, the message is not lost - but nobody answers until you wake the machine.
Reading a folder of documents takes longer than your attention span. Suspend the machine halfway and the work is cut off, not paused.
OAuth grants expire on their own schedule. Renewal has to happen ahead of expiry, whether or not anyone is at the keyboard.
Precision matters here, because the honest list is shorter than the marketing version and more convincing for it. When a machine suspends, the agent process stops. It does not crash, lose data or corrupt anything - it simply is not running, and four consequences follow.
Schedules do not fire, and they are not replayed. This is the one that surprises people. A missed 9am run is missed; when the laptop wakes at 11 there is no catch-up queue, because a scheduler fires on a clock rather than working through a backlog.
Standing instructions go unpolled. Anything checked on an interval simply is not checked, and the gap is invisible afterwards.
Background work is interrupted mid-task. Not resumed on wake - interrupted.
Connector authorisations can lapse. This is the subtle one and the one that generates the most confused support requests. Grants are renewed ahead of expiry. A machine that is asleep through the renewal window can wake up to a connection that now needs a human to re-authorise it, which reads as "the integration randomly broke" rather than "the computer was off".
What sleep does not damage is your data. Conversations, memory and files are all still there. The failure is availability, not integrity, and it is worth saying that plainly because the opposite fear is common and wrong.
The standard advice in every self-hosting community is to stop using a laptop and rent a small server, and that advice is correct. A few dollars a month buys a machine that does not sleep, a stable address, and a process that restarts itself after a reboot. If the only question you have is "will it stay up", a VPS answers it and you do not need a vendor.
We would rather say that first than build an argument on a problem the open-source world already solved. The interesting question is the next one.
Once the machine stays up, you are running a service. The agent holds live connections to platforms that change their rules, tokens that expire on their own timetable, and a model provider that occasionally deprecates something. None of it is difficult. All of it is unscheduled, and it lands on whoever set the thing up - at the least convenient moment, while they are on leave, and after they have left the company.
For a personal assistant that is a fair trade: if it is down for a day, you noticed, and you fixed it. For an agent answering customers the failure is silent, and the customer is the one who discovers it.
One honest correction to a claim vendors like to make: hosting is not more private than self-hosting. An agent on hardware you own, talking only to a model provider you chose, is the stronger privacy position, and if sovereignty is your priority you should take it.
What a hosted deployment offers instead is isolation - your own deployment rather than a shared tenancy, in a region you pick, with credentials resolved per agent from an encrypted vault rather than one process holding every login. And for the cases where nothing may leave the building at all, open models can run on your own GPU, which is the self-hosting answer arriving from the other direction.
The dimensions that decide it - not model benchmarks.
| Dimension | On your own machine | Hosted deployment |
|---|---|---|
| Staying up | As available as the machine. On a laptop, that means office hours; on a rented server, genuinely 24/7. | The runtime boots agents, channels, scheduler and the improvement loop as one long-running service. |
| Surviving a dropped connection | The process is the session. Close the terminal or the tab and whatever it was doing stops. | A turn is detached from the connection that started it. Lock your phone mid-task and you are replayed exactly what you missed when you return. |
| Who is on call | You. Updates, expired tokens, a channel that changed its rules, a dependency to patch. | Provisioning, updates, connection health and reconnection are the product. |
| Several colleagues | One operator, one set of keys. Sharing means sharing a login. | Owners, admins and members on the same agents, with per-person control over which agents each can see. Unlimited people on every plan. |
| Approvals and audit | Whatever you configure, plus reading logs afterwards. | Trust levels 0-4 per agent and per category; outbound sends and financial actions wait for a human; every action lands in an append-only audit trail. |
| Privacy posture | Strongest available. Nothing reaches a vendor except your chosen model provider. | Isolation rather than secrecy: your own deployment, your region, per-agent credentials - or open models on your own GPU. |
| Cost shape | Software often free; a small server is a few dollars a month; model tokens on top. Your time is the uncosted line. | Managed plans from $10/month with unlimited agents, people and connections. Bring your own model keys at no surcharge. |
Four situations where running it yourself is the right answer and a managed plan would be buying something you never use.
One person, one server, one set of keys. Team access, approval gates and per-customer isolation are all describing a problem you do not have.
On hardware you own, nothing reaches a vendor except the model provider you picked. No managed service can beat that, ours included.
The cheapest way to learn which workflows actually matter is to run one for a few months. That knowledge transfers; a subscription started too early does not.
Plenty of operators genuinely enjoy this and get better results than any vendor would, because they know their own work.
Four situations where the session-versus-service line has already been crossed.
The moment someone outside your company can message the agent, downtime stops being your inconvenience and becomes their experience of your business.
If the honest answer to "who fixes it at 2am" is "nobody, we would notice on Monday", that is a decision about customers, made by accident.
Two colleagues at different depths of access is not something a single-operator setup expresses, and a shared password is not an answer.
Continuity comes from where the state lives. When the deployment owns the thread, every device is a window onto the same agent - including WhatsApp and Telegram.
Most people should start local and move when a specific thing breaks. The trigger is rarely a feature; it is usually a moment. A schedule that mattered did not run. A customer messaged overnight. A colleague asked for access and there was no way to give them a partial one. When one of those happens, the shape of the problem has changed, and that is worth acting on rather than working around.
It is also worth knowing that this is not a one-way door. Olano can be self-hosted on your own infrastructure, so "managed or not" stays a choice you can revisit rather than a purchase that locks the answer in.
No. The agent is a process, and suspending the machine stops it. Scheduled work does not fire and is not replayed on wake, standing instructions go unpolled, background tasks are interrupted mid-task, and a connector grant due for renewal during the sleep can wake up needing manual re-authorisation. Your data is unaffected - the failure is availability, not integrity.
You can, and for a while people do. The practical problems are that laptops sleep on their own, move between networks in ways that break inbound endpoints, and get closed and carried home. A small rented server removes all three for a few dollars a month, which is why every self-hosting community recommends one.
On the raw question of what leaves your building, yes - a local agent on hardware you own is the stronger position, and we are not going to pretend otherwise. A hosted deployment answers with isolation instead: your own deployment rather than a shared tenancy, in a region you choose, with credentials resolved per agent. Where nothing may leave at all, open models can run on your own GPU.
Not to try them, and not for personal use on a machine you keep awake. You need one the moment the agent has obligations that outlive your attention - a schedule that matters, a channel customers use, or work that runs longer than you sit at the desk.
Often smaller than people expect, and not always in the direction you would guess. Self-hosting is software you do not pay for, a small server, and model tokens; managed plans start at $10/month with unlimited agents and people. The line that never appears on either invoice is your time, and that is usually what decides it.
Where to go next.
The same argument against the best-known self-hosted harness, in full.
The diagnostic version, for when something already failed overnight.
The buyer's checklist, including the four honest limits.
What a managed deployment costs, and why it is priced per deployment.
Checked 13 September 2026. Self-hosting practice moves quickly and the costs quoted for running your own server are order-of-magnitude figures from widely published community guides, not offers. If we have described something wrongly, write to support@olano.ai and we will correct this page.
If one workflow is the reason you are reading this, tell us which one. We will say plainly whether it needs a managed deployment or a ten-dollar server and an afternoon.