Agents
Focused roles can reduce context scope and create explicit implementation, review, and audit boundaries. TRW ships 11 bundled agents overall. In practice, most sprints revolve around a recommended five-role lineup, while the rest of the bundle covers explicit leadership, testing, traceability, and specialist requirement work.
Roles are the portable contract
Use helper agents when the client supports them, or run the same responsibilities sequentially. Correctness comes from explicit ownership, evidence, and project-native validation—not a particular model or beta runtime primitive.
Default
Start with the five-role sprint roster.
Execution
Give every active role a clear file scope and handoff.
Expansion
Add specialists only when the work needs a distinct boundary.
How it works
Workstreams follow a role-and-handoff model. The primary agent decomposes work, each specialist receives only the relevant scope, and structured evidence replaces shared mutable state. Parallel helpers and worktrees are optimizations when the client supports them, not prerequisites.
- 1
Primary agent decomposes the work
The orchestrating agent reads the sprint plan and PRD execution plans, then creates tasks with explicit file ownership boundaries for each specialist.
- 2
Each agent gets only what it needs
Implementers receive explicit file sets and acceptance checks. Narrow context means deeper understanding per task; separate worktrees are optional acceleration when available.
- 3
Communication via structured messages
Roles exchange interface contracts and completion signals through checkpoints, PRDs, and review notes. No hidden handoffs.
- 4
Assign an auditor to verify integration
When independent integration review is warranted, assign trw-auditor or an equivalent role to check the combined outputs against PRD acceptance criteria.
# Illustrative portable workstream plan
> Create a TRW workstream plan for sprint.yaml
[Primary] Read the sprint plan and identify independently owned outputs.
[Primary] Assign three role-scoped workstreams when the harness supports helpers.
Task 1: implementation → trw-implementer
Files: declare the exact owned paths
Contract: describe the behavior and proof to return
Task 2: audit → trw-auditor
Files: (read-only verification)
Blocked by: Task 1
Task 3: review → trw-reviewer
Files: (read-only review)
Contract: findings tied to files and requirements
[implementer] Return changed paths and the exact validation command output.
[auditor] Verify the implementation against the current source and acceptance criteria.
[reviewer] Report actionable findings; do not invent a passing verdict.
[Primary] Reconcile outputs, run project-native validation, then record the evidence.Core sprint roster
These five roles cover most implementation sprints. Each one has a single mandate and a defined trigger condition. Assign isolated file ownership when helpers run concurrently; run the roles sequentially when they do not.
trw-implementerInspect
- Role
- Code implementation specialist. Writes production code following TDD, honors interface contracts and file ownership boundaries.
- When to use
- Writing production code, TDD, file ownership
- Model
- frontier
trw-researcherInspect
- Role
- Research and investigation specialist. Explores codebases and the web, gathers evidence, produces structured findings.
- When to use
- Codebase exploration, web research, evidence gathering
- Model
- balanced
trw-reviewerInspect
- Role
- Code review and audit specialist. Read-only, rubric-scored reviews with security auditing.
- When to use
- Rubric-scored reviews, security auditing
- Model
- balanced
trw-auditorInspect
- Role
- Adversarial spec-vs-code auditor. Verifies implementation against PRD acceptance criteria, checks type safety, DRY violations, and error handling.
- When to use
- Spec compliance, type safety, DRY, error handling
- Model
- balanced
trw-prd-groomerInspect
- Role
- PRD drafting and validation specialist. Grooms requirements to sprint-ready quality, manages the full PRD lifecycle.
- When to use
- Requirements engineering, PRD lifecycle
- Model
- frontier
| Agent | Role | When to use | Model |
|---|---|---|---|
trw-implementer | Code implementation specialist. Writes production code following TDD, honors interface contracts and file ownership boundaries. | Writing production code, TDD, file ownership | frontier |
trw-researcher | Research and investigation specialist. Explores codebases and the web, gathers evidence, produces structured findings. | Codebase exploration, web research, evidence gathering | balanced |
trw-reviewer | Code review and audit specialist. Read-only, rubric-scored reviews with security auditing. | Rubric-scored reviews, security auditing | balanced |
trw-auditor | Adversarial spec-vs-code auditor. Verifies implementation against PRD acceptance criteria, checks type safety, DRY violations, and error handling. | Spec compliance, type safety, DRY, error handling | balanced |
trw-prd-groomer | PRD drafting and validation specialist. Grooms requirements to sprint-ready quality, manages the full PRD lifecycle. | Requirements engineering, PRD lifecycle | frontier |
Additional bundled specialists
These agents are still part of the shipped inventory. Reach for them when you want explicit lead/test separation, lighter-weight utilities, or requirement work split into smaller responsibilities.
trw-leadInspect
- Role
- Explicit workstream orchestrator for large sprints and wave-based execution.
- When to use
- When you want a dedicated lead coordinating roles and handoffs
- Model
- frontier
trw-testerInspect
- Role
- Testing specialist focused on PRD acceptance criteria and high diff coverage.
- When to use
- When implementation and test authoring should be split across roles
- Model
- balanced
trw-traceability-checkerInspect
- Role
- Coverage verifier for bidirectional mapping between PRDs, code, and tests.
- When to use
- Validate or deliver phases where traceability is the main question
- Model
- local-small
trw-adversarial-auditorInspect
- Role
- Deeper spec-vs-code auditor used for more aggressive multi-wave verification.
- When to use
- High-risk audits where an extra adversarial pass is worth the cost
- Model
- balanced
trw-requirement-writerInspect
- Role
- Focused FR/NFR drafting helper for expanding or repairing a PRD.
- When to use
- When requirement writing needs to be split from overall grooming
- Model
- balanced
trw-requirement-reviewerInspect
- Role
- Structured PRD reviewer that scores readiness without rewriting the document.
- When to use
- Independent requirement review before sprint planning
- Model
- balanced
| Agent | Role | When to use | Model |
|---|---|---|---|
trw-lead | Explicit workstream orchestrator for large sprints and wave-based execution. | When you want a dedicated lead coordinating roles and handoffs | frontier |
trw-tester | Testing specialist focused on PRD acceptance criteria and high diff coverage. | When implementation and test authoring should be split across roles | balanced |
trw-traceability-checker | Coverage verifier for bidirectional mapping between PRDs, code, and tests. | Validate or deliver phases where traceability is the main question | local-small |
trw-adversarial-auditor | Deeper spec-vs-code auditor used for more aggressive multi-wave verification. | High-risk audits where an extra adversarial pass is worth the cost | balanced |
trw-requirement-writer | Focused FR/NFR drafting helper for expanding or repairing a PRD. | When requirement writing needs to be split from overall grooming | balanced |
trw-requirement-reviewer | Structured PRD reviewer that scores readiness without rewriting the document. | Independent requirement review before sprint planning | balanced |
Formation patterns
Three common workstream shapes. Pick the smallest formation that covers the work.
Solo + reviewer
One implementer does the work, an independent reviewer catches what they missed. The file-ownership contract keeps the handoff explicit.
When: Most common. Single-PRD features, refactors, bug fixes that touch 3-10 files.
Parallel implementers
Each implementer gets exclusive file ownership. Parallel helpers are safe only when scopes do not overlap. The auditor verifies integration seams.
When: Multi-package changes where files have no overlap. API + frontend, or two independent modules.
Full sprint workstream
Dedicated research, implementation, and review roles. Each role has explicit file ownership and a declared handoff.
When: PRD sprints delivering 2-4 PRDs in parallel. Quality-critical or security-sensitive work.
When to use workstreams
Workstreams add coordination overhead. Use them when the benefits outweigh the cost:
- Multi-file features — changes span 3+ files across different modules or packages
- Parallel PRDs — a sprint delivers 2+ PRDs that can be implemented concurrently
- Quality-critical work — security hardening, API migrations, or anything that benefits from independent review
- Large refactors — splitting a god module, migrating a dependency, or restructuring packages
Quality gates
Workstreams keep the same quality bar as solo work:
- Coding delivery requires a passing recorded build check, a valid acceptable-failure record, or an authorized operator/config override with technical rationale
- Idle or stalled workstreams can be nudged when the active harness supports coordination
- Assign an auditor or equivalent review role to verify integration across role outputs
- Require requirement-by-requirement evidence when the work is governed by a PRD
Next steps
Agents make the most sense when you pair them with the requirements they should satisfy, the skills that invoke them, and the tool surface they act on while they work.