Problem 1:No memory
Every run starts from scratch
Each run depends on someone's own prompts, not a shared workflow your team can improve.
From agent sessions to a team system
Agents can write code.
Agents can write code.
Teams still need a delivery system.
A single agent session can finish one task. But it can't decide how your team picks up work, reviews it, approves it, and ships it.
Problem 2:No trail
You only see the final result
Reviewers get the finished code, but not the tests and decisions that produced it.
Problem 3:No automation
Everything moves by hand
Someone has to move the ticket, run each step, get approval, and ship it by hand.
How it works
Three things to set up.
Three things to set up.
Then it runs itself.
Peractor sits between the tools your team already tracks work in and the agents that do the work — designing it, coding it, testing it, shipping it. You connect it once and describe how your team works; after that the work moves on its own, and only stops at the points where you said a person should decide.
Connect where work lives
Point Peractor at your tracker, your board, or a messaging channel. Anything your team adds there shows up in Peractor as a task, and a rule you set decides how that task is handled.
Describe how work gets done
A workflow is a list of phases, and a phase is a list of steps: give an agent an instruction, run your tests, open a pull request, merge it, notify the team, run your deploy. Mark any phase that should stop and wait for a person to review it.
Watch it, and decide
Open the run and watch it happen: what your agents are doing, the files they changed, whether the tests passed. It loops where you told it to loop, stops where you told it to stop, and the finished work goes back to the ticket or the message it came from.
Everything it plugs into
Peractor coordinates the tools your team already uses instead of replacing them.
Work comes from
Your team keeps filing work exactly where it always did.
Every door into the same system
Anyone on the team can start work.
Anyone on the team can start work.
It comes back done.
Support posts in Slack. The PM moves a Linear ticket. Marketing marks a Notion task ready. None of them open an editor and none of them learn a new tool — the request goes in where it always did, and a reviewed change comes back out.
Support engineer
#bugs · Slack
Checkout returns a 500 when a saved card has expired.
Peractor runs
ReproduceFixMerge
They get back
Fixed and merged
The run threads under the original message; the fix is posted there when it lands.
Product manager
Acme Platform · Linear
ENG-214 · Build the usage analytics dashboard
Peractor runs
SpecCodingTestingMerge
They get back
Merged · issue moved to Done
The spec, the changes and the full history land on the issue as each phase finishes.
Open-source contributor
acme/platform · GitHub Issues
#482 Daily buckets ignore the project timezone
Peractor runs
TriageFixTestingPull request
They get back
PR opened with a regression test
A maintainer approves on the PR; merging runs your release command and posts to Discord.
Marketing
Website tasks · Notion
Update the pricing page for the new Team plan
Peractor runs
SpecCodingPreviewShip
They get back
Preview link, then shipped
They open the preview from Telegram, approve it there, and the ship step runs your deploy.
Designer
WRD board · Jira
WRD-102 · Empty states for the runs list
Peractor runs
DesignCodingPreview
They get back
Preview URL on the issue
The preview link posts to Teams the moment it is ready, and the issue moves on once they approve it.
QA engineer
acme/platform · GitLab Issues
#77 Logout test is flaky on CI
Peractor runs
CodingTesting
They get back
Merge request opened, tests passing
Peractor pushes the branch and opens the MR; one more step and it merges too.
Any system you own
POST /api/v1/tasks
{ "title": "Patch CVE-2026-1181 in the api service" }
Peractor runs
PatchTestingMerge
They get back
Run id returned immediately
An on-call bot, an internal portal, a nightly cron — anything that can POST starts a run.
Your process, made executable
You write the workflow.
You write the workflow.
Peractor runs it.
A workflow is the path every task takes, from arriving to done. You break it into phases and fill each one with steps — an instruction for the agent, a test to run, a pull request to open, a deploy to trigger. Peractor then walks that same path for every task that comes in, pausing at the phases where you want a person to review first.
An example workflowSpecCodingTestingMergeShip
Stops for a person to review
Where this workflow ends
A step can
Prompt an agentRun a checkRun a commandOpen or merge a PRNotify the teamPublish and preview artifactsLoop back and retry
Personas
The same agent.
The same agent.
As many specialists as you need.
A persona is a job description you attach to a step: the standing instructions that come with being your reviewer, or your test writer, or the one who touches payment code. The model stays the same — what it is being is up to you.
Change it once, every step follows
The instructions you keep retyping into prompts live in one place instead of in every workflow that needs them. Edit the persona and every step using it picks up the change on its next run.
What you put in one
How this codebase does things
What to leave alone
When to push back
The bar for done
Watch and steer
Watch every run.
Watch every run.
Decide what matters.
Every run is visible from the moment it starts: what your agents are doing, what they changed, and whether the tests passed. At the phases you marked for review, it pauses and waits for a person — and the same holds when twenty of them are moving at once.
Where it runs
Your code goes exactly
Your code goes exactly
as far as you allow.
Peractor comes in two halves: a control plane that coordinates the work, and runners that execute it. You choose who owns each half — so when your code has to stay on your own machines, it can.
Nothing to run. Sign in, connect a repo, and the first run starts on our machines.
We coordinate the work. Your code is only ever checked out and executed on machines you own.
Bring the whole thing up with Docker Compose on your own box. The source is MIT, so you can read every line first.
Every run is sandboxed and thrown away afterwards, whoever owns the machine it ran on.
Why not just…
Each of these covers a piece.
Each of these covers a piece.
Peractor covers the path.
Your tracker, your agents and your CI each own a stretch of the way from a task to a merge. Peractor is the process that carries one task across all of them and back.
A coding agent on its ownClaude Code, Codex, Gemini CLI
Finishes one task in one session. Peractor runs the same agents inside a workflow fed by your tracker, with your team's decisions in it.
A hosted autonomous agentDevin, Copilot agent, Codex cloud
Their process, their runtime, their machines. Peractor runs the workflow you wrote, on infrastructure you pick, from source you can read.
CIGitHub Actions, GitLab CI
Strong at checks and deploys. Peractor calls your CI and covers what it was never built for: rework loops, questions, decisions.
A general workflow engineTemporal, Trigger.dev, n8n
It could carry all of this, once you build the agent seam, the live view, the decisions and the tracker sync.
Peractorwith the agents you already run
One run from ticket to merge, visible the whole way, stopping where your team marked.
Covers this
Only once you build it
Not what it is for
Get Peractor
Install it where
Install it where
you already work.
Sign in once and your work follows you — the same runs, the same backlog, the same reviews, in the editor, on your desktop, and in your pocket.
Editor extension
Start a run, watch it work, and review the result without
leaving your editor.
Editor download
Desktop app
A dedicated app for watching and steering every run on your
computer.
Desktop download
Mobile app
Start runs, review the work, and approve it from wherever
you are.
Mobile download