Describe the product. Read the repo.
The Builder takes a brief and returns a project: a crew of agents plans it, writes the schema and the server code and the interface, reviews what it wrote, and hands you the files. What makes the result usable is not the model — it is the grounding. The crew recalls from the family’s own documentation and builds on kits that already solve accounts, teams, money and email, so what comes back is an application on a stack that works, not a folder of plausible-looking code.
write_file call, never scraped out of prose — so the transcript of the run and the contents of the repo are the same record. The plan is validated before a single agent starts; a dependency that loops is refused with the cycle named.Anything can write a file. The question is what it was reading.
A general code generator starts from everything it has ever seen and averages. This one starts from one stack it has the documentation for, and a crew whose structure does the supervising: the plan is validated before anything runs, tools are allowlisted rather than requested politely, budgets are enforced, and every step is on the record.
A crew, not a chat window
Four agents with four jobs: an architect that designs routes, schema and which kit carries which concern and writes no code at all; a backend and a frontend that write; a reviewer that reads every file back, fixes what is concretely wrong and stops there. Each one holds its own toolset — the architect cannot write a file, because designing is not writing.
Grounded in the kits’ real documentation
The corpus is the family’s own package documentation, ingested and recalled per question. Ask for teams and the backend agent answers out of tenant-kit’s actual README, not a model’s memory of a package it saw once. Where the documentation is silent, the run says so rather than inventing an API that would fail on first import.
Code arrives as a tool call
Every file is a write_file call — path and contents, one call per file — never a fenced block scraped out of prose by a regex that a stray backtick can defeat. A path that climbs out of the project with two dots is refused and told why, not quietly rewritten into something else. The transcript and the repo are the same record.
It builds from components that exist
The frontend agent reads UI-Kit’s generated component contracts — the same data the design system’s MCP server serves — so it composes fifty real components with their real props instead of hallucinating a prop that never shipped. A design system is a vocabulary; this one is handed over rather than guessed at.
The whole run is kept
The request, the validated plan, every event in order, each file, the summary, and — when a run fails — the reason it failed. A generation is watched, not awaited behind a spinner, and a finished one stays readable afterwards, which is what makes a disappointing result diagnosable instead of merely disappointing.
Your projects, and only yours
Projects belong to a team and carry the same opaque tenant id as everything else on this account, so one team’s brief and one team’s generated code are not another’s to read. When you want the result out, take the whole generation as a zip — it is your repo, not a preview you have to keep visiting.
It runs here. The Builder is this portal’s own cloud product: it lives on the account you already have, so opening it from your dashboard is a link rather than a second sign-in — unlike QuxKit CRM, QuxMail and AI Member Cloud, which run independently with their own. The engine underneath is rag-kit, the family’s multi-agent RAG library, and the Builder is its first product: if you would rather run a crew of your own inside your own repo, that is the page to read instead. Generation needs an inference provider, which is ours to configure here and yours to choose there.
Start from a working application.
Bring a brief. The crew brings the stack, the documentation and the record of what it did — and you leave with the files.