Evaluate a subagent across its lifecycle
A subagent is not only a prompt; it is a team artifact. Create, test, version, review, update, and remove it when needed. Evaluation asks whether the role is more predictable and useful than an ordinary prompt in a fresh session.
One useful finding does not justify an agent that creates noise or violates its boundary.
Lifecycle evaluation
- Define representative tasks and expected outputs.
- Run the role with the minimum tools.
- Record findings, false positives, missing evidence, and time cost.
- Check that the role stops at its boundary.
- Have a fresh reviewer inspect the instruction and output.
- Decide whether to keep, narrow, improve, or remove it.
- Record the decision and next review point.
Useful evaluation signals
| Signal | Question |
|---|---|
| Usefulness | Does it answer the defined question? |
| Evidence quality | Can another person verify the result? |
| Boundary safety | Did it stay within tools and scope? |
| Noise | How many findings are irrelevant or duplicated? |
| Repeatability | Does it behave consistently on comparable inputs? |
| Handoff quality | Can the owner act on the next step? |
Evaluation record
# Agent evaluation
Role: <name>
Scope: <files or workflow>
Input: <representative task>
Expected result: <contract>
Checks: <commands or review>
Observed result: <facts>
Unknowns: <not verified>
Decision: keep / narrow / improve / remove
Status: documented example; adoption result: Unknown.Stop conditions
- The role needs broader permissions than its stated outcome.
- The report cannot separate evidence from hypotheses.
- False positives outweigh useful findings.
- A reviewer cannot reproduce important claims.
- No owner can maintain or disable the agent.
Canonical lesson source · JavaRush
Open JavaRush material