Agent 4: Solution Architect

Requirements → Stack & Blueprint

Role

The Solution Architect takes the unified specification from Agent 3 and designs the optimal modern implementation. This is a greenfield design — no legacy constraints, no backward compatibility requirements, no "we have to use this because the old system used it."

The architect selects the best tools for the job in the current technology landscape, not the landscape that existed when the legacy system was built.

---

Inputs

• Unified requirements specification (Agent 3)
• Organizational constraints (cloud provider preferences, compliance requirements, team skills)
• Non-functional requirements (performance, scalability, security, availability)

---

Outputs

Tech Stack Recommendation

A justified selection of technologies:

Layer	Technology	Rationale
Frontend	React / Next.js	Component model matches screen inventory; SSR for performance
Backend	Node.js / Go	API-first architecture; Go for compute-intensive services
Database	PostgreSQL + Redis	Relational for business data; Redis for session/cache
Infrastructure	AWS / GCP	Client preference; containerized with Kubernetes
CI/CD	GitHub Actions	Pipeline-as-code; integrates with deployment targets

Each selection includes:

• Why this technology (not just what)
• How it maps to specific requirements from the spec
• Migration path if the technology needs to change later

System Architecture

A complete architectural blueprint:

• Service boundaries and responsibilities
• Data flow between services
• API contracts (OpenAPI specifications)
• Event-driven communication patterns
• Authentication and authorization architecture
• Caching strategy
• Error handling and resilience patterns

API Contracts

Fully specified API definitions for every service boundary:

POST /api/orders
  Request: { customerId, items[], discountCode? }
  Response: { orderId, status, totalAmount }
  Rules: BR-001 (discount cap), BR-003 (approval routing)
  Auth: CSR, Manager

Every API endpoint traces back to specific business rules and user journeys from the spec.

Data Schema

The database design — normalized for the business domain, not copied from the legacy schema:

• Entity-relationship diagrams
• Table definitions with constraints
• Index strategy for query performance
• Data migration plan (how to move data from legacy to new schema)

Build Plan & Sequencing

The order in which the Builder Fleet should construct the system:

1. Foundation — infrastructure, CI/CD, authentication, core data models
2. Critical path — the most important business workflows, built and testable first
3. Breadth — remaining features, built in parallel where possible
4. Polish — reporting, admin tools, edge case handling
5. Hardening — performance testing, security audit, operational readiness

---

Methodology

Phase 1: Constraint Analysis

Understand the non-functional requirements and organizational constraints before making technology decisions. A perfect architecture that the organization can't operate is useless.

Phase 2: Domain Decomposition

Divide the unified spec into bounded contexts — natural groupings of related business capabilities. Each bounded context becomes a candidate service or module.

Phase 3: Technology Selection

Match technologies to domains based on requirements. Not every service needs the same stack. A compute-intensive rules engine might use Go while a CRUD-heavy admin interface uses a full-stack framework.

Phase 4: Blueprint Assembly

Compose the architecture from domain boundaries, technology selections, and integration patterns. Every decision is documented with rationale.

---

Human Validation Gate

Before the Builder Fleet begins construction, the AI Software Lead:

• Reviews the tech stack against organizational capabilities
• Confirms the architecture supports all critical non-functional requirements
• Validates API contracts against the unified spec
• Approves the build sequencing and phasing strategy
• Ensures the data migration plan is feasible

---

Next: Agent 5 — Builder Fleet →