Product · AI agents for software delivery
Agents is a multi-agent platform that plugs into the backlog and repository you already use. The SDE agent implements work items, the QA agent tests them, and the PR Review agent reviews pull requests and comments on them. Your engineers keep the judgement calls and the merge button.
$ agents run --work-item ENG-2481resolved backlog item ENG-2481 · "Reject expired invite tokens"[sde] reading 6 files in src/auth/ …[sde] planning change: validate token expiry before session issue[sde] wrote 2 files · committed to agents/eng-2481-invite-expiry[qa] derived 5 cases from acceptance criteria[qa] running suite … 148 passed, 1 failed[qa] defect: expired token returns 500, expected 401 → back to sde[sde] patched error path · re-committed[qa] running suite … 149 passed, 0 failedpull request #812 raised → main[review] reading diff: 3 files, +64 −11[review] comment L42 · expiry compared in local time, use UTC[review] verdict: approve with 1 commentawaiting human merge — no changes pushed to mainThe team
Implementation, testing and review are different jobs with different failure modes. Splitting them across three agents means no agent ever signs off its own work.
Picks up a ticket from the backlog, reads the surrounding code, and writes the implementation. It works the way an engineer does: understand the change, make it, keep it scoped to the ticket.
Takes the same work item and tests it independently of the agent that wrote it. It checks the change against what the ticket actually asked for, and reports what it finds.
Reviews pull requests as they are raised — including the ones your engineers raise — and comments on them. It reads the diff in context rather than pattern-matching on style.
How it works
One pass through the pipeline. Each stage hands something concrete to the next, and the last stage is a person.
The pipeline runs in six stages, in order: a work item is picked up from the backlog; the SDE agent implements it on a branch; the QA agent tests that branch against the acceptance criteria; a pull request is raised; the PR Review agent reviews the diff and leaves comments and a verdict; finally a human engineer reviews everything and merges.
01 · Human / system
A ticket is picked up from the backlog you already maintain, with its description and acceptance criteria.
02 · Agent
The SDE agent reads the surrounding code, writes the change and commits it to a dedicated branch.
03 · Agent
The QA agent derives cases from the acceptance criteria, exercises the branch and reports defects back.
04 · Human / system
Once the branch passes, it is raised as a pull request against your normal target branch.
05 · Agent
The review agent reads the diff in context and leaves inline comments plus a verdict on the pull request.
06 · Human / system
An engineer reads the summary, the comments and the diff, and makes the call. Merge is never automatic.
If the QA agent finds a defect, the branch goes back to the SDE agent rather than forward to review. A broken implementation costs you a loop inside the pipeline, not a rejected pull request on your team’s desk.
See it runningWhere it fits
Adopting Agents should not require a migration, a new tracker or a change of process. It attaches to the four things you already have.
Agents work on the repository you already have, using your branching model and your conventions. Nothing is copied into a separate system and nothing is rewritten to suit the tooling.
Work items come from the tracker your team already writes tickets in. The description and acceptance criteria are the brief, so better tickets produce better output — as they always did.
Branches and pull requests flow through the checks you have configured. The agents add a testing pass and a review pass before your pipeline runs, not instead of it.
The pipeline stops at review by design. An engineer reads the change, the test results and the comments, and decides. Nothing reaches your main line on an agent’s say-so.
Capabilities
Built around how software actually gets delivered: scoped work, isolated branches, independent testing and a review a human can act on.
01
Implementation, testing and review are separate jobs handled by separate agents, so no single agent marks its own work as finished.
02
Agents operate on the repository and branching model you already have. No migration, no parallel copy of your codebase.
03
A ticket is the unit of work. Agents read the description and acceptance criteria and stay inside that scope.
04
Every change lands on its own branch and arrives as a pull request. Nothing reaches your main line unreviewed.
05
The PR Review agent explains why a line is a problem and what it would break, so the comment is actionable rather than cosmetic.
06
The pipeline deliberately stops before merge. Approval stays a human decision on every single change.
Who it is for
Agents earns its place when the bottleneck is volume of routine work, not shortage of ideas.
You have more backlog than throughput and you need the routine half of it to move without adding headcount.
Three or four engineers carrying a roadmap sized for ten. The mechanical work is what is eating the week.
Pull requests sit for days waiting on the one person everyone routes reviews through.
Testing is the step that gets dropped first when a release date tightens. A dedicated agent stops that happening.
Questions
Still unsure whether it fits your stack? Send us the details and we will give you a straight answer.
No. It removes the mechanical part of the job — the boilerplate implementation, the repetitive test passes, the first read of a diff. Judgement, architecture, product decisions and the merge itself stay with your engineers. The pipeline is built to stop at a human on purpose.
Agents work against the repository you point them at and operate within the access you grant. We scope permissions to what a task needs, and we do not require you to move your codebase anywhere. If you have specific data-handling requirements, raise them before rollout and we will confirm in writing what the deployment does and does not touch.
It works on mainstream application stacks — TypeScript and JavaScript, Python, Java, Go, C#, PHP — and the frameworks built on them. The agents read your existing code before writing anything, so they follow the conventions already in the repository rather than imposing a house style. Tell us your stack and we will be straight with you about fit.
It gets caught before you see it, or it gets caught at review. The QA agent tests the branch against the acceptance criteria and sends failures back to the SDE agent instead of promoting them. Anything that survives that still arrives as a pull request with review comments attached, and a human decides. A bad implementation costs you a rejected pull request, not a production incident.
The PR Review agent comments on the diff and the code it affects — correctness, edge cases, unhandled failure paths, and scope creep beyond the linked work item. It is not there to relitigate formatting your linter already handles, and it does not open unrelated refactoring arguments in someone else’s pull request.
We start with one repository and a narrow slice of the backlog so you can judge the output on work you understand. You connect the repository and the backlog, we agree the branch and review conventions, and the agents begin producing pull requests you review as normal. Scope widens only once you are happy with what is landing.
Try it
The fastest way to evaluate Agents is to let it work a narrow slice of your backlog and review what comes back. Open the app, or talk to us about a scoped rollout on your codebase.