Agent 5: Builder Fleet
Blueprint → Working Software
Role
The Builder Fleet is not a single agent — it's a coordinated swarm of coding agents that construct the greenfield application in parallel. Backend, frontend, database, integrations, CI/CD, documentation — all built simultaneously from the architectural blueprint.
This is the stage where the Phoenix rises. No legacy code is referenced. No old patterns are preserved. The Builder Fleet constructs a modern system from a modern blueprint, using modern tools and patterns.
Inputs
- System architecture and tech stack (Agent 4)
- API contracts and data schema (Agent 4)
- Build plan and sequencing (Agent 4)
- Unified requirements specification (for business rule implementation)
Outputs
Production Codebase
A complete, working application:
- Clean, well-structured source code following modern patterns
- Comprehensive inline documentation
- Unit tests for every business rule
- Integration tests for every API endpoint
- End-to-end tests for critical user journeys
Deployment Pipeline
Fully automated CI/CD:
- Build, test, and deploy on every commit
- Staging environment for validation
- Production deployment with rollback capability
- Environment-specific configuration management
Documentation
- API documentation (auto-generated from OpenAPI specs)
- Developer onboarding guide
- Architecture decision records (ADRs)
- Operational runbook (monitoring, alerting, incident response)
Infrastructure-as-Code
Everything needed to provision and run the application:
- Container definitions (Dockerfile, docker-compose)
- Orchestration configuration (Kubernetes manifests or equivalent)
- Cloud resource definitions (Terraform, CloudFormation, or equivalent)
- Monitoring and alerting setup
How the Fleet Works
Parallel Construction
The Builder Fleet divides the build plan into independent work streams that execute simultaneously:
Stream 1: Database schema + migrations + seed data
Stream 2: Backend services + API implementation
Stream 3: Frontend application + component library
Stream 4: Authentication + authorization
Stream 5: Integration adapters (external APIs, file transfers)
Stream 6: CI/CD pipeline + infrastructure
Stream 7: Test suites (unit, integration, e2e)Each stream follows the same pattern:
- Read the relevant section of the blueprint
- Implement the specified behavior
- Write tests that validate the implementation against business rules
- Produce documentation
Coordination Protocol
Streams that share boundaries (e.g., frontend needs API contracts from backend) coordinate through the architectural blueprint — the contracts are defined before building begins, so each stream builds to the same specification.
Quality Enforcement
Every line of code produced by the Builder Fleet must:
- Pass linting and formatting checks
- Have corresponding test coverage
- Trace back to a specific requirement in the unified spec
- Follow the patterns established in the architectural blueprint
What the Builder Fleet Doesn't Do
- Reference legacy code — the fleet builds from the blueprint, never from the old codebase
- Make architectural decisions — those were made by Agent 4 and approved at the gate
- Interpret business rules — the rules are already extracted, synthesized, and specified
- Compromise on quality — no shortcuts, no "we'll fix it later," no technical debt
Human Validation Gate
Before passing to validation, the AI Software Lead:
- Reviews critical code paths (business rule implementations, security boundaries)
- Confirms the build matches the architectural blueprint
- Verifies test coverage meets the defined threshold
- Validates that the deployment pipeline works end-to-end
- Spot-checks documentation quality