Skip to content
Typillar Typillar Typillar

The build loop

The build loop is the engine of Typillar. It’s the same sequence every time, which is what makes the system predictable: you always know where a request is, what’s been decided, and what happens next.

The five stages

Section titled “The five stages”

1. Intent

Section titled “1. Intent”

You describe an outcome in plain language. Intent can be a whole product (“a link-in-bio site”) or an increment to an existing one (“add a contact form that emails me”). You never have to express it as a ticket — that’s the agent’s job.

2. Proposal

Section titled “2. Proposal”

The product-manager agent converts intent into a ticket: a concrete, scoped, named unit of work with a short rationale. Proposals are where ambiguity is resolved — the agent makes the implicit explicit so you’re approving a specific thing. See Tickets & approvals.

3. Approval

Section titled “3. Approval”

You approve (or decline) the ticket. This is a hard gate: no code is generated, no resource is created, and nothing is deployed until you approve. Approval is how you control direction, cost, and timing.

4. Build

Section titled “4. Build”

Builder agents implement the ticket:

  • Generate the code, using inference that runs on your side (Models & API keys).
  • Provision what the feature needs on your Cloudflare account — a database, a Durable Object, a scheduled trigger.
  • Commit the source to your GitHub repository as ordinary commits.

5. Ship

Section titled “5. Ship”

The build is deployed to a live URL on your Cloudflare account and recorded in the project history. From the moment it ships it is reversible — see Deploys & rollback.

Why the gate matters

Section titled “Why the gate matters”

The approval gate between Proposal and Build is the most important line in the loop. It keeps an autonomous system from running ahead of you: agents can propose freely and continuously, but they only act on what you’ve approved. That’s what makes “always-on agents” safe to leave on.

The loop has a memory

Section titled “The loop has a memory”

Each pass leaves a durable trail — an approved ticket, commits, a deployment. Because that history persists, the PM agent can reason about what already exists and propose sensible next steps, and you can always trace how the product got to its current state. The loop doesn’t just produce output; it builds a record.

Section titled “Related”