Letting AI edit a production website safely has very little to do with trusting the model and everything to do with the system around it. Ours has four layers: schema validators that reject malformed work at write time, versioned workspaces where every change is diffable and reversible, branches and checkpoints for risky work, and a human approval gate in front of everything customers can see.
At Faster, AI agents edit real customer websites every day — pages, forms, posts, emails, animations. The question we get from engineers is always the same: how do you let a language model touch production? The honest answer is that we don't, quite. We let it touch a heavily instrumented layer that sits in front of production. This post is about that layer.
Start from the failure modes, not the features
Designing guardrails means naming what you're guarding against. For AI editing a website, the failure modes are specific and rankable:
The ranked fears
1. Structurally broken output that takes a page down. 2. Structurally valid output that's wrong for the business — wrong price, wrong claim, wrong audience. 3. A correct change that can't be undone when the owner changes their mind. 4. A change nobody knew happened.
Notice that only the first one is a "model quality" problem. The other three are systems problems — and they'd exist with a junior human editor too. That's the useful framing: design for a fast, tireless, occasionally overconfident junior teammate, and the architecture writes itself.
Validators: reject bad structure at write time
Every artifact an agent can produce — a page template, a post bundle, a form configuration, an email — has a schema, and every write passes through a validator before it lands. Not after, before. A page with unbalanced template blocks, a post missing its metadata sidecar, a form field with an invalid type: all of these bounce back to the agent with a machine-readable error, and the agent retries with the error in context.
Two design decisions matter more than the schemas themselves. First, validation errors are written for the model, not for humans — precise, located, and actionable ("post_settings.tags[2].id: expected string"), because the validator's main consumer is the retry loop. Second, validators are allowed to be opinionated. Ours don't just check syntax; they enforce contracts — content lives in the body file, never inlined in the record; immutable identifiers can't be rewritten; references must resolve. Every contract encodes a production incident we don't want twice.
Versioned workspaces: every change is a diff
Every Faster workspace — the website theme, posts, forms, journeys, media — is a versioned content repository. An agent doesn't "update the website"; it writes files into a working copy, and those writes become commits with messages, authorship, and diffs. This buys three things that turn out to be load-bearing for AI work:
- Reviewability. "What did the agent change?" has an exact answer — a diff — not a vibe. Review tooling renders that diff next to a visual preview.
- Reversibility. Any change, agent or human, rolls back the same way. There is no special "undo the AI" machinery to build or trust — reverting is a property of the storage layer, not a feature bolted on top.
- Attribution. Agent commits are marked as agent commits. Six months later, "who changed the pricing page in March?" is a log query.
Reversibility isn't a feature you add for AI. It's a property of the storage you choose.
If undo requires special-case code, you'll discover its gaps during an incident.
Branches and checkpoints: blast-radius control
Small, low-risk edits can go to the main working copy. Anything bigger — a redesign, a restructure, anything a human would think twice about — happens on a branch with checkpoints: an isolated copy of the site where the agent can work freely, with named save points summarizing what changed at each stage. The owner reviews the branch as a whole, merges when satisfied, or deletes it without ceremony.
Checkpoints earn their keep in the middle of risky work, not at the end. Before an agent touches navigation across every page, it checkpoints. If step four of six goes sideways, the recovery point is minutes old and clearly labeled — not "whatever the site looked like this morning". The agent is required to create them precisely because it's the kind of discipline a hurried human skips.
The approval gate: drafts by default
The last layer is a policy, enforced in tooling: AI output is a draft until a human approves it. Agents prepare; owners publish. Page changes land in a review-and-approve flow with a visual preview; posts, emails, and journeys sit in draft states until someone clicks send. The gate exists because layer-1 validators can't catch the second failure mode — structurally perfect output that's wrong about the business. No schema knows your prices changed last week. The owner does.
The subtle part is keeping the gate cheap. If review takes longer than doing the work by hand, people start rubber-stamping, and a rubber-stamped gate is worse than none — it launders mistakes with the appearance of oversight. Diffs, previews, and one-click approve/revise/reject keep the cost low enough that review actually happens.
What we deliberately didn't build
Three roads we considered and closed. Auto-publish with anomaly detection — catching "weird" changes statistically sounds clever and fails exactly when it matters, on the plausible-but-wrong change. A sandboxed preview-only AI — if the agent can't do real work, people copy-paste its output by hand, and now there's no diff, no attribution, no rollback. And per-feature undo systems — special-case reversibility is the kind of code that rots quietly; storage-level versioning made it unnecessary. In all three cases the lesson was the same: guardrails work when they make the safe path the convenient path.
Key takeaways
- Design for failure modes, ranked: broken structure, wrong business facts, irreversibility, invisibility.
- Validate at write time, for the model: machine-readable errors feed the retry loop.
- Version everything: diffs, rollback, and attribution come free from the storage layer.
- Branches + checkpoints bound the blast radius of big agent jobs, mid-task and not just at the end.
- Humans hold the publish gate — and the gate must be cheap, or it becomes theater.
Frequently asked questions
Doesn't all this review defeat the point of AI speed?
The speedup was never in the clicking — it's in the preparing. Drafting a page, restructuring navigation, writing variants: minutes instead of hours. A thirty-second review of a good diff preserves nearly all of that win, and skipping it gives the win back the first time something wrong ships.
What happens when the agent produces invalid output?
The validator rejects the write and returns a located, machine-readable error; the agent retries with that error in context. Most failures resolve in one retry. Repeated failures surface to the user rather than looping silently — an agent that can't satisfy the schema is information, not noise to swallow.
Why not fine-tune the model to make fewer mistakes instead?
Model quality reduces how often guardrails fire; it can't replace them. Failure modes two through four — wrong business facts, irreversibility, invisibility — are independent of model quality. A perfect model with no review gate still publishes last month's prices, because nobody told it they changed.
Do human edits go through the same machinery?
Yes — same repositories, same validators, same checkpoints. That's most of why the system stays healthy: a single pipeline gets exercised constantly and fixed quickly. Separate "AI rails" would be the least-tested code in the product, guarding the highest-risk writes.
What would you tell a team building this from scratch?
Order of operations: versioned storage first, validators second, review UX third, agent capabilities last. Teams that start from agent capability spend the next year retrofitting the other three under incident pressure — every layer here is cheaper to build before the agent exists than after it has users.
If you remember one thing: the model is the least important part of the safety story. Storage that diffs, schemas that reject, checkpoints that bound the damage, and a review gate cheap enough to actually use — that's what lets a business owner say "update my website" to an AI and sleep fine. The user-facing version of these flows lives in the help center; this was the view from underneath.