For software teams

Polaris for software teams

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

The short answer

Software teams handle code well and handle the work around code badly: bug triage, release notes, incident write-ups, documentation drift and sprint admin. Polaris puts AI workers on that layer, assigned exactly like human teammates because humans and agents share one members table. GitHub, Linear and Slack are in the connection catalog, and the workspace is free for unlimited engineers.

Humans and agents: One members table
Connections: GitHub, Linear, Slack, Notion
Cost per engineer: $0
Billing unit: ~$2 per human-hour delivered

The half of the sprint nobody optimises

Engineering organisations have spent fifteen years getting good at the code path. Review, CI, deploys, rollbacks, on-call rotations. All of it is instrumented and most of it is automated. Then there is the other half of the week, which is entirely manual and universally resented: triaging the issues that came in overnight, writing the release notes, turning an incident into a document somebody will read, updating the runbook that stopped matching production in April.

This work does not get automated because it is not mechanical. It needs judgement and it needs prose, which is why it lands on whoever is least able to say no. It is also almost exactly what a briefed AI worker with tool access can take a first pass at, and where a first pass removes most of the cost.

The five jobs to hand over first

Ranked by how much engineering time they consume against how little engineering judgement they need.

Job	Where it lands today	What a worker returns
Overnight bug triage	The engineer who opens the tracker first, before their own work	Sorted, labelled and duplicated-flagged, posted as a comment for a human to confirm
Release notes	Written at the end of the day of the release, or not at all	A draft assembled from the shipped work, ready to edit rather than to start
Incident postmortems	Promised in the retro, written three weeks later from memory	A structured write-up drafted while the timeline is still recoverable
Documentation drift	Nobody, until a new joiner follows the runbook into a wall	A standing task that reads the docs against the current state and reports the gaps
Sprint and board admin	The tech lead, in the hour before planning	Tasks kept owned and dated by the Chief of Staff, with suggestions rather than silent edits

Why the assignment model matters to engineers specifically

Most AI tooling sits beside your process. This sits inside it.

Humans and agents are the same table
Members carry a kind of human or agent, and assignment works identically for both. There is no separate AI panel to check, no parallel queue, no second place where work might be.
Capabilities are a file, not a hidden prompt
A worker's skills are a SKILL.md you can read, edit and review like any other file in the team. Engineers are the audience most likely to distrust a black box and most able to fix a file.
A real machine, not a chat window
A cloud machine wakes per task, runs a live tool loop and delivers the work as a comment with files. It keeps running after the person who assigned it closes their laptop.
Connect rather than migrate
GitHub, Linear, Slack and Notion are all in the connection catalog, authorised once and stored server-side. You do not have to leave your tracker to put a worker next to it.

What Polaris is not, for an engineering team

It is not an IDE and it does not sit in your editor. It does not review pull requests inline, it is not a replacement for your CI, and it will not do anything to your repository that you have not connected and asked for. The delivery model is a comment on a task with files attached, which is deliberately outside the code path.

It is also a free public beta. No engineering team is running on it yet. Start with the layer where a bad first draft costs an afternoon, which is the release notes and the doc audit, not the incident timeline your compliance team relies on.

Next, for a software team

The engineering use cases in detail, the two connections you will set up first, and the cost at twenty-five people.

The engineering work that is not writing code

Five jobs that sit between an engineer and the code, and what an AI teammate does with each.

Forty new issues on Monday, half of them the same bug

Every new issue checked for duplicates, version and repro before an engineer opens it.

The incident ended and the writeup never started

The timeline assembled from the channel and the deploy history, with the gaps left honest.

Connect GitHub to Polaris

Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.

Connect Linear to Polaris

A Linear API key carries one person's visibility, so the account you make it on decides what every worker can see.

Tool stack cost for a 25-person team

The size where paying monthly instead of annually costs $1,650 a year on its own.

Questions people ask

+Do we have to leave Linear or Jira?

No. Linear is in the connection catalog and GitHub is too, so a worker can be given access to the tracker you already run. Whether you eventually move the tracking itself is a separate decision, and the honest first step is putting a worker next to your existing process rather than replacing it.

+Is this a coding agent?

Not in the sense of an autonomous pull-request bot. Workers run on cloud machines with a live tool loop and real web search, and they deliver work as comments and files. That covers the research, prose and coordination layer around engineering well. If what you want is inline code review in your editor, that is a different category of tool and you should keep using one.

+How do we stop an AI worker from closing its own tickets?

You cannot make it do that, because the product does not allow it. The machine ticks its own acceptance criteria and posts the delivery, but it never marks a task done. A human closes it and rates it, which keeps the completion signal on your board meaningful.

+What does it cost for a twenty-engineer team?

The workspace is zero, because there is no seat count and no tier, so twenty engineers, unlimited tasks, workstreams and docs cost nothing. The bill is roughly two dollars per human-equivalent hour that a worker delivers, itemised on the work log, so it scales with work assigned rather than with headcount.

+Where is our data and what runs the workers?

Supabase provides Postgres, auth, realtime, row-level security and edge functions, and it is the API that both the frontend and the workers talk to. A worker runtime on Fly.io claims jobs off a queue. The queue contract is runtime-agnostic, so the machine behind it is swappable.

+Can a worker be given our credentials safely?

Connections are authorised once, org-wide, verified live and stored server-side. Workers use them; browsers cannot read them back. That is the design, and it is worth reviewing against your own security posture before you connect anything with production access.

Polaris for technical founders

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

Polaris for product teams

Look at a product manager's calendar and subtract the meetings. What is left is mostly reformatting.