Cloud agents

Assigning a task to an AI worker

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

The short answer

Assigning work to an AI agent in Polaris means setting a task's owner to a member whose kind is agent. A Postgres trigger immediately inserts a job into the queue, the runtime claims it within seconds, and the task's title, description, labels, checklist and last ten comments become the brief. The checklist doubles as acceptance criteria, which the worker ticks as it satisfies each item.

The interface: The owner field on a task
The contract: The checklist
Time to first activity: Seconds

Why there is no prompt box

A chat box produces a request that exists only in one conversation. A task produces a record with an owner, a bucket, a due date, labels, a description, a checklist and a comment thread, all of which persist and all of which a second person can read.

So Polaris uses the task as the unit of instruction. Assignment is the send button. Everything you would have typed into a prompt already has a field, and the fields survive the session that consumed them.

What happens the moment you assign

1
The trigger fires
An after-insert-or-update trigger on the tasks table checks whether the new owner is a member with kind agent that is not the copilot, and whether the task is not already done. If so it inserts a pending job row carrying the org, the task and the agent.
2
The index protects you
A unique index over task_id, limited to jobs in pending or running, means a second assignment while one is live is quietly ignored rather than starting a second machine on the same work.
3
The runtime claims it
Within one five-second poll, the job flips to running, the worker's status flips to working, and the task moves to in progress. Everyone watching sees all three at once through Realtime.
4
The brief is rendered
Title, bucket, due date, labels, description, every checklist item with its current state, and the last ten comments with their authors, are formatted into one message. The worker's instructions and skills become the system prompt.
5
It states a plan
Workers are instructed to post one short progress comment early, saying what they intend to do. That comment is the earliest point at which you can stop a session heading the wrong way.

What makes a brief a worker can actually execute

The failure mode is vagueness, and the fix is boring.

A title that names the deliverable
Not review pricing, but a comparison table of five competitors' published pricing with sources. The worker is told to deliver something concrete and specific, and the title sets what concrete means.
Checklist items that can be verified
Each item is an acceptance criterion the worker ticks by name. An item like do a good job cannot be ticked honestly, and an item like include the effective date for each price can.
A destination for the output
Written deliverables go into the Docs tree by default, under a parent page whose topic matches or under Unsorted. Naming the page you want removes the guess.
The reason, in one line
A worker that knows a brief is for a board meeting on Thursday makes different choices about length and format than one that does not.
Scope small enough for one sitting
A session is capped at ten rounds and eight minutes. Work that exceeds that should be several tasks, which also gives you several checkpoints.

Agents deliver, humans close

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

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.

Queueing work at night and reading it in the morning

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

Acceptance criteria

Written before the work, checkable after it, and binary either way.

Human-in-the-loop

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

AI worker

The difference between an agent you prompt and an agent you assign work to.

Questions people ask

+What if I assign a task with no checklist?

The brief says the checklist is empty and the worker proceeds on the title and description alone. It still delivers, but there is nothing structured to verify the result against, which makes review slower and disagreements harder to settle.

+Can I change the task after assigning it?

Editing the task does not restart a running session, because the brief was rendered at claim time. Commenting does: a comment from anyone other than the worker queues a follow-up session in which the latest human comment is treated as the new brief.

+How do I stop a session I regret?

Sessions are short by design, with a hard eight-minute deadline and a ten-round cap, so the practical answer is to let it finish and then redirect it with a comment. There is no kill switch on a running job in the product today.

+Can I assign the same task to a person and an agent?

A task has one owner. The pattern that works is to assign the worker, let it deliver into the comment thread, and leave the human as the person who reviews and closes. Mentioning another worker by first name in a comment pulls it onto the same task without changing the owner.

+Does the worker see the whole bucket?

It sees the bucket's name for context, not its other tasks. Its window is the task it was assigned, that task's checklist and recent comments, its own instructions and skills, and the titles of the org's document pages so it knows where to file written work.

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.