Performance Tester agent
The Performance Tester agent finds likely hot paths, quantifies bottlenecks and plans how to check an optimization. It opens and closes Performance Tuning.
The Performance Tester agent looks for what makes software slow. It identifies hot paths, estimates how much each bottleneck costs, and checks whether an optimization should have the effect it claims.
Where it runs
| Workflow | Step |
|---|---|
| Performance Tuning | Profile |
| Performance Tuning | Re-measure |
Performance Tuning has four steps: the Performance Tester profiles, the Architect writes an optimization plan, the Builder describes the change, and the Performance Tester runs again to re-measure.
Inputs
- The session task. The best tasks include real measurements: a slow endpoint, its latency, a profiler output or a slow query log.
- A read-only snapshot of relevant files from the project's repository.
- In the Re-measure step, the optimization plan and the described change.
- Tools from connected MCP servers, if your workspace policy allows them.
Outputs
- Profile: the likely hot paths and why, such as a query inside a loop, repeated serialization or missing caching, with a rough estimate of what each costs.
- Re-measure: an assessment of the planned change against those bottlenecks, the improvement it should give, and what to measure to confirm it.
The Architect's optimization plan is synced to the workspace plan board. The change itself is written by the session's code pass, then tested and reviewed like any other.
Example run
Illustrative example, not a recorded session. Matt reports that the project list page takes four seconds for large workspaces. In Profile, the agent finds that each project row loads its latest session with a separate query, so 300 projects means 301 queries, and that the list is not paginated. The Architect plans a single joined query and pagination. In Re-measure, the agent estimates the query count drops to two, and recommends timing the page with 300 projects before and after, since the new join needs an index to be fast.
Limits
- It does not execute code, run profilers or load-test anything. Its numbers are estimates from reading code.
- Re-measure runs before the code pass writes the change, so it assesses the planned change, not the final diff.
- It cannot see production traffic, data volumes or hardware unless you describe them.
Frequently asked questions
Does the Performance Tester agent run benchmarks?
No. It reads code and reasons about cost. Neither its Profile step nor its Re-measure step executes anything, so treat its numbers as estimates.
How should I get real measurements?
Put measured numbers from your own profiler in the task. The agent works much better from real data, and you can benchmark the resulting change yourself before approving it.