Agents
A single agent holding an entire codebase in context misses things. Focused agents with narrow context windows catch what broad agents miss. TRW ships 12 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.
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
Auditor verifies integration
Before delivery, trw-auditor checks that all agent outputs wire together correctly against the PRD acceptance criteria.
> Create a TRW workstream plan for sprint-79.yaml
[Primary] Reading sprint plan: sprint-79.yaml
[Primary] PRDs to implement: PRD-CORE-092, PRD-CORE-094
[Primary] Creating 3 role-scoped workstreams with explicit ownership...
Task 1: impl-092 → trw-implementer
Files: src/agents/, data/agents/
Contract: 5-agent roster, PREDECESSOR_MAP exported
Task 2: audit-092 → trw-auditor
Files: (read-only verification)
Blocked by: Task 1
Task 3: review-094 → trw-reviewer
Files: (read-only review)
Contract: rubric scores for all changed modules
[implementer] Task 1 complete. Build check: PASS (1337 tests, 94% coverage)
[auditor] Task 2 complete. All FRs verified. 0 spec gaps.
[reviewer] Task 3 complete. Rubric scores: correctness 9/10, security 10/10.
[Primary] Integration check: all contracts satisfied.
[Primary] Sprint delivered. 2 PRDs, 0 integration gaps.Core sprint roster
These five roles cover most implementation sprints. Each one has a single mandate, a defined trigger condition, and worktree isolation for parallel work.
| 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.
| 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-code-simplifier | Targeted cleanup helper that simplifies code without changing behavior. | Post-implementation simplification passes | 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:
- Work cannot be marked complete until trw_build_check records passing validation evidence
- Idle or stalled workstreams get nudged when automation is available
- trw-auditor verifies integration across all role outputs before delivery
- Each agent performs FR-by-FR self-review before marking work complete
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.