One prompt to launched: inside the 14-agent pipeline

Most AI tools stop at “it compiles.” A model writes a feature, you copy it into your editor, and the rest of the work, the database, auth, the deploy, the domain, something to post about it, is still yours to do. That gap between deployed and launched is where most side projects quietly die.

Moonshift runs that whole stretch as a pipeline of specialised agents. You describe the outcome in plain language and approve a build plan; the pipeline does the rest and hands back a live URL. The point of this post is to open the box and show you what each agent is actually responsible for, and why the work is split up the way it is.

Why split the work into agents at all

A single model asked to “build the whole app” drifts. It forgets its own earlier decisions, contradicts a schema it wrote ten minutes ago, and produces code that almost fits together. The longer the task, the worse the drift. Splitting the work into focused agents with explicit handoffs means each one starts from a clean, written contract instead of a fuzzy memory of what came before.

Each phase reads the artifacts the previous phase produced, a requirements doc, a schema, an API surface, and writes the next artifact in the chain. Nothing is implied. The frontend agent doesn’t guess what the API looks like; it reads the typed routes the backend agent committed.

What the planner actually decides

The planner is the most important agent in the run, because every later decision inherits from it. It turns your sentence into a concrete spec: who the app is for, what screens it needs, what data it stores, and what the first build should and should not include. It also writes the data model, so the database agent has something real to provision against.

This is the plan you approve before the build starts. It’s deliberately legible, no jargon, so you can catch a wrong assumption in ten seconds instead of finding it in the finished app.

• Planner: requirements, data model, page list, and the build plan you approve.
• Database: provisions storage and pushes the schema before any code runs.
• Backend: typed API routes and server logic against that schema.
• Frontend: real screens wired to the API the backend just shipped.
• Tests + security: a gate, not a suggestion, before anything deploys.
• Deploy + launch: a live URL on your infra, plus drafted posts.

Failure is local by design

Because each phase is isolated, a failure is local. A wedged build can’t hold a slot forever, a flaky step retries, and the run keeps a tight budget so it can never surprise you with a runaway cost. A failure classifier sorts errors into transient, deterministic, and permanent, so the pipeline knows the difference between “retry this” and “stop and tell the human.”

Transient errors, a network blip, a rate limit, get a bounded retry. Deterministic errors, a type error the model can see, get handed back to the agent that caused them with the error attached. Permanent errors stop the run cleanly instead of burning budget on a problem no retry will fix.

Every phase writes an event log, so when something does go wrong there’s a precise trail: which agent, which turn, what it tried, and why it stopped. That’s the same data that powers the run replay and the post-run metrics.

“The measure of a run isn’t code generated. It’s whether you can send someone the link.”

The gates before it ships

A build that compiles isn’t a build that’s safe to ship. So the pipeline runs a series of gates between the last line of code and the deploy. Tests run on every build. A security pass scans for the obvious footguns. A design gate scores the result so a generic-looking app gets caught before you see it, not after.

Gates can send work back. If the design score is too low, the run iterates instead of shipping something flat. The point is that the bar is enforced by the pipeline, not by your patience after the fact.

It ends at a link, not a folder

The repo lands on your own GitHub and the app deploys to your own Vercel, so you keep everything. The run finishes by drafting the posts you’ll use to launch, ready for one-click approval. You walk away with a live URL, an owned repo, a provisioned database, and a launch kit.

You stay in control at every step: approve the plan, watch it build, and iterate with plain language. The first version is a starting point, not a final answer, and the rest of the product, replay, the night shift, integrations, exists to take it from there.