A website agent needs a release process

“It's live” should describe the website, not the agent's mood after a successful command.

An agent can edit a homepage, pass a build, push a commit, and still be wrong about what visitors see. Each step establishes something. None automatically establishes the next one.

That gap matters more as agents take on bigger chunks of website work. The speed is useful. So is being able to tell which version shipped, what was checked, and how to recover without trampling someone else's changes.

You don't need a release department. You need a path from the approved change to the actual public page.

Know what you're shipping and what was already there

Imagine a small marketing-site update: a homepage hero, a services card, and a corrected contact link. Those three changes are approved for production. The visual system stays as it is.

That's a workable scope. “Clean up the site and deploy” leaves much more room for the agent to develop a sudden interest in your navigation architecture.

Record the repository, affected routes, intended result, and destination. Carry forward permission already granted for that work. Repeatedly asking whether an approved release is approved adds friction without adding judgment.

If only a local draft was authorized, finish the reviewable candidate before asking for the missing publication decision. Agent governance should make the boundary usable.

A checkout can contain more than your task

Before editing, inspect the current revision, modified files, new files, and last known production deployment. The local checkout and public site may already differ.

Git status distinguishes staged, unstaged, and non-ignored untracked work. It doesn't tell you who owns each change or stop someone else from editing.

Git diff also depends on what you ask it to compare. A plain diff, a staged diff, and a comparison between commits show different things.

Read the complete changed-file inventory, then the exact candidate. An unfinished navigation change from another person shouldn't disappear—or get shipped—because it happens to be nearby.

Choose the starting state deliberately. Starting from production can omit approved work that exists only on disk. Starting from the working tree can include unrelated changes.

“Stage everything” is wonderfully efficient if everything actually belongs in the release. Establish that before using it as a shortcut.

Back up the state you might need back

A commit ID doesn't preserve uncommitted files. A Git bundle preserves Git references and objects, not the working tree and index state.

That distinction matters when the asset you need was created ten minutes ago and has never been committed.

For a scoped website change, preserve the relevant source and assets, their original paths, and hashes of the copied bytes. Keep backups in an authorized location outside served and published paths.

Check that the copies match and can be read or restored into a separate safe location. Testing recovery by overwriting the active checkout would be a memorable way to discover a bad backup.

Hash equality proves the captured bytes survived the copy. It doesn't prove you captured every dependency or a coherent snapshot while other people were writing. Coordinate a stable capture point or recheck files that changed during the copy.

The recovery notes should answer three questions:

• What source and assets did we preserve?
• What external state isn't covered?
• Which known deployment could restore the previous presentation?

Check the baseline again before release. If production or an affected file changed while you worked, inspect that difference. A safe starting point needs to be understood, not merely old.

This is the state awareness behind agent workflows that stick. The agent needs to know where it is before choosing the next action.

Review the candidate, including the part people see

Read the project's scripts and run the checks that apply: build, types, lint, and relevant tests. Don't assume one command covers them all.

The Next.js production checklist recommends a production build and testing in a production-like environment. A passing build is useful. It can't tell you that the headline is persuasive or the mobile button is easy to tap.

For our example, the review is small and concrete:

Change	Check
Homepage hero	Approved copy, hierarchy, wrapping, desktop and mobile layout
Services card	Accurate content, layout, correct destination
Contact link	The intended page actually opens

Use validators for things they can inspect reliably: required fields, routes, supported structures, known prohibited output. The pre-publish QA gate still needs human judgment about meaning and claims.

Use the interaction you changed

Open the routes at a representative desktop width and a narrow mobile width. Read the page. Look for overflow, awkward wrapping, missing images, and controls covered by other content.

If a tab, menu, or form changed, exercise the affected behavior. A screenshot of the default state doesn't test the second tab.

Keep external effects in view. A preview can still connect to a real CRM, email service, or database. Use an authorized test destination when submitting a form. For this link-only change, sending a real message would add no useful evidence.

Content QA works the same way: different checks answer different questions. Rendering a form isn't proof that delivery works. A source link isn't proof of the claim next to it.

Keep review attached to a version

Record the source revision or artifact and the deployment used for review. If the candidate changes afterward, rerun the checks affected by the change.

Vercel's environment documentation distinguishes moving branch-preview URLs from specific commit deployments. It also describes environment variables and staged production deployments.

A saved preview link may show a newer candidate tomorrow. A preview environment may behave differently from production today.

Inspect the actual project and destination before deploying. Vercel also documents that a new project's first deployment is production even without the usual production flag. A staged production deployment can use production services before the public domain points at it.

The label “preview” isn't a substitute for knowing what the deployment can touch.

Finish at the public URL

After the authorized release, identify the resulting deployment and confirm its project, environment, source association, and completion state.

Vercel deployment inspection can retrieve a deployment by URL or ID, wait for completion, and show build logs. A dashboard or API can provide equivalent evidence.

Then open the actual public origin and changed paths. Check the distinctive approved copy, assets, status or redirect, and relevant behavior. Follow that contact link again.

These are separate observations:

Observation	What it establishes
Commit pushed	The remote received the source change
Deployment completed	The host built and completed that deployment
Production assignment confirmed	The intended domain points at the deployment
Public page checked	The visitor-facing destination returned the expected result when inspected

If old content appears, investigate identity and domain assignment before firing off another deployment. Then inspect response behavior and caching.

Vercel's cache-control documentation separates browser and CDN policies. An HTTP 200 can contain the wrong page. One cache-busting request also doesn't prove every visitor receives the same version.

An interrupted command is another reason to inspect before repeating it. The deployment may have succeeded even if its response never arrived.

The agent's final report should describe the state it observed. “Pushed; deployment pending” is useful information. “Live” is a different claim.

Recovery needs to undo the actual problem

For a presentation defect, restoring a known working deployment may be sensible. For a narrow content error alongside newer valid work, a corrective release may preserve more of the current site.

Choose based on the change, not on which button is easiest to find.

Vercel's Instant Rollback guidance describes restoring an eligible earlier production deployment and warns about compatibility with changed external APIs, databases, and CMSes. The restored deployment retains its original environment values.

Its documentation also says rollback disables automatic production-domain assignment until a later promotion restores it. Don't assume the next push will automatically put the correction live.

More broadly, deployment rollback doesn't unsend email, reverse a CMS edit, or restore database records. Those effects need their own recovery procedures and responsible operators.

Git revert creates new commits reversing selected earlier changes. It doesn't deploy itself or erase external effects. Review the corrective diff against current work, then verify the public result again.

Leave a short, useful receipt

The next operator needs the release story, not a transcript of every command:

• What changed and where it was authorized to go.
• The starting revision and previous production deployment.
• Backup location, coverage, and verification.
• The exact reviewed and deployed candidate.
• Checks performed, with URLs and results.
• Recovery target, constraints, and open items.

Keep credentials and private material out of public records. State what remains unverified. Checking three routes proves something about those routes at that time; it isn't a lifetime warranty on every visitor journey.

That receipt becomes operational documentation the system can use. It also makes the next release easier to understand.

If you want help building this release path, bring one small change and how it currently reaches production. The agent can do a lot of the work. The process should make its last sentence earn the words “it's live.”