An Agent That Survives a Closed Laptop

The laptop is the wrong place for an autonomous agent. What it took to move Sentinel to a Mac mini that never sleeps, keep the laptop's bigger model in the loop, and make an interrupted turn resumable.

A laptop is a client. It closes, sleeps, changes networks and runs out of battery, usually in the middle of the job you asked for. An agent that is supposed to work for hours has to live somewhere that does none of those things. For us that is a Mac mini on a shelf, and getting there taught us more about agents than about servers.

The turn belongs to the server

The first change is structural. In most chat apps the browser owns the request: close the tab and the server cancels the work. In Sentinel the server owns the turn. The browser subscribes to a stream of events; if it disconnects, the turn keeps running, every event is kept, and the next client to open the session replays what it missed. Closing the laptop no longer means anything to the agent.

Interrupted is a state, not a failure

Servers restart. When ours does, every session that was mid-turn is marked interrupted and the last unanswered tool call is kept. The session shows a Resume button. Resume settles that tool call (read-only calls are simply re-run), appends the result, and re-enters the loop with no new user message. The plan checklist, which lives in the session rather than in the model's head, tells the model where it was. The test for this forges an interrupted session on purpose and checks the agent finishes it.

The small machine, the big model

A 16-gigabyte mini runs an 8-billion-parameter model well and a 27-billion one not at all. The laptop runs the big one. So the mini treats the laptop as a remote model host over a private network: a token-gated proxy on the laptop forwards requests to its local model server, and the mini's model picker shows the big model as "awake" or "asleep" depending on whether the laptop answers. When the laptop is closed, the mini's own model does the work. When it is open, the big model is available to the always-on agent, without exposing the model server to anything but the proxy.

Process supervision, not scripts

Everything on the mini runs under a process manager with a saved process list, so a reboot brings it all back: the model server, the agent, its browser automation, and the tunnels. Two details cost us an afternoon each. A generic PORT variable in the environment was picked up by a child process that then bound the agent's own port. And the process manager does not read the project's environment file, so secrets had to be loaded by the application itself before any module imports them.

What the agent does at night

Being always on is only useful if something happens while you are away. The scheduler runs system jobs as plain coroutines, not as chat turns: a health check every ten minutes, a model keep-warm every four, a weekly memory consolidation, and a nightly review in which the agent reads its own ledger of the day's turns, failures and cures, and writes at most three lessons it will apply tomorrow. The first night it ran, its lessons were about its own retry policy. That is the behaviour we wanted from the box on the shelf.

Resources