What shipped, as it shipped

Peractor on your phone, and on your desk

Two new apps, both running the same screens as the dashboard rather than a reduced version of it.

Peractor for iOS and Android puts a run in your pocket: the live transcript as it streams, gates to approve or reject, mid-run questions to answer, the diff to review, the backlog to work from, and push notifications when a run parks for review, asks something, or ends. Peractor for desktop is a native window with the session in your OS keychain and real system notifications.

The web dashboard became a single-page app in the same pass, so switching runs, gates and tasks no longer reloads the page.

Attachments, a public API, and a live canvas

Tracker attachments now reach the agent — the screenshot on the Linear issue is part of the task, not context you have to retype.

Organizations can mint API keys, so your own software can register a task and start a run on the org's behalf without a browser anywhere in the loop.

Artifacts a run publishes render live in a Canvas tab beside the transcript, sandboxed and offline, so you watch what the agent built take shape while it builds it.

Run one task across several agents at once

Parallel runs: send the same task to several agents at the same time, each with its own model override, and compare what comes back. The siblings group under one parent in the runs tree instead of scattering.

Presets save the run configuration you keep retyping — agent, model, workflow — as one pick.

Live previews, questions mid-run, and Slack as a task source

A preview step holds the sandbox open and serves what the run built at its own URL, so you review a running app instead of a diff. A per-run warm workspace keeps the clone and its dependencies across the phases of one run, which is most of the wait gone.

Agents can now ask you something mid-run: the run parks, the question reaches every surface you're signed in on, and your answer resumes it — no more guessing wrong for twenty minutes.

Slack joins the trackers as a chat-native task source: a message becomes a task, reactions move its status. And a finished run takes requested changes as rework, from the editor's Actions menu.

Projects, onboarding, and config that lives with the org

Projects are a first-class tier between an organization and a repository: workflows, personas, connectors and settings belong to a project, and a repo binds to one with a small peractorrc.json. Configuration moved into the org's own storage, so a teammate who clones the repo inherits the setup instead of rebuilding it.

New organizations get a real onboarding — create or join an org, invite the team by email, and a staged setup wizard that connects a tracker, a workflow and a notifier before the first run. Slack also became a one-click OAuth notifier.

GitLab and Notion join the tracker lineup

Two new first-class trackers, both connected with one OAuth click — no API keys to paste.

GitLab imports issues per project and syncs status through labels, alongside the existing merge-request support. Notion imports any database as a backlog: a per-database property picker maps your status, assignee, and label properties onto Peractor's board, so pages move columns as runs progress.

Personas, published artifacts, and GitHub Projects

Personas are reusable agent identities — a name, icon, color, and system prompt kept in .peractor/persona/ — that any prompt step can put on. Your spec writer and your implementer no longer have to sound like the same agent.

Phases can now publish design artifacts: the agent renders previews of what it built (screens, diagrams) and Peractor delivers them to your review surfaces — the gate, Slack, the tracker.

GitHub Projects (v2) boards are a tracker of their own, with real status columns — where plain repo issues only know open and closed.

Accounts, organizations, and the web app

Peractor is now multi-tenant: sign up with email, GitHub, or Linear; create an organization; invite your team with a link. Admins manage members and roles from the web, and every run, task, and connector is scoped to its org.

Connector management moved into the editor's Settings hub, and tracker boards now mirror the real task board — including tasks currently owned by a run.

The task board goes first-class

The backlog now holds tasks from multiple trackers and manual tasks at once, each keeping its origin, priority, assignee, and labels. Imported issues route to a workflow by label/assignee rules you edit next to the tracker.

In-editor code review shipped alongside: leave native review comments on a run's diff and submit them as a "request changes" rework — any time, not just at a gate.

Peractor's source also went public under the MIT license.

Draft PRs and a sharper live view

Runs open a draft pull request when work starts and mark it ready as it lands; branches derive from the task, so a run's history reads like a teammate's. The live session shows the exact prompt each phase sent, friendlier markers for git steps, per-phase model and reasoning-effort chips, and one-click checkout of the committed branch.

Webhook sync and per-origin statuses

Trackers push changes in over webhooks, so imported tasks stay live without polling delays — and can auto-start a run on arrival (opt-in). Statuses became per-origin: each tracker's own columns sync natively, with no translation table, and workflow phases can reference them in status automation.

Status-driven workflows

A workflow phase can declare onStatus — the board column that triggers it — and setStatus — where the task moves when the phase lands. Drag a task to "In Progress" and the right phase starts; when it finishes, the card moves on. The board becomes the control surface.