Cloud agents
What keeps running after you close the lid
The honest version: nothing on your laptop survives, so the work has to not be on your laptop.
The short answer
An AI agent running in a terminal stops when the process stops, and closing a laptop stops the process. Work only continues if execution lives elsewhere. In Polaris the task, the queue row and the runtime process are all server-side, so a job that was claimed before you shut the lid keeps running and posts its comment, its files and its ticked checklist items whether or not any browser is open.
- What survives locally
- Nothing
- Poll interval
- 5 seconds
- Retries per job
- Up to 2 attempts
Two failure stories
Same task, same model, different place of execution.
Local session, lid closes
- The process is suspended or killed with the session
- Partial output exists only in scrollback
- Nothing was written anywhere a colleague can reach
- Restarting means re-establishing the whole context by hand
- Nobody else knew the work was in flight
Queued job, lid closes
- The claimed row keeps running on the Fly machine
- Progress comments and ticked items are already in Postgres
- Attachments are already in storage with a version number
- Realtime replays the state to any browser that opens later
- The activity feed shows who assigned it and when
Why the browser is not part of the machinery
The Polaris frontend is a static export talking to Postgres directly, with row-level security deciding what each member can read. It subscribes to changes on tasks, comments, jobs and the per-step event stream. It is a viewer.
The runtime is a separate long-lived process on Fly.io holding a service-role key. It never talks to a browser. It reads its next job from the same database the app reads, does the work, and writes the results back. Close every tab in your company and the loop continues, because no step in it needs a client.
What happens to a job while you are asleep
- 1
Claimed work finishes
A job already flipped to running continues through its rounds until it calls deliver or hits the eight-minute deadline. Comments, ticks, docs and files are written as they happen, not at the end.
- 2
Queued work waits its turn
Pending rows sit in created_at order. The runtime takes the oldest each cycle, so a backlog assigned at midnight drains one job at a time rather than all at once.
- 3
A failure retries itself
An exception writes an error event, then sets the row back to pending if it has been attempted fewer than twice. The third failure parks it in error with the message stored on the row.
- 4
Nothing gets closed
The machine sets the task to in_progress and stops there. A delivered task is waiting for you in the morning, not silently marked done.
What still stops when you stop
Anything you queued but never assigned
Work starts on assignment. A task sitting in a bucket with no owner sits there all night.
A worker waiting on a question
Workers are instructed to deliver a clear statement of what they need rather than guess. That delivery is a comment you answer in the morning, which then wakes the worker again.
Anything needing a credential nobody added
Connections are authorised once, org-wide, by an owner or admin. A missing credential is not something a machine can resolve at three in the morning.
Related reading
Queueing work at night and reading it in the morning
The realistic version of overnight work, including the part where there is no scheduler.
How long an agent session can run, and what happens when it ends
Every agent runtime has bounds. The useful thing a vendor can do is tell you what they are.
Running your AI workers from a phone
A terminal agent needs a terminal. A queued job needs a text field and a network.
Agent runtime
Not the model, not the framework: the thing that actually runs the job.
Task queue
The thing that lets a request survive the process that made it.
Questions people ask
+Does my browser need to stay open for the agent to keep working?
No. The runtime is a server process holding its own database credential, and it never communicates with a browser. The app subscribes to the same tables to display what is happening, so closing it changes the view and nothing else.
+What if the job was mid-search when I closed the lid?
Web search runs server-side as part of the model call, so it was never happening on your machine in the first place. The session continues through its remaining rounds on the Fly machine.
+Is partial work lost when a job fails?
No. Progress comments, ticked checklist items, drafted documents and uploaded files are each committed to Postgres or storage the moment the tool call succeeds. A failure later in the session leaves all of that intact and adds an error event describing what went wrong.
+Can I see what happened while I was away?
Yes. Every session writes an ordered event stream with kinds such as session, thought, search, tool, progress, delivered, error and done. Opening the task later replays the stream in sequence alongside the comments and files it produced.
Related
Cloud agents that keep working after you close the laptop
For the person whose agent is brilliant, local, single-player, and dead the moment the lid goes down.
Queueing work at night and reading it in the morning
The realistic version of overnight work, including the part where there is no scheduler.
How long an agent session can run, and what happens when it ends
Every agent runtime has bounds. The useful thing a vendor can do is tell you what they are.
The audit trail behind every agent session
If you cannot reconstruct what happened three weeks later, you do not have an audit trail. You have a feeling.
Running your AI workers from a phone
A terminal agent needs a terminal. A queued job needs a text field and a network.
Headless agent
Nobody is typing at it, so its output is actions and artefacts rather than replies.
Agent runtime
Not the model, not the framework: the thing that actually runs the job.