Blog / From prompt to production in one call

From prompt to production in one call

· Ryan Detzel Engineering

Let me show you the thing that, the first time it worked end to end, made me sure this was worth building. Not the architecture. The moment. You tell your agent "ship me an app," and a minute later there's a real URL you can click, backed by a real repo, a real database, and a real domain. No dashboard. No wizard. No copy-pasting a connection string.

Here's what's actually happening underneath that one sentence.

One call does the whole first mile

The shortcut is a single tool: start_project. From the agent's side it's one call with a name. From the platform's side it's the entire cold-start of a web app:

  1. Create a GitHub repo.
  2. Scaffold a starter template into it.
  3. Provision an app wired to that repo.
  4. Deploy main behind a health gate.
  5. Attach a domain.

Five steps that, done by hand, are five context-switches across five consoles. Done by the agent, they're one structured call that either succeeds or tells you exactly where it stopped. The app comes up at its URL and the agent moves on to the next thing.

The build is the slow part, so you get to choose how to wait

Building and deploying takes a minute or three. That's the genuinely slow step, and it can outlast your client's request timeout. So start_project gives the agent two honest options instead of one opaque hang:

Either way there's no mystery. If the call seems to hang, the deploy is still running server-side, and because everything is idempotent on the name, the agent can just re-run start_project with the same name and pick up where it left off. (With wait: false the domain route is deferred until the build exists. Once the deploy is done, one reconcile_project call attaches it.)

Failure is a resumption point, not a dead end

This is the part that matters most for an agent, and the part most automation gets wrong. When a multi-step workflow fails, the worst thing it can do is fail opaquely ("something went wrong"), leaving the agent to either give up or blindly retry the whole thing from zero.

start_project never does that. If a step fails, it returns { ok: false, failedAt, partial }: a machine-readable marker of exactly which step broke and what already got created. The agent reads failedAt, fixes the specific thing, and resumes by calling the failed primitive directly, or just re-runs start_project (create-repo and create-app are idempotent on an existing name). A half-built project isn't wreckage to clean up. It's a checkpoint to continue from.

That's a deliberate design rule, not a nicety: no agent dead-ends. Every workflow has to let the agent recover by calling the primitive that failed. An opaque failure is a bug.

After the first mile: the primitives

start_project is the on-ramp, not the whole road. Once the app exists, everything else is its own neutral primitive the agent drives the same way: spin up an isolated preview, attach a custom domain, set env vars, hand off a secret it never sees, branch the database, read logs, check health, roll back. The high-level shortcut gets you a running app in one call. The primitives let the agent operate it for the rest of its life, all through the same tool surface, all returning structured output it can branch on.

Why one call matters more than it sounds

It's tempting to read "it's one call" as a convenience: fewer steps, nice. But the real point is what it removes: it removes the human from the critical path of starting. The single hardest place to keep an agent autonomous is the cold start, because that's where all the console-clicking traditionally lives: create the repo here, provision the app there, wire the domain in that other panel. Collapse all of it into one resumable, idempotent, structured call and the agent never has to hand the keyboard back.

That's the whole feeling I was chasing: you point your agent at it, say ship, and watch it ship. Try it and tell me where it surprised you.