What shipped, as it shipped

Show the assistant what you mean

The assistant takes files. Attach a screenshot, a log or a document to a message — the paperclip in the message box on the phones, the Mac and the dashboard — and it opens the file and looks at it before it answers. "Set up our board like this one" with a picture of the board is a whole request.

A file rides with your words rather than replacing them, and what is inside it is something you are showing the assistant, never an instruction to it. Files stay part of the conversation: each sits under the message that sent it, and a later message can ask about one you attached several turns ago.

Sharing works the same way. Share a screenshot from another app to Peractor and The assistant — ask about it takes it along with your question — it used to step aside whenever a share carried a file.

Ask the assistant to do it, not only to explain it

The assistant can now do what you can do on a screen. It used to set Peractor up — workflows, personas, settings, a run to start — and could only describe the rest: it would tell you a run was waiting for your review and leave you to go and find it. Now ask it to approve or reject a gate, answer a run's question, request changes, restart a phase or cancel; to file, triage, merge, relate or archive tasks, or change a dozen at once; to move a milestone and post its update; to sync a tracker or start an import; to invite people, look after machines and apps, or publish a pack.

It still proposes and you still apply. Each of these is a line on the plan it hands you, applied through the same code your own screens use, so it can do nothing you could not. On the phones and the Mac, a plan that is only an answer to a run's question — or a message to a step you are talking to — is a single Send button with the words beside it, because typing an answer and then approving a card that sends it was two yeses for one thing.

What it will not do is a short list, kept on purpose: delete an organization or a project, connect a service whose consent screen a person has to see, change how you sign in, or learn a secret.

Who filed it, what it is, and who has it

A task can have several people on it — up to ten, which is GitHub's limit for GitHub's reason: a task assigned to everybody is assigned to nobody. Each person added is told. On a board grouped by person a task with two people stands in both columns, and dragging it into a third column hands it over. Synced GitHub and GitLab issues now bring every assignee, where they used to keep the first and drop the rest without saying so.

My tasks knows who you are. It matched on a name, so renaming your GitHub login took your own tasks off your own view. It matches your account now, and a name only where there is no account to match — an imported issue assigned to somebody who never joined.

A task says who filed it, set once when it is made. A synced issue carries its tracker's reporter, and a backlog imported from Linear, Jira, GitHub, GitLab or Notion keeps every issue's reporter instead of crediting the import.

And it can say what kind of thing it is. Your project names its own types — Bug, Feature, Chore, whatever your team calls them — each with an icon and a colour, under Types beside Statuses and Priorities, and every task wears its type's icon beside its title on the board. Change a task's type on the task itself or a dozen at once, and group a board by type or by who filed it. A project that defines none has no type field anywhere: nobody meets a concept their team did not ask for. An import brings the source's types with it, so a Jira project arrives with its Bug, Story and Epic as your own.

Publish from any device, as your organization

Publishing a pack works everywhere now — the phones and the Mac as well as the dashboard and the editor. Publish a pack sits in the marketplace, and the form is the same decision on each: pick what goes in, name it, say what changed.

The organization publishes, not whoever pressed the button. A pack wears your organization's name and picture, and any of its admins can publish the next version — a pack should not become unmaintainable the day one person leaves. The form offers every library the organization has at once, the shared one and each project's, and says which is which: "Release" in the shared library and "Release" in a project are two different workflows.

What a workflow uses comes with it. Tick a workflow and the personas its steps name are ticked beside it, each saying which workflow holds it, and one a picked workflow still needs cannot be unticked. Anything that only means something inside your organization — the statuses a phase moves a task to, a notifier you named — is left out of the pack, and the form says so before you press Publish rather than after somebody installs it.

Your own packs come first, under "Published by" your organization's name, withdrawn ones included. Each has Publish a new version, which starts from everything the last version carried, and Unpublish, which takes it off the marketplace and refuses new installs without touching anybody who already installed it.

And a pack lands where you opened it from. Open the marketplace from a project's skills and the pack installs into that project; from the organization's library, into the organization's. The page says which above the button. Packs mix kinds now too: most of ours carry skills beside their workflows and personas.

Videos play where they were attached

A video attached to a task or a comment now plays right there, in each device's own player — on the phones, the Mac, the dashboard, the desktop app and the editor. Until now the viewer wrote the file's name on a black screen and suggested finding a computer, on the one device already holding the clip.

Nothing starts playing by itself. A format the device cannot play says so and names the type, instead of drawing a black rectangle and failing where nobody sees it. And the copies a phone keeps in order to play them are cleared when you sign out, so the next account on that phone finds none of yours.

Your project decides where things are

Runs, Triggers, Tasks, Planning, Wiki, Apps and Settings, in the order your team wants them. A phone's tab bar holds five things and this product has seven, so something was always off the bar — and we picked which, badly: turning a wiki on quietly took the Triggers tab away, and Planning had no door of its own at all.

Now an admin drags the list in Settings → Navigation, and every device follows: the phones, the iPad, the Mac and the dashboard. Whatever a phone's bar has no room for is behind More, which is a screen rather than a disappearance — nothing here can hide a part of the app from the people using it.

A team that lives in its wiki drags it to the front. A team whose work all starts from events puts Triggers first. A project that never opens the screen keeps the order we think is right, and gets our next answer for free when we change our minds.

On the Mac, all six of a project's destinations are rows in the rail — Triggers and Planning were filed under Settings and inside the board before this, which made them the two the order had nothing to say about. Each opens the desk's own three columns: your triggers beside the one you are editing, your cycles and milestones beside the one you opened.

Your team's notes live in the repository

A project can have a wiki, and the wiki is markdown files in your own repository. Not rows in our database. Turn it on, name the folders that hold pages — docs/ is prefilled — and every markdown file under them is a page on every device: the phone, the browser, the Mac, the editor.

Every client holds the whole wiki as text, so it opens instantly and searches with no connection at all. Edit on a train; a pending list shows what this device has changed, and one button commits all of it in a single commit. If somebody edited a different part of the same page while you were offline, the two merge and nobody is told anything — you are only asked when you both changed the same lines.

Because the pages are the repository, the agent working your next run already has them, they are diffed and reviewed like the code they describe, and a developer editing docs/ in their editor is simply editing the wiki.

Look at a preview on your phone, and draw on it

A run that parks with a preview now opens inside the phone app rather than throwing you into a browser. Look at the real thing, then continue or request changes without leaving the run.

And you can draw on what you are looking at — circle the misaligned button, scribble on the broken row — and the drawing goes into the note the agent receives. A pointed finger beats a paragraph describing where to point.

The backlog becomes a real tracker

Every task gets a key — WEB-14 — that names its branch, prefixes its pull request, and finds it in search.

A conversation and a record. Comment on a task, reply once, attach files, and name people with @. Every change writes a line, so a task reads months later. Runs comment too: a run posts when it starts, when it parks for review, and when it settles, each comment a door into the transcript.

Planning. Milestones with dates and progress, cycles on a cadence you set that roll unfinished work forward by themselves, and a triage queue that holds work arriving from outside until somebody says it is real. Plus sub-tasks, relations — blocks, blocked by, relates, duplicates — estimates on the scale your project uses, and due dates.

Views. Filter, group, order, and switch between a board and a list, then save the arrangement. Active, Backlog, My tasks, and Current cycle are always there. Drag to reorder or to change column, and change many tasks at once.

And a way off your old tracker. Import a whole Linear team, Jira project, repository, Notion database, or Slack channel — comments, attachments, dates, parents, relations and all — into tasks Peractor owns. You read the plan before anything is written, it can be run twice safely, and nothing is ever written back to the source.

Open a run's file where you actually work

A file a run changed now opens at its first changed line, in your own editor — VS Code and its forks, JetBrains, Xcode, Zed, and a dozen more. The picker lists what is installed on your machine and remembers what you chose.

A pull request is a piece of work, with a board

Incoming pull requests become tasks. The third GitHub tracker, on the same app install as Issues and Projects, with six columns instead of two — Draft, Open, Changes requested, Approved, Merged, Closed.

A run started from one is a review run: it checks out the pull request's head, diffs against its own base, is told it is reviewing and who wrote the code, and writes nothing at all to the repository. What it finds arrives as a comment on the pull request.

Moving a card can close, draft, reopen or mark ready. It refuses Approved, Changes requested and Merged, and says so — the first two are a person's judgment, and the third would merge somebody's code because a card moved.

Steps that wear several roles, loops that reach back a phase

A step can bind several personas. A step is regularly a frontend engineer and the house reviewer, and writing a third persona that repeats both is how a library stops being reusable.

A loop can reach back into an earlier phase — "if the checks in Verify failed, go back to Build's implement step and do it again" — and can now exit when either condition is met rather than always needing both.

A tag step really cuts the tag, from a template you write, on the base branch as it stands when the step runs. And git steps can skip what is already done, so a re-run phase stops failing on the one step with nothing left to do.

A step's conclusions carry forward by default. Every prompt step is a fresh session, so what one worked out used to vanish unless it was committed. Now it ends with a short note that every later step receives — switch it off per step if the thinking is not worth passing on.

And your organization's standing instructions wrap every run. Four layers, each openable on its own in the transcript: the organization's, the project's, the workflow's, and the step's persona.

Steps you can talk to

Mark a prompt step interactive and it runs its prompt, then stops and waits for a person. Until somebody ends it, anyone who can see the run can open the step and talk to the same agent — send messages, read replies, watch the tools it uses. The conversation is part of the run and shows in both places.

Two ways out: Proceed accepts and advances, and Request changes re-runs the phase with the conversation threaded into the next prompt — because a conversation that concludes "this approach is wrong" should not strand you.

It costs nothing while nobody is in it. Peractor keeps the machine warm for a short window, then saves the work and gives the machine back, with the decision still open. More than one person can be in one conversation.

Skills your agents carry, and MCP servers they may call

Teach every run how your organization works. A skill is a page of instructions with one line saying when it applies — written once in your organization's settings, staged on disk for every run of the projects that pick it, and followed by the agent when the work matches. Skills use the open SKILL.md format, so the ecosystem's public skills work here: paste a GitHub address to import one, or start from the suggestions on the empty screen.

And hand your agents the tools you already run. Register an MCP server — a docs index, a database gateway, an internal API — and every run of the projects that pick it can call its tools, on Claude and Codex alike. The token is stored encrypted, referenced by the run's environment, and never written to any file the agent could commit; registering and changing a server is admin-only and lands in the audit log. If you harden egress, a registered server's host joins the allowlist by itself.

Picking stays the boundary. Like shared workflows and personas, a skill or a server an admin registers does nothing anywhere until a project ticks it under Settings → Shared library.

Previews you can come back to

A preview waits for you now. It used to hold the run's machine open while it waited, and give up after half an hour — so a site built overnight was a dead link by morning, and the only way to see the finished work was to run the phase again. The run parks instead: the decision stays open for as long as it takes, and nothing continues without you.

Tell the preview step how to serve what it built — npx serve -s dist -l $PORT, with an optional folder and build line beside it, the same three fields an app declares itself with — and Start preview brings it back from the very commit you are being asked about. The build log runs while it comes up, so a two-minute wait reads as work rather than a hang.

One preview, everyone looking at it. Two people reviewing the same result share one container and each other's link, and the card says when somebody else is on it. It stops when the last of you does — a preview nobody is reading costs nothing, and starting it again is a button. A preview step with no serve line still shows you the result while its phase is up, and the run still waits for your decision afterwards — it just cannot be started again.

For self-hosters: previews are sized against your box with PERACTOR_PREVIEW_MAX_RUNNING and friends, and the review window is gone — there is nothing to time out.

One link for everything, and a share sheet that files work

Every run, task, workflow, persona, trigger, app, and project has one link. It opens the right thing on whatever the person opening it is using — the app where it is installed, the browser otherwise — and it carries enough to open cleanly even on a device signed in as several people. A link to a gate lands you on that gate.

And it works the other way: Peractor is a share target on iPhone, iPad, Android, and the Mac. Share a screenshot from anywhere and pick where it goes — a run, a task, or a message to the assistant — with the file attached. "Here is the bug" is a screenshot and a sentence.

A marketplace of workflows and personas

Install a set of workflows and personas somebody already wrote. Open the Marketplace, pick a pack, and everything lands in your organization's shared library under a category named after it. From that moment the copies are yours — edit them, rename them, delete them. Nothing stays owned by the marketplace and nothing ever changes on its own. Packs are free; there is no paid tier and no cut.

The install screen is the point. Installing a pack means running a stranger's instructions on your infrastructure with your credentials, so before you press the button you see every step it would add — drawn in Peractor's own vocabulary rather than the author's description, so a step that runs a shell command or posts to one of your connectors says so — what it needs that you do not have, and what the checks found. A pack that runs shell commands asks twice.

Updates wait for you, and never overwrite your edits. When an author publishes a new version your list says so; Update shows what would be rewritten and the changelog for every version between yours and the new one, not just the newest. Anything you have changed is recognised as yours and skipped — editing one workflow does not cost you fixes to the other nine — and a version that drops a record deletes nothing.

Publishing closes over what you picked: a workflow brings the personas and prompt files its steps name, or the publish is refused rather than shipped broken. Every version is scanned first — no web addresses in text an agent will read, no command that downloads or escalates or reads your credentials, no secrets in prompts — and a version that fails is not published at all. The badge says "checked", not "safe": an automated scan cannot promise the second one.

Apps your organization builds for itself

A small web app, built from your repo, opened from every device. A team chat, a retro board, a poll, a dashboard: declare it from Apps, point it at a folder in a repository, and an admin deploys it. It appears in the Apps list on the dashboard, in the editor, in the desktop app and on both phones — where it is a tab of its own, and an open app fills the screen with no chrome around it.

Nobody signs in to it. Whoever opens it is already themselves, and Peractor stamps who they are onto every request it forwards, after stripping anything the browser sent under the same names. The app never sees a password, a token or an email address — and it never asks.

It can reach nothing. The container has no route to the internet or to your network; the only thing that can talk to it is Peractor, forwarding the people who opened it. An app cannot leak what it is told, which is what makes it safe to tell it who is in the room. It starts when somebody opens it and stops when nobody has for ten minutes, so an app nobody is using costs nothing.

Deploys are ordinary and reversible. Build a branch from the app's own screen; people get the new code on their next page load and whatever the app stored is untouched. Every build keeps its log, the last three keep their code, and Make live is an instant rollback — no rebuild, nobody signed out. Data lives on one volume that outlives every deploy and every rollback.

Your account, and every way into it

A confirmed email address is your account. A password, a GitHub login, a Google account, a Linear user — each is a way in, and one account can hold as many as you like. Sign up with Google, add a password later, attach GitHub because a teammate's approver rule names it, drop Linear when you stop using Linear. You land on the same account every time.

A Sign-in methods screen on every surface lets you add and remove providers, set or change a password, change your email address, and see the devices signed in as you — ending one, or all but this one. The last way in is refused before it is offered rather than after.

Two-factor authentication with an authenticator app, and several accounts signed in on one device: switching is instant, nothing signs out, and each account keeps its own notifications and cached work.

Run on your own machine

Pair your Mac or Linux box and run phases on it — for the work the Peractor runner can't do: building and screenshotting a native app, driving the iOS or Android simulator, using a toolchain or GPU only your machine has. The machine runs a small agent that dials out to Peractor over one WebSocket; nothing ever connects to it, so home NAT with no public address works with no port forwarding and no tunnel service. Pair in Settings → Runners, label the machine (say macos), and any workflow phase with that label — pickable in every editor's Runs on field — executes there. Every phase header says where it ran.

The whole run experience crosses over: screenshots and other artifacts the agent registers arrive inline in the run, and preview steps serve from the machine too — the built result stays on the machine's own localhost while its traffic rides the same outbound connection, so reviewers use the normal preview link and the machine's network sees nothing.

Sign-in is per machine: save a Claude/Codex key or subscription token for each machine in Settings, or just sign the machine itself in — your organization's key from Model providers backs the Peractor runner and is never sent to anyone's laptop. Pairing, removal, and machine sign-in are on the web, the desktop app, and both phones.

The phones work without a connection, and runs can be filed away

A phone gets used in lifts, trains, basements and planes. Now the last answer each screen received is kept on the device and drawn on the first frame of the next visit, marked as a saved copy, while the fresh one loads. You see what you had instead of a spinner.

And any finished run can be archived: it leaves the runs list for an archive of its own and comes back with one action. The runs list answers one question — is anything waiting on me — and this is how it keeps answering it after the three hundredth run.

Work that starts itself

Triggers bind an event to a workflow run, so a run no longer needs somebody to click it. Three sources, one config file: a schedule (a 5-field cron, UTC), a repository event (a push, a tag, a pull request opened, updated or closed — through the GitHub App already installed, filtered by branch and by changed path), and a webhook anything that can POST JSON can call, signed with a secret from your organization's store.

The event reaches the agent as text: the run's title and description are {{ event.pr.number }}-style templates over the payload, with {{ event | json }} for everything a normalized event doesn't name.

Because a triggered run spends money without being asked, every evaluation is recorded — fired or not — with the guard that decided it in a sentence you can act on: disabled, a filter that missed, Peractor's own commit, the concurrency policy, your quota, a repeat delivery. A Test button shows what would happen without starting anything, and Run now fires it for real. Triggered runs carry their attribution in the run header and group under Triggered in the runs list.

Triggers are a library beside Workflows and Personas — in the editor, the dashboard, the desktop app, and on both phones.

Run whole workflows side by side

A phase can fan out into lanes, each running another of your project's workflows at the same time, in its own container on its own branch. Ship the same feature on Android and iOS; try three approaches; run a security audit beside the implementation.

When the lanes settle, the next step gets every lane branch fetched locally — so git diff and merge between them just work — plus a manifest and a report per lane. Gates, questions and previews are honoured per lane: one that needs you parks on its own while its siblings carry on.

With a single lane it is not parallelism at all but reuse — one shared test-pass workflow dropped into ten pipelines instead of copy-pasted phases.

An assistant that sets Peractor up for you

Describe your team and what you are building, and the assistant drafts the workflows, personas and settings that match — then shows you exactly what it would change and waits.

It proposes; you apply. It works in a throwaway copy of your configuration, so nothing it writes is your configuration. A turn ends with a plan you read and either approve or discard, applied all at once through the same handlers your own screens use — so it can only ever do what you could do. It never learns your secrets, and a draft with a credential written into it is refused.

It reaches every organization and project you belong to, needs neither to get started, and answers questions about how Peractor itself works.

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 artifacts you can look at

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 are rendered rather than listed — an HTML widget, a chart, a diagram, a screenshot. Each opens in a tab of its own, sandboxed with no network at all, so you can look at what the agent built while it is still building.

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 run 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 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.