The Blueprint — How an Agent Rebuilds a Website From the Ground Up

Positions One Through Five

What Does Each Level of Autonomy Look Like in a Site Rebuild?

The same task — transforming rawweights.com from 40 inconsistent pages into a unified system — looks completely different depending on how much you hand over to the agent.

I mapped the rawweights.com rebuild across five levels of agent autonomy to understand where I was operating at each stage — and where I should have been.

🔍

Position 1

Suggest

Scripted / Rule-Based

The agent crawls all 40 pages and produces a report: "14 pages use a different nav structure. 9 pages have no footer. 6 different heading font sizes in use." It lists everything. It changes nothing. You decide what to prioritise.

Build equivalent

A Lighthouse audit report or a CSS linter output — findings only, no fixes applied.

🖼️

Position 2

Approve

Bare LLM / Chatbot

The agent drafts a new nav component in HTML and Tailwind, shows you a preview with its reasoning: "I used Inter 800 for the brand, matched your existing #0077b5 blue, and grouped the tools into dropdowns." Nothing is written to any file until you confirm.

Build equivalent

Vibe-coding in a chat window — you review the generated code before copying it anywhere.

⚙️

Position 3

Delegate

Agentic Workflow

The agent has standing rules: use the rag-pipeline-toolkit nav as canonical, slate-900 background, Inter font, Cloudflare beacon at the bottom of every page. It applies these to every standard blog page autonomously. It stops and calls you when it finds a page with a custom interactive SVG that doesn't fit the pattern.

Build equivalent

A script with a ruleset that runs on straightforward pages and raises a PR for the complex ones.

📡

Position 4

Monitor

Single Agent

The agent takes ownership of the entire transformation. It builds pages, pushes to staging, runs Lighthouse checks on each, and reports back weekly: "31 of 40 pages migrated. Average Lighthouse score up from 62 to 91. Three pages flagged — links below." You review and approve before anything hits production.

Build equivalent

A CI/CD pipeline with an AI layer — runs autonomously, surfaces results, waits for promotion approval.

🌐

Position 5

Automate

Multi-Agent System

Four specialist agents run in parallel: a design agent handles visual consistency, a code agent implements and lints, an SEO agent rewrites meta tags and adds structured data, a QA agent runs cross-browser and accessibility checks. You see a nightly summary and approve releases. The system alerts you only when agents disagree or hit a blocker they can't resolve.

Build equivalent

A full engineering team replaced by coordinated specialist agents, each with a defined scope and escalation path.

💡

Vibe-coding sits at Position 2

When you paste a prompt into Claude or ChatGPT and get back a redesigned page, you're at Position 2 — Approve. The agent generated the code; you decided whether to use it. The moment you give the agent file access and let it write directly to your repository without showing you each change first, you've moved the dial. Understanding where you are on the spectrum is what determines whether the result is a time-saver or a recovery exercise.

The Control Dimension

Autonomy Without Control Is Not a Shortcut — It's a Rollback Risk

Giving an agent access to your live website files is not the same as giving it the right to use that access freely. Autonomy and control are two separate dials, and only one combination is safe at scale.

⚠️ High Autonomy · Low Control

Agent with Full File Access, No Staging

The agent can read and write any file in the repository. It rewrites all 40 pages overnight and deploys directly to production. By the time you check in the morning, 8 interactive pages have broken carousels and 3 have wrong brand colours. There is no preview, no diff, no way to selectively revert.

Verdict: One bad run away from a full rollback

Sweet Spot

✅ High Autonomy · High Control

Agent Writes to Staging, You Promote

The agent has full access to a staging branch. It rewrites pages, runs Lighthouse, and posts a diff for each page. You review the diff, click approve or reject per page, and only approved pages get merged to main. Speed of automation, safety of review.

Verdict: How production-safe rebuilds work

😐 Low Autonomy · Low Control

Copy-Paste from a Chat Window

You paste a prompt, copy the output, manually edit the file. You're doing all the applying yourself — and you're not really tracking which pages have been updated or how. Low risk per change, high risk of inconsistency across 40 pages.

Verdict: Safe but doesn't scale

🏛️ Low Autonomy · High Control

PR Required for Every CSS Change

Every modification — even tweaking a colour variable — requires a pull request, a peer review, and a CI run before it merges. Maximum visibility, minimum speed. Appropriate when the site has legal compliance requirements or when multiple teams share the codebase.

Verdict: Enterprise compliance environments

← Low autonomy

Autonomy axis

High autonomy →

Inside the Agent's Reasoning Loop

Goal → Reason → Act → Observe → Repeat

When you hand a site rebuild to an agent, it doesn't work through a checklist. It runs a loop — reasoning before each action, observing the result, and deciding what to do next based on what it finds.

Step 1 / 4

Nav centralisation

Scenario — centralising the nav across all 40 pages

Step 1 — Receive the Goal

"Navigation and Footer are maintained at individual page level. Make it centralized, so that modifying in one place gets applied across. Use the Home page Navigation as the correct one."

The agent has a clear goal, a canonical reference (home page nav), and implicit constraints: don't break existing pages, don't remove nav items that are page-specific.

🔄

It loops

Each page the agent touches produces an observation that updates its understanding of the codebase before it moves to the next.

🔧

It uses tools

Reading files, writing files, running Lighthouse, checking git diff, posting a summary — all real actions, not just generated text.

🎯

It recovers

When it finds a page that breaks the standard pattern, it doesn't crash or skip — it flags, adapts its approach, and continues.

What the Agent Remembers

Three Layers of Memory — How the Agent Keeps the Site Consistent

An agent working across 40 pages over multiple sessions has to remember design decisions, brand rules, and exceptions — or it will re-introduce the very inconsistency you hired it to fix.

🗒️

Working Memory

The file currently open on the workbench

Right now, the agent is working on blog/rag-pipeline-toolkit.html. It knows this page uses teal accents, has a 3-column section layout, and a custom tooltip component. This knowledge is immediate and active — it applies only to what is being processed right now.

Lifespan

Current file / current task

What it holds

Page structure, current colour scheme, active components

Risk if lost

Agent re-reads the file — low cost

📋

Session Memory

Everything decided in today's session

In this session you said: use blog.html as the canonical footer, dark mode must store state in localStorage, the guides dropdown should include MCP as the last item, and the Cloudflare beacon script goes at the very end of every file. The agent remembers all of it — until the session closes.

Lifespan

All turns within one conversation

What it holds

Footer source, dark mode approach, nav additions, script order decisions

Risk if lost

Next session reverts to defaults — inconsistency returns

🧠

Long-Term Memory — Two Kinds

The style guide and the decision log

📇 Semantic — The Style Guide

Standing rules with no expiry date. "Brand primary: #0077b5. Background: slate-900. Font stack: Inter + JetBrains Mono. Each page gets a Cloudflare beacon. Nav uses the dropdown grouping JS pattern." These apply to every future page, forever — until you change the guide.

📔 Episodic — The Decision Log

Time-stamped choices. "On 7 June 2026, user said rag-pipeline-toolkit nav is canonical. On 10 June, MCP added to guides dropdown. On 13 June, user specified blog.html footer as the canonical source." These were decisions made at a moment in time — and they override the default.

A well-architected site agent writes both types to a persistent file — a CLAUDE.md or a design-system.json — so every future session starts with a complete picture of every decision ever made.

Your Role During the Rebuild

Reviewer or Dashboard Watcher?

There's a difference between an agent that can't ship without your approval on every file, and one that ships to staging on its own while you monitor for anomalies. Both are valid — for different phases of the same project.

👁️

Human-in-the-Loop (HITL)

The Code Reviewer

Every file change the agent proposes is presented as a diff. You review it, approve or reject line by line, and only then does the agent write the updated version. Nothing touches the live site without your explicit sign-off on each change.

Use this mode when:

→ You're touching complex interactive pages with custom JS
→ The agent is doing something it hasn't done before (new component type)
→ The page has content that must stay exactly as written
→ You're early in the project and still calibrating the agent's rules

📊

Human-on-the-Loop (HOTL)

The CI Dashboard

The agent runs the build pipeline on staging. You check the dashboard once a day: Lighthouse scores per page, diff summary, pages that failed checks. You intervene on the flagged ones; the passing ones promote automatically on a schedule.

Use this mode when:

→ You're migrating straightforward content pages (no custom JS)
→ The agent has been running reliably on similar pages for a while
→ You have automated Lighthouse thresholds as a safety gate
→ You need to process 20+ pages without a per-file review bottleneck

Four hard stops — always require human review before the agent proceeds, regardless of which mode you're in:

🎨

Brand colour changes

Any change to the global colour token or brand primary — ripples across every page

⚡

JS that drives interactions

Carousels, visualisers, SVG animations — breakages here are invisible to Lighthouse

🔗

URL or nav changes

Changing a URL or removing a nav item breaks inbound links — no auto-revert

🌐

Production deploys

Anything that touches the live domain requires a final manual approval — always

Agent Architecture Patterns

Four Ways to Split the Rebuild Across Agents

One agent can handle a small site. But a 40-page rebuild with design, performance, SEO, and QA concerns is almost always better divided. These four patterns describe how.

🗂️

Pattern 1

The Router

Classifies — takes no action

A triage agent reads every page and categorises it: standard content page, interactive tool, guide with SVG visualiser, blog post. It doesn't touch any of them — it routes each to the agent best equipped to handle it.

Page comes in → Router reads structure → Tags it "standard" or "complex-interactive" → Sends to the appropriate rebuild pipeline. Nothing is changed by the router itself.

🧩

Pattern 2

The Orchestrator

Delegates — assembles results

A project-managing agent receives the redesign brief, breaks it into tracks — design tokens, nav standardisation, footer centralisation, page-by-page migration — and assigns each to a specialist sub-agent. It assembles the results and checks consistency before surfacing a summary.

Redesign brief received → Orchestrator breaks into 4 tracks → Each specialist agent runs in parallel → Orchestrator merges outputs and flags any conflicts between them for review.

🔍

Pattern 3

The Supervisor

Monitors — intervenes mid-flight

A watchdog agent monitors the migration in real time. When the mobile menu breaks on a page the code agent just updated, the supervisor detects it via the automated Lighthouse run, pauses that page's deployment, and alerts you — while the other 15 pages in the queue continue uninterrupted.

Code agent updates nav.html → Lighthouse score drops from 91 to 67 on mobile → Supervisor pauses nav.html deploy → Files issue → Remaining 14 pages continue deploying normally.

✅

Pattern 4

The Reflection Loop

Build → critique → improve

A build agent produces the redesigned page. A QA agent then tests it against the design system checklist — brand colours, font sizes, nav structure, Lighthouse score, mobile layout, accessibility. It sends specific failures back. The build agent fixes them. The loop runs until QA has no more objections.

Build agent produces page → QA agent: "H2 uses wrong font weight, mobile padding missing on section 3, meta description over 160 chars" → Build agent applies fixes → QA: approved → Page queued for staging.

What Goes Wrong

Five Ways a Site Rebuild Agent Fails

Every one of these has already happened to someone rebuilding a site with AI. They're not edge cases — they're the default outcome when the right constraints aren't in place.

🎨

Failure 1 — Stale Knowledge

Rolling out a brand colour that was changed two months ago

▼

The agent was trained or briefed on your brand at a point in time. You changed your primary blue from #0077b5 to #005fa3 two months ago. The agent doesn't know. It applies the old value across all 40 pages — perfectly, confidently, wrongly.

The pages look correct to the agent. It followed its design spec to the letter. The spec was just out of date.

Prevention: Keep brand tokens in a single authoritative file — design-tokens.json or a CSS custom properties sheet. The agent reads this file before every session, not its training data. When the file changes, the agent's knowledge updates automatically.

🤔

Failure 2 — Overconfident Assumption

Silently removing content it decided wasn't needed

▼

You asked the agent to "standardise the footer." Several pages had an additional information block above the footer — credits, related links, event-specific notes. The agent decided these weren't part of the "footer" and removed them. It was right by one interpretation and completely wrong by yours.

It didn't ask. It didn't flag what it was removing. It made a judgment call and moved on. The content was gone before you noticed.

Prevention: Instruct the agent to flag — not remove — anything it cannot confidently map to the standard pattern. A line in the brief: "If you find content that doesn't fit the template, create a separate div above the footer and note it for review. Never delete content silently."

🔁

Failure 3 — Infinite Improvement Loop

Iterating the homepage for 6 hours without shipping anything

▼

You asked the agent to make the homepage "beautiful and consistent with the brand." There's no objective definition of beautiful. The agent generates version 1, runs its internal critique, finds improvements to make, generates version 2, finds more improvements... By the time you check in, it's on version 9 and nothing has been written to a file.

This is a reflection loop with no acceptance criteria — the agent can't know when it's done because "beautiful" has no measurable definition.

Prevention: Give measurable done criteria. Not "make it beautiful" but "Lighthouse performance ≥ 90, all headings use Inter 800, hero section matches the reference screenshot, mobile layout reviewed at 375px." The agent can check all of those. It can't check "beautiful."

💥

Failure 4 — Precise Execution of Wrong Instructions

Breaking all animations while "optimising CSS"

▼

You asked the agent to "clean up the CSS and remove anything unused." The agent ran its analysis, identified several @keyframes declarations that didn't match any obvious class names in the HTML, and removed them as "dead code." Those keyframes powered the SVG animations on the interactive visualiser pages. The animations silently stopped working.

The instruction was correct. The execution was correct. The agent's understanding of "unused" was wrong for your specific context.

Prevention: Scope instructions explicitly. "Remove unused CSS classes — but do not remove any @keyframes declarations, CSS custom properties, or classes that are added via JavaScript." Tell the agent what "unused" means in your context, not just the word "unused."

🔧

Failure 5 — Wrong Tool for the Task

Using a text-generation agent to validate real-time performance

▼

You asked your design agent to also check whether the lazy-loading implementation was working correctly. The agent can read the code and reason about whether it looks correct — but it cannot actually load the page in a browser, measure image load timing, or check network waterfall. It reports "lazy loading looks correct" based on code inspection. The images are in fact all loading on initial page load.

The agent gave a confident answer. It was using the wrong method to answer the question. Runtime performance needs a runtime tool — not a code reader.

Prevention: Pair your build agent with a Lighthouse runner or a headless browser tool for performance validation. The code agent writes the code; the performance tool verifies the output at runtime. Different tools for different types of truth.

📐

The compounding accuracy problem in a 40-page rebuild

If the agent is 95% accurate at each decision — choosing the right component, applying the right colour, preserving the right content — and makes six decisions per page across 40 pages, that's 240 decisions. The probability that every single one is correct is roughly 5.5%. Not because the agent is bad — because errors compound. This is why staged rollouts, automated checks after each page, and human review at key gates are not optional overhead. They are the mechanism that keeps the error rate manageable.

The Design Principle

Don't Build a Component Library to Fix One Misaligned Heading

Before spinning up any agent, four questions decide whether you're solving a real problem or building complexity to feel productive.

🧱

Fewest agents that can do the job

One well-scoped agent handling design and implementation for one page at a time beats four parallel agents before you understand any of their failure modes.

🧠

Reasoning matched to the task

A text-swap job doesn't need a reasoning model. A classification step doesn't need a 100K context window. Right-size to the actual requirement — not what you imagine you might need later.

⚖️

Every component earns its place

Add a QA agent only after you've seen what the build agent gets wrong. Add a reflection loop only after you've measured where quality drops. Don't design for failures you haven't seen yet.

🔑

Tool access scoped to the task

Blog redesign agent needs the blog directory and shared components — not credentials, analytics config, or the full repository. Every extra permission is an unexpected failure waiting to happen.

Four questions before you spin up a site rebuild agent

How I apply these principles in practice — from the rawweights.com rebuild

1

Could a find-and-replace script handle this?

If you're swapping one nav HTML block for another across all pages — that's a script job, not an agent job. A sed command or a simple Node.js script is faster, cheaper, and completely predictable. Use an agent only when the task requires judgment.

2

Does this genuinely need multiple specialist agents, or can one handle it?

A multi-agent architecture adds handoff complexity, state synchronisation between agents, and more surfaces for errors to compound. A single well-scoped agent handling design + implementation for one page at a time is often faster and easier to debug than four agents running in parallel.

3

What file access does the agent actually need?

If it's redesigning blog pages, it needs access to the blog directory and the shared component includes. It does not need access to your credentials, your analytics config, or your entire repository. Limit access to the scope of the task. Every extra permission is a surface for an error you didn't anticipate.

4

What's the smallest working version?

Rebuild one page. Run it. See what breaks. Add the QA step only after you see what the agent gets wrong. Add a second agent only after you hit a bottleneck a second agent actually solves. Complexity is a cost — justify it with evidence, not anticipation.

🔗

Related — The Autonomy Dial

The same five levels, explained through travel planning

If the technical framing in this page was useful, the companion page walks through the same five positions, the 2×2 quadrant, the ReAct loop, memory types, and failure modes using everyday travel analogies — no code involved.

Read The Autonomy Dial →

🔨

Fix the heading first

You built rawweights.com page by page in late-night sessions. The inconsistency wasn't incompetence — it was momentum. The right first step for an agent isn't to rebuild all 40 pages at once. It's to pick the one page that would most benefit from being the canonical reference, make it perfect, document every decision it embeds, and use that as the foundation for everything else. Start with the one. Prove the pattern. Then scale.