Cloud agents

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.

The short answer

Cloud agents are AI workers that execute on a server rather than on your laptop, so work continues when your machine sleeps. Polaris runs one: a queue table called agent_jobs, a worker process on Fly.io that claims a job, compiles the worker identity, runs a tool loop with live web search, and posts the result as a comment on the task. Humans close the task, never the machine.

Pages in this cluster: 15
Queue table: agent_jobs
Runtime host: Fly.io, region sin
Software price: $0, billed per hour delivered

The ceiling every local agent hits

A terminal agent on your own machine is the best single-player tool most engineers have ever had. It reads your repository, runs your tests, uses your credentials, and iterates in the same second you think of something. Nothing in this cluster argues against that.

The ceiling is not intelligence. It is the process. The agent lives inside a session on one laptop, owned by one person. Close the lid and it stops mid-thought. Your colleague cannot see it, cannot assign it anything, and cannot review what it produced without you pasting the transcript somewhere. There is no roster, no queue, no record of who asked for what.

These fifteen pages are about moving that execution onto a machine that nobody has to keep awake, and putting a team around it: a shared list of workers, a queue with a contract, an append-only activity log, files with version history, and a rule that the machine never marks its own work finished.

The job lifecycle, end to end

Every page in this cluster refers back to these seven steps. They are the actual sequence in runtime/worker.mjs and the migrations behind it.

1
Assignment writes a row
A Postgres trigger on the tasks table fires when owner_id changes to a member whose kind is agent. It inserts one row into agent_jobs with status pending. A unique index allows only one live job per task, so double-assigning cannot spawn two machines on the same work.
2
A worker claims it
The runtime process polls every five seconds for the oldest pending job, then updates it to running with a WHERE clause that still requires status pending. If another process got there first the update returns nothing and this one moves on. The claim is the lock.
3
Identity gets compiled
The runtime reads the worker's own instructions, the full text of every SKILL.md-style playbook attached to that worker, the org's document tree, the task title, description, labels, bucket, checklist items and the last ten comments. Those become one system prompt and one task brief.
4
The tool loop runs
Up to ten rounds against the Anthropic Messages API, with server-side web search plus five tools the runtime implements itself: tick_checklist, post_progress, attach_file, create_doc and deliver. Every round's text and every search query is written to job_events, which the app streams live.
5
Acceptance criteria get ticked
The checklist on the task is handed to the worker as its acceptance criteria. Calling tick_checklist marks one item done and stamps the agent as its owner, so the box moves in everyone's browser through Realtime while the session is still running.
6
Delivery is a comment
The session ends when the worker calls deliver, which inserts a comment on the task authored by the agent's member row. Files land as real attachments in storage; written deliverables land as pages in Docs. The task status is set to in_progress, never done.
7
The bill is written next to the work
On success the job row stores human_minutes and the raw effort counters it was computed from: searches run, characters written, checklist items ticked, comments addressed, files produced. The estimate and its inputs sit on the same row, which is what makes a line on the invoice arguable.

Where the work lives in each model

Same agent quality in both columns. The difference is custody.

	Agent on your laptop	Agent on a Polaris machine
Runs while you sleep	No, the session dies with the process	Yes, the queue drains on the server
Who can assign it work	You	Anyone in the org, from the task
Where the output goes	Your terminal scrollback	A comment, a file, or a Docs page
Record of what happened	Shell history, if you kept it	activity_events plus a per-step job_events stream
Credentials	Your local environment	Org-wide, server-side, no read path to the browser
Repository and shell access	Full	None today, web search and writing only
Who marks the work finished	You, informally	A human closes and rates it, by design

What this cluster covers

Four questions, roughly, split across fifteen pages.

Getting execution off your machine
What actually keeps running when the laptop closes, what a queue contract guarantees, how long one session can last, and what happens when it fails halfway.
Putting a team around the agent
A shared roster where humans and agents sit in one members table, assignment that works identically for both, and an audit trail that answers who asked for this.
Configuring what the worker is
Skill files you can read and edit, org-wide tool credentials that the browser cannot read back, and instructions that compile into the prompt at job time.
Getting work back you can use
Deliverables as comments, attachments with version history, documents in the shared tree, and a review loop where commenting on the work wakes the worker again.

Every page in this cluster

Fourteen pages plus this one. Each stands on its own.

Running an AI agent in the cloud instead of on your laptop

Three approaches, one of which is ours, described precisely enough that you can tell which one you actually want.

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.

Turning a single-player agent into a team member

The change is not a better prompt. It is putting the worker in the same table as the people.

Sharing the agent, not the transcript

There are two different things people mean by sharing, and only one of them survives contact with a second person.

Queueing work at night and reading it in the morning

The realistic version of overnight work, including the part where there is no scheduler.

Running your AI workers from a phone

A terminal agent needs a terminal. A queued job needs a text field and a network.

Cloud agents versus local agents

Most teams end up running both. The useful question is which work belongs where.

Assigning a task to an AI worker

There is no prompt box. The task is the prompt, and the checklist is the contract.

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.

Skill files, and why a worker's capability should be readable

The difference between a prompt and a playbook is that one of them is a document your colleague can edit.

How an AI worker gets tool access

The interesting part of tool access is not the list. It is where the credential lives and who can read it.

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.

When the deliverable is a file

A chat reply is not a deliverable if the thing you needed was a document somebody can open.

Agents deliver, humans close

One rule holds the whole product together, and it is a rule about who is allowed to say finished.

Definitions, tool access, and the cost model behind the machine time.

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.

Headless agent

Nobody is typing at it, so its output is actions and artefacts rather than replies.

Human-in-the-loop

The system cannot complete the loop without a person, by design.

Web search in Polaris

Nothing to authorize, nothing to store, and every query a worker runs appears in the activity feed while it works.

What an AI worker costs, and how the hours are counted

The whole formula is on this page, including the parts that make it an estimate rather than a measurement.

Polaris for software teams

Nobody joined your team to write the release notes. Something still has to write them.

Questions people ask

+Is Polaris an official cloud version of Claude Code?

No. Claude Code is Anthropic's product and Polaris has no affiliation with Anthropic. Polaris is a separate workspace, built by superstack.digital, with its own agent runtime that calls the Anthropic API. Product names on this site belong to their respective owners and are used to describe compatibility of purpose, not partnership.

+Can a Polaris worker check out my repository and run my tests?

Not today. The runtime gives a worker live web search and five tools for posting progress, ticking acceptance criteria, attaching files, drafting documents and delivering. There is no shell, no git checkout and no test runner in the session. For repository work, a local coding agent remains the right tool and Polaris is the place the resulting task, review and record live.

+What happens if the runtime machine dies mid-job?

The job row stays in running with its claimed_at timestamp and an incremented attempts counter. Failures are caught and rewritten to pending for a retry while attempts is under two, then to error with the message stored on the row. Any work the model had already produced as comments, files or ticked checklist items is already committed to the database and survives.

+Do I need my own Anthropic API key?

An organisation can store its own key, which is written to a table with no select policy so it never travels back to a browser. The runtime looks up the org key first and falls back to the key configured on the machine. Owners and admins are the only members who can write it.

+How is any of this priced?

The software is free with no seats and no tiers. Billing is roughly two dollars per human-equivalent hour that a worker delivers, estimated by an open formula from observable effort and logged job by job. Nothing delivered means nothing billed.