Agent 3: Requirements Synthesizer
Logic + Interface → Unified Specification
Role
The Requirements Synthesizer is the convergence point. It takes the business logic from Agent 1 and the user intent from Agent 2 and weaves them into a single source of truth — a unified specification that is complete, consistent, and ready for architecture.
This is where contradictions surface. The code says one thing. The UI implies another. The stakeholders remember a third. The Synthesizer doesn't hide these conflicts — it flags them for human resolution.
Inputs
- Business rules catalog (Agent 1)
- Workflow maps (Agent 1)
- Data entity model (Agent 1)
- Screen inventory (Agent 2)
- User journey maps (Agent 2)
- Input/output specifications (Agent 2)
- Role-permission matrix (Agent 2)
Outputs
Unified Requirements Specification
A complete, structured document that describes what the new system must do — expressed in business terms, not implementation terms.
The spec is organized by:
- Domain (Customer, Order, Pricing, Reporting, etc.)
- Capability (what the system must do)
- Rule (the specific logic governing the capability)
- User story (who needs it and why)
Logic-to-UI Mapping
A cross-reference table showing exactly which business rules manifest in which user interactions:
| Business Rule | UI Manifestation | Gap Status |
|---|---|---|
| BR-001: 15% discount cap | Pricing screen validation | Covered |
| BR-003: $10K approval threshold | Approval queue routing | Covered |
| BR-047: Quarterly rebate calculation | No UI — batch process | Background rule |
| BR-089: Archive after 7 years | No UI, no batch found | Potential orphan |
Gap Analysis
Identifies three categories of gaps:
- Missing rules — UI actions that have no corresponding business rule (the code doesn't enforce what the UI implies)
- Hidden rules — business rules with no UI representation (background processes, batch jobs, database triggers)
- Contradictions — where the code, the UI, and stakeholder understanding disagree
Ambiguity Flags
The most critical output. For every item the Synthesizer can't resolve with certainty, it produces an ambiguity flag:
| Flag ID | Category | Description | Resolution Required |
|---|---|---|---|
| AMB-001 | Contradiction | Code allows 20% discount but UI caps at 15% | Business owner decision |
| AMB-002 | Missing context | Archive rule references "compliance policy v3" — policy not found | Compliance team interview |
| AMB-003 | Orphaned logic | Three functions handle date parsing differently | Determine canonical behavior |
These flags are the agenda for the human validation gate. They represent the questions that only humans can answer.
Methodology
Phase 1: Alignment
Map every business rule from Agent 1 to its corresponding UI element from Agent 2. Identify covered rules, uncovered rules, and orphans in both directions.
Phase 2: Synthesis
Merge aligned items into unified requirement statements. Each requirement captures: the business intent (from rules), the user experience (from journeys), and the data model (from entities).
Phase 3: Conflict Detection
Systematically compare the three sources of truth — code, interface, and stakeholder knowledge — to identify contradictions. Every conflict becomes an ambiguity flag.
Phase 4: Specification Assembly
Organize the unified requirements into a structured specification document. The spec must be readable by both technical and business stakeholders.
Human Validation Gate
This is the most important gate in the pipeline. Before Agent 4 designs the architecture, the AI Software Lead must:
- Review the unified spec for completeness
- Resolve every ambiguity flag (with stakeholder input)
- Confirm the gap analysis — are "orphaned" rules truly orphaned, or just undocumented?
- Sign off that the spec represents the desired system, not just the existing one
- Identify any new requirements not present in the legacy system
The spec that exits this gate is the contract for everything that follows.