Tester agent
The Tester agent writes the test plan and names the test cases that prove a change works. It runs in ten built-in workflows, and your own tests run after.
The Tester agent decides how a change should be proven. It proposes a test plan and the specific test cases that cover the happy path, edge cases and failure modes, and it names the tests.
It is one of the most used agents. It runs in ten of the sixteen built-in workflows.
Where it runs
| Workflow | Step |
|---|---|
| Plan, Build, Review & Test | Test |
| Security-Sensitive Change | Validate |
| Parallel Review | Test coverage review |
| UI Implementation | Behavior test |
| DevOps Change | Validate |
| Swarm Inspection | Tester slice |
| Incident Response | Verify |
| Dependency Refresh | Test |
| Data Migration | Validate |
| Quality-Gated Change | Test |
Inputs
- The session task and a read-only snapshot of relevant files, including existing tests, from the project's repository.
- The earlier steps: the plan, the described change and any review notes.
- Tools from connected MCP servers, if your workspace policy allows them.
Outputs
The Tester's step returns a test plan in text, with named test cases. The code pass that writes the change reads it, so tests the Tester names can end up as real test files in the diff.
Running tests is a separate step. After the code is written, the session's verify step rebuilds the proposed tree inside a sandboxed environment for the project and runs the project's own test command there. A completed run is recorded as a test run on the session, and the release gate requires passing tests before a change can ship. If the tests cannot run, the session records why instead of a result.
Example run
Illustrative example, not a recorded session. In Dependency Refresh, the Migration Specialist has proposed moving a date library up a major version. The Tester lists what could break: parsing of ISO strings with offsets, the formatting of invoice dates, and a daylight-saving boundary in the scheduler. It names a test for each and notes that the scheduler has no existing coverage. The code pass adds two of those tests to the diff. The verify step then runs the project's test suite against the upgraded code and records the result on the session. The Security Auditor checks the upgrade last.
Limits
- It does not execute anything. Its step is a plan; the verify step produces the result.
- Verification needs a test command and an environment that can install the project's dependencies. Without those, the change is not verified, and the session says so.
- Test runs have a time budget. A suite that runs longer is not verified in the session.
- A passing suite only proves what the suite covers.
Frequently asked questions
Does the Tester agent run my tests?
No. It plans them. The session's verify step runs your project's own test command in a sandbox against the code the session wrote, and records the result.
What if my tests cannot run?
The verify step records a skip with its reason, such as no test command or dependencies that will not install. A skip is never shown as a failure, and never as a pass.