Part III
Compare — Evaluate workflows and scaling responses#
Implementations A and B expose what changed across two single-agent development systems, but they do not yet show what orchestration adds or costs. Compare produces implementation C through a declared agent fleet, applies common scaling pressures to all three applications, and turns their evidence into a justified target architecture and development workflow.
III.1 From orchestration to an evidence-based decision#
The three chapters form one progression:
- When do agent fleets improve web development? grows one agent into a bounded fleet, makes authority and integration explicit, and treats failure correction as part of implementation C.
- How should web applications respond to scaling pressure? identifies approaching limits, applies formal models, and compares possible responses without treating a technique catalog as a design.
- What do three agent-assisted implementations teach us about web scalability? connects the application, development, and agentic loops and turns the three evidence packages into a final decision.
Complete Compare with implementation C and its fleet trace, a three-way application and workflow comparison, and a target design whose claims distinguish observation, inference, and proposal.
III.2 Implementation C — Work Activity Tracker#
The Compare project specification defines the third fresh implementation and its bounded fleet workflow. The common behavior, permitted acceptance material, pressures, and reporting categories remain stable while delegation, orchestration, authority allocation, integration, and fleet controls vary deliberately. When practical, use the same foundation model as implementation B so orchestration is the primary changed variable; otherwise record the configuration difference and narrow the comparison claim.
Implementation C also turns its development process into application data. A transformed fleet trace is loaded into the Work Activity Tracker so its history, filters, and relationships can expose attempts, failures, handoffs, validation, correction, and human intervention. Use that view to locate where coordination failed and which correction worked.
III.3 Compare applications and development systems#
Explain what each setup made easier or riskier, which application architecture best fits the selected pressure, and what the team can sustain.
Record architectural, configuration, and practice differences as alternative explanations for the result. The final decision should name the conditions under which you would choose the application and development workflow.