Software teams
Reproduce bug reports before a developer picks them up.
Agents follow the reporter’s steps on staging, in the browser the report names, and file what breaks. Fixes go up as pull requests. Merging waits for a developer.
Or Book a demo
Bug report
Starts: A webhook when support escalates a Zendesk ticket
- Report, someone outside
- Try on staging, an agent
- Keep evidence, an agent
- Can’t reproduce, waits for you
- File it, an agent
Waiting for you
It didn’t break. What did we miss?
A developer checks for missing setup details before the report is closed. In the film, the missing detail is the browser.
- An agent
- A teammate
- Someone outside
- Waits for you
Reproducing a bug needs the reporter’s setup.
A useful reproduction needs the reported steps and browser, along with screenshots and logs. A report tested in the wrong browser can miss the failure.
Agents attempt the reproduction on staging and keep what they find with the ticket. If they can’t reproduce it, they ask for help.
Film · Bug report
Testing a bug in the browser the reporter used.
In the film, an agent tries a bug report in Chrome and can’t reproduce it. The team lead asks it to use Safari, where the bug appears. An agent drafts the browser requirement into the procedure, then tests it on the same report.
Five procedures for a software team.
The examples include developer review for unreproduced bugs, merges and releases. You choose the review steps, and can try a revised procedure on past runs before publishing.
An integration agent builds connections to the systems your team uses from their API docs. How connections are set up
-
- Report, someone outside
- Try on staging, an agent
- Keep evidence, an agent
- Can’t reproduce, waits for you
- File it, an agent
Agent work
Read the Zendesk report, follow the customer’s steps on staging, and keep screenshots and browser logs. Add matching Sentry errors and file the findings in Linear.
Waits for you
It didn’t break. What did we miss? A developer checks for missing setup details before the report is closed. In the film, the missing detail is the browser.
-
- Plan, an agent
- Build, an agent
- QA, an agent
- Open PR, an agent
- Review and merge, waits for you
Agent work
Write acceptance checks from the ticket, build on a branch, run every check in a browser with a screenshot at each step, and open the pull request.
Waits for you
Merge this pull request? Review the code and QA results before merging. GitHub’s merge call asks first unless a person changes that setting.
-
- Run checks, an agent
- Screenshot each step, an agent
- Failed checks, waits for you
- Send back, an agent
Agent work
Run the acceptance checks for everything in the deploy, at desktop and phone widths, and keep a screenshot for every step.
Waits for you
Send it back, or ship it with a note? A failed check can be a real bug or an out-of-date check. The developer who knows the change can tell.
-
- Read merged PRs, an agent
- Read tickets, an agent
- Draft notes, an agent
- Publish, waits for you
Agent work
Read every pull request merged since the last release and the tickets behind them, and write the notes in your customers’ words.
Waits for you
Publish these notes? Check which changes are available to customers before publishing, including features still behind a flag.
-
- Recent deploys, an agent
- Read the errors, an agent
- Update incident, an agent
- Roll back, waits for you
Agent work
Compare the incident’s Sentry errors with recent Vercel deployments, then add the findings and source links to the PagerDuty incident for the on-call engineer.
Waits for you
Roll back the last deploy? A rollback changes production. The on-call engineer decides, with the agent’s evidence in front of them.
What arrives with the ticket or pull request.
- Reports that come with evidence
- Screenshots, the network log and the console, from the browser the reporter used.
- Pull requests with the QA run attached
- Every acceptance check, with a screenshot at each step.
- Tests from real reports
- Turn a past run into a test, and replay it before you change the procedure.
- A question when reproduction fails
- The agent asks for help so a developer can check the setup before closing the report.
You choose where work waits for a person.
Set review steps for merges and rollbacks. Connection calls require approval by default, and code an agent writes runs without internet access.
How approvals and tool limits work- Automatic learning
- Every edit or correction to agent work becomes a lesson automatically. Agents use relevant lessons on future jobs, with no separate training task.
- Your data and procedures
- Your business keeps its data, procedures and the knowledge built from corrections. The details of how your team works stay in your workspace.
- Choose review steps
- Add, remove or move a review step. You can try the draft on past jobs before publishing the change.
- Calls ask first
- Every call through a connection waits for a person until someone decides it can run on its own. No agent can make that decision.
- Keys stay sealed
- An agent knows a connection only by its name. The key is added on the server as each call goes out.
- Run records
- Each run keeps its steps, calls and answers. A hash-chained record makes changes to recorded events detectable.