Autonomous agents
Where an autonomous agent actually lives
Choosing a framework is the interesting question and the smaller one. An agent that runs unattended is a process that has to survive the night: a laptop that sleeps, a function that times out, a token that expires at three in the morning, a tool that starts returning errors while nobody is watching. This page is about that, with numbers from an install of our own that has been running since May.
2,688
Times a watchdog restarted the gateway on one of our installs between 18 May and 2026-09-20, which is 126 days and about 21.3 restarts a day. In the same log there are 21,955 healthy checks and 3,971 stretches where the process was alive and had stopped making progress. Everyone involved would describe that install as working fine, and it is working fine, because something is watching it. Take the watchdog away and it stops twenty one times a day instead.
The four places people run agents, and what breaks in each
The laptop you develop on
It sleeps. A closed lid stops the loop mid task, the wake up does not resume it, and the run you started before dinner is a half finished task and a burnt context in the morning.
Right choice when: Writing the agent. Every agent should start here, and most should be moved off here the day they start running unattended.
A serverless function
It has a wall clock limit, usually minutes. An agent loop that waits on a slow tool call dies at the timeout with no state, and retry storms turn one stuck task into a bill.
Right choice when: A single short step triggered by an event. If the work is one model call and one write, this is the cheapest correct answer.
A Linux VPS
Nothing, for most agents. It is the right default. What it cannot do is run macOS, drive a Mac app, build for Apple platforms, or hold a large model in unified memory: a cheap VPS has no GPU at all, and a GPU instance costs more per month than a Mac.
Right choice when: Almost everything. If the agent only calls an API and writes to a database, rent a VPS and stop reading.
A dedicated Mac
Nothing that a supervisor does not fix, but it is the expensive answer unless you need what only it has. Rented, it also means trusting someone else with the machine your agent lives on.
Right choice when: Three cases: the agent needs a local model in unified memory rather than an API, it has to drive macOS or build for Apple platforms, or the token bill on a hosted model has grown past the rent.
We rent Macs, so read the last row with that in mind. For most agents the VPS row is the correct answer and we would rather write that down than sell you a machine you do not need.
What the frameworks do when things go wrong
Same task for each: call a tool until a counter reaches three, then stop. Same mock endpoint, same step limit of twelve. The endpoint can be told to return 500, return 429, or reply with something that is not JSON, and the tool can be told to fail every time. No paid keys are involved, so you can run the same thing yourself: the harness is in agent-uptime-kit. Versions and figures from 2026-09-20.
| What happens | LangGraph 1.2.11 | OpenAI Agents SDK 0.22.3 | CrewAI 1.15.22 |
|---|---|---|---|
| Nothing wrong | done in 4 model calls | done in 4 model calls | done in 4 model calls |
| The tool fails every time | Stops on the first failure. One model call spent, nothing burnt. | Keeps going to the step cap. Twelve model calls for nothing, every time the backend is down. | Thirteen model calls, then a validation error. |
| The endpoint returns 500 or 429 | Dies after the client's own retries on both 500 and 429. Without a wrapper the process exits. | Dies after the client's own retries on both 500 and 429. | Rides out three 500s and three 429s and finishes the task. Litellm underneath retries. |
| The reply is not valid JSON | Dies on the first unparseable reply. | Dies on the first unparseable reply. | Recovers and finishes. |
| State survives the process dying | Yes. A sqlite checkpointer and a thread id, one line each. | Yes. SQLiteSession and a session id, one line each. | Partly. Memory is optional and pulls in an embedding model, which is another dependency and another key. |
| Prompt tokens for identical work | 428 | 472 | 802 |
| Step cap | recursion_limit | max_turns | max_iter |
The useful part is that toughness inverts. Against a flaky endpoint CrewAI is the survivor of the three, because litellm retries underneath it, while the other two let the exception out and your process exits. Against a tool that keeps failing it reverses: LangGraph stops after one model call, the Agents SDK spends all twelve. Neither behaviour is wrong, and both are worth knowing before you leave the thing running.
None of the three restarts itself, and none of them notices that it has stopped making progress. That is not a criticism: they are libraries for writing a loop, not supervisors. It just means the part that keeps the agent alive is a part you have to supply.
The parts that keep it alive
In order of how often their absence has cost us something. Templates for all of these are in the kit, MIT licensed.
- 1
Start at boot, restart on exit
KeepAlive and RunAtLoad in a launchd job, Restart=always in a systemd unit. This is the easy half, and it is the half every guide covers.
- 2
Restart on lack of progress, not lack of pulse
The failure that costs you a night is the one where the process is alive, the port answers and nothing has moved for an hour. Have the agent touch a file when it finishes a unit of work, and have something else restart it when that file goes stale.
- 3
Put a cooldown on the restart
Without one, an agent that cannot start restarts in a loop for eight hours and fills the disk with logs of itself failing.
- 4
Cap the spend, not just the steps
Every framework has a step limit and a step limit is not a budget. Twelve steps on a small model is free, twelve steps on a large one with a long context is real money, and a loop that runs all night is both.
- 5
Rotate the logs before the disk decides for you
Our install wrote 392 MB across 235 files in four months. That is fine until the day it is not, and the day it is not, the agent stops for a reason that has nothing to do with agents.
- 6
Watch the memory store, not just the process
The process holding steady says nothing about the vector store next to it. Ours is at 2.9 GB and grows with every conversation it decides to keep.
- 7
Know what happens when the key expires
An expired token looks exactly like a broken tool from inside the loop. Whichever framework you picked, the behaviour above is what you get: one of them stops, one of them spends your budget finding out.
What a real install looks like after four months
The same machine the watchdog numbers come from, on an ordinary day. Counters only: nothing here says what the agent does.
| Scheduled jobs enabled | 71 |
| Scheduled jobs disabled and left in place | 91 |
| Jobs whose last run exited non zero, right now | 4 of 67 |
| Vector memory on disk | 2.9 GB |
| Logs on disk | 392 MB across 235 files, oldest 2026-05-02 |
Two things in that table are worth sitting with. More than half the scheduled jobs are switched off rather than deleted, which is what an install looks like after you have tried things. And four jobs are failing right now, on a system nobody is worried about. An agent setup that has been alive for months is never entirely green, and planning for one that is will leave you without the alarms that matter.
When the model should live on the same machine
A loop that wakes every five minutes makes roughly 288 model calls a day doing nothing in particular, and a framework that retries a dead tool to its step cap multiplies that. At some point the token bill passes what a machine costs, and at that point a local model on a machine that never sleeps is the cheaper answer as well as the private one. Whether the model you want actually fits, and how fast it will generate, is arithmetic rather than opinion: our calculator does it for any Apple Silicon chip, and the same formula applied to NVIDIA and AMD shows where a Mac is the wrong purchase.
Questions people ask
How often does an unattended agent actually need restarting?
On our own install, twenty one times a day. The watchdog log covers 126 days and records 2,688 restarts against 21,955 healthy checks. Nobody involved would describe that install as broken, and it is not: restarts take seconds and no human sees them. It is only working because something is watching it.
Do any of the agent frameworks survive a reboot on their own?
No. Not LangGraph, not the OpenAI Agents SDK, not CrewAI. They are libraries for writing a loop, not supervisors. Starting at boot and restarting on exit is launchd on macOS or systemd on Linux, and restarting on lack of progress is a job you write yourself, which is why we published ours.
Which framework is the most robust for unattended work?
It depends on which failure you expect, and the answer inverts. Against transport failures CrewAI is the toughest of the three, because litellm retries underneath it, while LangGraph and the Agents SDK let the exception out and the process exits. Against a tool that keeps failing it is the other way round: LangGraph stops on the first error and spends one model call, while the Agents SDK spends its entire step budget getting nowhere.
Is a Mac the right place to run an agent?
Usually not. If the agent only calls an API and writes to a database, a Linux VPS is cheaper and simpler and we would rather say so than sell you the wrong machine. A Mac earns its rent in three cases: the agent needs a local model in unified memory instead of a hosted one, it has to drive macOS or build for Apple platforms, or the token bill has grown past what a machine costs.
What does it cost to keep an agent running all day?
The machine is the predictable part and the tokens are not. A loop that wakes every five minutes makes about 288 model calls a day even when nothing happens, and a framework that retries a dead tool to its step cap multiplies that by the cap. That is why the budget belongs in front of the model rather than inside the agent, where the agent can talk its way past it.
If the machine is the part you are missing
We rent dedicated Apple Silicon machines that do not sleep, with root access and a fixed monthly price. If your agent needs a local model, macOS itself, or simply a host that is still awake at four in the morning, that is what we are for. If it does not, the kit above works just as well on a ten dollar VPS.