What it produces
- Eight architecture sections, real system design documents: system overview, container architecture, database design, API design, deployment architecture, security architecture, design patterns, and technical risks
- Architecture decision records (ADRs), each captured with its context and consequences
- Infrastructure cost estimates, projecting the running cost of the proposed architecture
Who runs it
The Architect Agent, a system design and technical architecture specialist. One boundary matters: it designs the system; it does not write the app code. Implementation belongs to the Fullstack Builder in the Develop stage. Like the PRD, the architecture document is written behind an outline: the Orchestrator scaffolds the architecture outline, then delegates one section per call (write_architecture_section). Before writing, the agent loads your locked constraints, so the design respects tech-stack facts you have already fixed rather than reinventing them.
What it reads
- The PRD sections from Define
- Structured project constraints
- Locked tech-stack facts
How you steer it
- Lock your constraints first. If you already know the stack, the hosting target, or a hard compliance requirement, get it into the project constraints before the sections are written; the agent reads them before every section.
- Review the ADRs, not just the prose. The decision records are where trade-offs live. Each one states the context and the consequences, which is exactly where to push back if a choice does not fit your situation.
- Ask for the cost estimate early.
estimate_infrastructure_costprojects what the proposed architecture costs to run, and it is cheaper to change an architecture on paper than in production.
Skipping this sub-phase does not mean the build is unplanned; the Fullstack Builder still works from the PRD and the design system. It means the technical decisions are made during implementation instead of being documented ahead of it.