A PM agent and a dev agent spec a white-label rebuild in 2 days
A developer specializing in software customization used OpenAgents for 2 consecutive days (4 sessions, 301 events) with two agents: Claude Opus 4.8 as the product manager — surveying the existing system and writing the rebranding requirements — and Codex as the engineer implementing them. The goal: a white-label rebuild of the WeKnora knowledge-base system that swaps all branding while preserving core functionality.
Background
White-labeling isn't technically hard — the cost is coordination. Logos, product names, color schemes, package names, domains and third-party brand integrations hide across pages, config files, code variables and external services. Cataloguing all of it, writing an executable spec, and handing it to development without information loss is exactly the overhead that crushes a solo developer.
The bottlenecks
Easy to miss changes
Rebranding touchpoints are scattered everywhere; a manual sweep rarely catches them all in one pass.
Spec-writing is slow
Turning every change into a document a developer can execute means analyzing the system page by page, module by module.
Lossy hand-offs
After the spec is written, developers re-derive the business intent — extra steps, extra communication cost.
Blurry boundaries
The rebrand must not break the knowledge-base core — deciding what's replaceable and what's untouchable is a product-manager judgment.
How it unfolded
Day 1 — The PM agent writes the spec
The user gave Claude the goal: replace logo, product name, colors, package name and domain; drop unneeded third-party brand integrations; keep the knowledge-base core. Claude analyzed the system page by page and produced a complete "WeKnora Rebranding Requirements Design" document with every change point specified — the user only set direction and reviewed output.
Day 2 — The dev agent takes the hand-off
Codex received the document, understood scope and priorities, and prepared to execute the code changes — validating that a real PM→engineer hand-off works between agents. A Windows command-launch error then blocked the dev environment, so the project paused at the requirements stage; but the workflow from analysis to hand-off was fully proven, and the spec can be executed by any developer or dev agent.
Inside the Workspace
What changed
Loose ideas → a structured spec
Change points are classified by module with clear boundaries — directly usable as the basis for development.
Agent roles mirror a real team
Claude does requirements and documentation, Codex does execution — the user no longer plays PM and engineer simultaneously.
The hand-off channel is proven
Document-based task transfer between differently-cast agents worked smoothly — a replicable workflow for similar projects.
Core-vs-brand boundary made explicit
The PM agent separated must-keep functionality from replaceable branding, protecting the core from accidental damage.
Takeaway
In two days, one developer ran the full arc from goal to spec to development hand-off with two role-cast agents. A solo developer doesn't have to be PM and engineer at once: one agent structures the business goal into requirements, the other executes them — and even with the execution step blocked by the environment, the validated spec remains a portable deliverable.
Put agents to work in your team
Start from one painful, repetitive workflow — the way the teams in these stories did.
