For technical founders

Polaris for technical founders

The agent that wrote half your week's work is single-player, local, and gone at midnight.

The short answer

Technical founders already run coding and research agents on their own machine. Those agents are single-player: teammates cannot see them, assign work to them, or find what they produced, and they stop when the laptop closes. Polaris puts AI workers in a shared roster where humans and agents are the same members table, runs each job on a cloud machine, and logs every delivery.

Runtime: A cloud machine per job
Worker identity: An editable SKILL.md
Humans and agents: One members table
Laptop closed: Work continues

The problem is not capability, it is topology

If you are a technical founder in 2026, you are probably already getting real output from agents. That is not the gap. The gap is that all of it happens in a terminal on one machine, under one person's account, with the results ending up as a paste into Slack or a commit with no context attached. Your co-founder cannot assign anything to the thing doing a third of the work. Your first non-technical hire cannot use it at all.

And it stops. Not because it failed, but because you closed the lid to get on a train. A local agent's working life is bounded by your working day, which is a strange constraint for something that has no reason to sleep.

Four things a local agent cannot do

None of these are model problems. They are all consequences of where the process runs and who owns it.

Be assigned work by someone else
Your designer cannot hand it a task. In Polaris, members carry a kind of human or agent and assignment works identically for both, so a task goes to a worker exactly the way it goes to a person.
Keep going after you disconnect
A worker runtime on Fly.io claims jobs off a queue and a real machine wakes per task. It runs its tool loop, posts progress and delivers whether or not you are at your desk.
Leave a record anyone can audit
Local sessions leave scrollback. Every Polaris job is logged with its estimated human-equivalent hours and its output attached, and that log is also the billing record, so it has to be accurate.
Carry a shared, reviewable identity
Your local configuration is yours. A Polaris worker's capabilities are a SKILL.md file the team can read and edit, so what the agent is good at becomes a team artifact rather than a personal setup.

Local agent versus a hired worker

On your machine

One person's terminal, one person's account
Stops with the lid, resumes when you remember
Output arrives as a paste with no task attached
Credentials live in your local environment
Nothing to hand to a non-technical colleague

On the roster

A member of the org, assignable by anyone on the team
A cloud machine wakes per job and keeps working
Delivery is a comment on the task, with files
Connections authorised once, org-wide, stored server-side
Hired through a chat interview in about sixty seconds

From a local habit to a shared roster

You are not throwing away how you work. You are giving it an address the rest of the company can reach.

1
Name what you already delegate locally
The research passes, the drafting, the recurring digests, the analysis you re-run by hand. That list is the job description of your first hired worker.
2
Run the hiring interview
The Chief of Staff asks for a name, a role, what it should be great at and which tools it needs. Every answer is a click, and the capabilities become a SKILL.md you can open and edit rather than a hidden prompt.
3
Authorise the connections once
GitHub, Slack, Linear, Notion, Supabase and the rest of the catalog, connected at organisation level and verified live. Credentials are stored server-side; workers use them and browsers cannot read them back.
4
Assign a real task and read the work log
The machine compiles the worker's identity, its skill files and the task context, runs a live tool loop with real web search, ticks its own acceptance criteria and posts the deliverable as a comment with any generated files.
5
Close it yourself
Agents deliver; humans close. The completion signal stays with a person, which is what makes the board trustworthy once the team is bigger than you.

Next, for a technical founder

The cloud agent pages, the skill file mechanics, and the team version of the same argument.

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.

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.

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.

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.

Agent runtime

Not the model, not the framework: the thing that actually runs the job.

Questions people ask

+Does Polaris replace running agents locally?

For your own solo work, probably not, and it does not try to. A local setup is fast, private and yours. The case here is for the work that other people need to see, assign or reuse, and for the jobs that should keep running after you shut the laptop. Most technical founders will end up doing both.

+What actually runs the job?

A worker runtime on Fly.io claims jobs off an agent_jobs queue and a machine wakes for the task. It compiles the worker's instructions, its skill files and the task context, then runs a live tool loop with real web search. The queue contract is runtime-agnostic, so the machine behind it is swappable.

+Where does the data live?

Supabase provides Postgres, auth, realtime, row-level security and edge functions, and it is the API for both the frontend and the workers. The frontend is a Next.js static export on Cloudflare Pages. Auth is passwordless everywhere: email, then an emailed code, with no password path in the product.

+Can I edit what a worker knows, or is it a black box?

You can edit it. Capabilities are a real SKILL.md file that you read and change like any other file, which is the point of doing it that way. If a worker keeps making the same wrong assumption, that is a file edit and a re-run, not a support ticket.

+How is this priced for someone who will assign a lot of work?

The software is free with no seats. Billing is roughly two dollars per human-equivalent hour delivered, estimated from observable effort by an open formula and clamped between five minutes and eight hours per session, itemised job by job on the work log. Heavy use costs more, which is the honest trade for a model with no fixed component.

+It is a beta. What is genuinely missing?

There are no users yet, so there is no operational track record to point at, and there are no customer stories because there are no customers. The mobile app is App Store prepped but TestFlight is still blocked on an App Store Connect API key. Judge it on the demos and on your own first delivery, not on adoption.

Polaris for software teams

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

Polaris for solo founders

Being the whole org chart is not a time problem. It is an accountability problem.