Konsol design agents
A multi-agent system that turned product managers' PRDs into screens built from Konsol's own design system — no designer needed in the loop.
overview
- role
- Product designer & engineer
- client
Konsol- period
- Apr — Sep 2026
- scope
- Methodology, agent pipeline, pilot rebuilds
- output
- 3 products, 320+ screens
At Konsol, product managers built new services themselves in Lovable. It was fast, but every screen came out as a one-off: drifting styles, no link to the component library, and a growing pile of UI that was very hard to maintain.
I designed and built the alternative: a design methodology and a multi-agent pipeline that lived inside the company's own workflow. A product manager writes a PRD; the agents brief them on the gaps, design the screens from the design system and review them against the company's rules — then the result moves on to discussion, the task tracker and engineering.
Three products and more than 320 screens were built with the pipeline — including the pilot products that had started in Lovable, which I rebuilt to cut the technical debt they had piled up.
context
Lovable ignored Konsol's design principles and drifted away from its styles, and back then it couldn't work with the company's component library. So each new screen wasn't a composition of existing components but a new piece of work — easy to make and extremely hard to support.
The goal: let product managers ship new services without a designer, while every screen stays built from the design system and fits the production process — discussions, task tracking, handoff to development.
role
I was both the designer and the engineer. I wrote the methodology — the rules, layouts and patterns the agents design by — and built the agent pipeline around it. Then I put real pilot products through it.
process
The pipeline starts with an intake agent. It reads the PRD, normalizes it into tasks for sub-agents and checks whether there's enough objective information to build the product. Where there isn't, it doesn't guess — it asks the product manager questions until the picture is complete. That brief was the main defense against hallucinations.
Designer agents then build the screens only from the design system's components, following the company's UX and UI rules, layouts and patterns. Reviewer agents check the result against those rules and the experience gathered so far.
Every mismatch the reviewers found went into a log the system learned from, so the same mistake became less likely next time.
result
In the lab the results were good: 3 products and 320+ screens came out consistent with the design system and fit the existing delivery process, and the pilot products rebuilt on it carried less technical debt.
In production it met resistance. The process turned out to be too heavy for product managers: with no way to freeze features, it was easier for them to keep releases on track in the tools they already knew. Since this was a trial for the company, Konsol decided not to continue research in this direction. The owner was happy with my work.
lessons
A tool that replaces a designer has to be easier for the product manager than the one it replaces — on day one, in the middle of a release. Next time I would start with adoption: plug into the tools people already use and introduce the heavier process step by step.