Finalization and the Next Agent

Start by writing down what now exists. Record the live URL, main pages, important redirects, analytics tools, search tools, forms, language versions, assets, and deployment path.

This is not documentation theatre. It is the baseline the next agent should compare against.

If a future run asks, 'What changed?', the answer should not depend on your memory. The launch state should already be visible in the project context.

A website can look finished while the project is still messy. Remove unused drafts, abandoned components, temporary screenshots, dead TODO notes, old prompt fragments, and duplicated assets that no longer explain the final result.

Then check the boring things: broken links, missing alt text, wrong dates, old metadata, placeholder copy, unused redirects, and files that should not be shipped.

This matters because agents read the project as evidence. If the project contains old decisions and final decisions side by side, the next agent may treat both as equally valid.

The next website should not rediscover the same rules. Update the project instructions with the patterns that survived the build.

Capture the stack, commands, folder conventions, naming rules, image rules, component rules, SEO rules, design decisions, and verification steps.

Write these instructions for a future agent that has no emotional memory of the project. It should know what to preserve, what to check, and where it must ask before changing something important.

Good context is not a dump of every file. It is a short, useful explanation of the website as a system.

Write a project summary that answers: what the site is for, who it serves, what the main pages do, what the visual direction is, which tools are connected, which checks matter, and what must not be broken.

Also include lessons from the build. If the footer was tricky, say why. If a language switcher needed a special pattern, record it. If the analytics setup has a manual step, make that visible.

This turns the finished site into reusable memory instead of a pile of completed work.

The next agent should not receive a vague instruction like 'maintain this website'. That is too broad and too risky.

Give it a brief with five parts: the goal, the files it may inspect, the actions it may take, the actions that need approval, and the evidence it must provide before calling the work done.

For example, a safe next-agent brief could ask for a weekly scan of broken links, missing metadata, oversized images, stale screenshots, and unregistered new pages. A risky brief would ask it to change strategy, publish content, or update account settings without review.

Overnight automation is powerful when the task is narrow. It is dangerous when the task is vague.

Good candidates are reviewable checks: broken links, missing images, sitemap drift, metadata gaps, Lighthouse changes, search-console follow-up notes, unused assets, or a draft list of things a human should inspect.

Bad candidates are irreversible or sensitive actions: changing paid campaigns, editing legal pages, publishing new content, deleting files, changing tracking settings, or logging into private accounts without supervision.

A recurring agent should produce a report first. The human decides what gets merged, published, or changed.

The handoff is only valuable if it becomes the first input next time.

When the next website starts, give the agent the final context package before asking for design, code, content, or review. That makes the previous project useful immediately.

This is the real compounding effect of the Website Factory. Every finished site leaves behind cleaner instructions, sharper checks, and a better starting point for the next one.