NOTE: Demo visuals include blurred data or synthetic placeholders to protect customer privacy.
Why Single Agents Stalled
Earlier iterations proved that code could generate customer-facing pages. Content could be written, and layouts could be produced. But the system was doing too much at once.
One agent was responsible for understanding product changes, writing marketing content, structuring the page, and handling design decisions. That created friction. Improvements to one part of the page often disrupted another. Updating the copy could break the layout. Adjusting structure required rewriting content.
The issue was not capability. It was coordination.
Three challenges became clear:
- Content quality and layout quality require different types of reasoning
- Hardcoded workflows made iteration slow and fragile
- A single system handling everything created tightly coupled outputs
To move forward, the system needed clearer roles.
A Writer and a Builder
This iteration introduces a dual-agent architecture inspired by a simple idea: great teams rely on complementary roles.
The writer agent focuses on substance. It ingests GitHub PRs and their context, then produces structured, product-marketing content. It does not concern itself with layout or animations. Its job is clarity and accuracy.
The builder agent focuses on experience. It takes the writer’s output from the CMS and applies design principles, components, and interaction patterns to render a finished page on the website.
Between them sits the CMS, which acts as the connection point. The writer agent outputs clean, structured content, typically in markdown. The builder agent reads that content and interprets it using shared design inputs.
Guiding both agents is a key input that functions as a constraint rather than an instruction. These inputs define expectations for structure, design, and quality, allowing agents to operate independently while remaining aligned.
This separation allows each agent to specialize while still contributing to a single output
What the Demo Shows
In the demo, Brandon walks through a newly generated product page built entirely by the system. The writer agent produced structured sections, FAQs, and flow. The builder agent transformed that content into a full-page layout with motion and visual hierarchy.
The output is not final. Some assets are placeholders. Some animations stand in for real screenshots. But the signal is clear. In one week, the system moved from isolated pages to coordinated generation.
The CMS view shows the simplicity underneath. What looks like a polished page starts as plain content written via API. That separation makes iteration faster and failures easier to diagnose.
Scaling Without Micromanaging
This episode also sharpens the long-term direction. The goal is not to remove humans, but to move them upstream. Humans define inputs, review outcomes, and evolve standards. Agents handle execution.
Brandon outlined near-term next steps:
- Expanding coverage across the entire site
- Improving image and asset generation
- Porting legacy content into the new system
- Running agents on a daily cadence for continuous improvement
He also hinted at a powerful extension: dynamically generated, customer-specific sites. With the same architecture, the system could generate tailored pages or domains on demand based on internal customer context.
From Pages to Plays
Episode 3 marks a shift in the series. The work moves from generating individual pages to building systems that coordinate multiple responsibilities.
Earlier iterations demonstrated how code can be structured into content and feature pages. This version extends that foundation by introducing agent collaboration, allowing the system to scale both quality and complexity.
The result is not just faster page generation, but a system that can evolve without breaking as it grows.
From individual outputs to coordinated execution.
