Flow map

Anatomy of a Change Request

What happens after a user asks this platform for a change — the same ask, review, preview, publish loop every time, whether that's a copy edit landing in seconds or a coding agent building a whole new ability. The user never has to care which one they got.

It starts in a chat thread, right on the page — the user types what they want and hits send. What happens next hangs on a classification the user never sees: can the content model already express this, or does the site need a new ability first? That fork is the whole story below. In both diagrams, the top row is what the user sees and the zone underneath is the machinery — one chain of events snaking between the two. First, the easy branch.

Data op

When the ask is content

Ask to change a headline and the fast model calls it in a beat: content edit. It proposes a surgical patch — just the field that was named, deep-merged onto the block instance — and the user accepts it as a draft. That draft is one changes row. A patch and a before. Nothing else moves.

Preview is the real site, server-rendered from the instance's working state — open patches merged, in order, onto whatever's already published. Publish folds the chosen changes into the published snapshot and purges the CDN cache tags for the pages they touch. No build, no deploy — live in seconds. And undo is just as plain: delete the change row, recompute, gone.

Pipeline

When the ask is code

Now ask for something the blocks can't do yet. Same chat, same fast model — but this time it proposes a plan instead of a patch. Two gates stand between that plan and any code: the user approves the plan, then explicitly starts the build. Only then does the hub dispatch a job to the engine, a developer-agent service living on a Mac mini. The engine clones the site's repo and turns a coding agent loose on a branch. An actual build, running unattended.

Mid-build, the agent has to prove its work: it registers a demonstration — real content that shows the new ability off — using a token scoped to this one change and dead the moment the work wraps up. No demonstration, no Preview ready. A build that can't show its work isn't done. Then it commits, pushes, opens a pull request, and waits on CI and a Netlify deploy preview. One failure gets one automatic follow-up; past that, the card says what's true: Needs a person.

Checks green, demonstration registered — the user sees exactly one card: the change, its diff, and a live preview. (That preview is the PR's Netlify deploy preview, because there's no production code that could render this anywhere else yet.) Publish merges the pull request itself, and the demonstration content ships with its capability — the two land together or not at all. And here's the part I love: the merge alone changes nothing a visitor would notice. Content is what makes an ability visible.

Count the cards in the user's row: four for a headline, five for a new ability — and the fifth is just a second go-ahead before a build. Everything below that row is where the two paths really split: a headline dips into a short row of data operations; a new ability dives into a build-test-ship pipeline with an engine, a pull request, and a safety hatch. Both surface at the same word: live. The platform's whole job is making the second path feel like the first.

← All drops