The Handoffs Are the Hard Part: Auditing Every Connection Point in an LLM-Run Site Pipeline

(No live web search in this session, so this is built on long-standing mechanics of how CI/CD pipelines, MCP tool calls, and deploy hooks actually behave in practice. Verify tool-specific limits against current docs before trusting any of this to production.)

---

Every comparison post about agentic site building asks the same question: which tool is best? Which LLM writes the cleanest code, which host deploys fastest, which MCP server is most reliable. It's a reasonable question asked at the wrong altitude.

Because if you've actually run one of these pipelines — LLM generates the page, an MCP tool call triggers the deploy, campaign data feeds back into the next revision — you already know the tools are rarely the problem. Each one works in isolation, demo-able, tested. What breaks is the seams. The moment output from one system becomes input to another, you're in the territory where nobody's documentation covers and nobody's error messages are written.

We've covered individual links in this chain before — where AI-generated code deploys without a fight, and how to wire MCP servers so your pages update from live campaign data. This post is the audit of the whole chain: every handoff, and where each one silently fails.

The pipeline, mapped

Before auditing anything, here's the full handoff chain as it actually exists, not as the architecture diagram in your head says it does:

1. Intent → LLM. You describe the page. The LLM generates code.
2. LLM output → version control. The code has to land somewhere durable.
3. Version control → deploy. A push triggers a build and release.
4. Deploy → live domain. DNS and CDN have to cooperate.
5. Live site → tracking. Pixels and analytics fire on the new version.
6. Tracking → campaign data. Metrics land somewhere queryable.
7. Campaign data → MCP. An agent pulls the data and decides what to change.
8. MCP → LLM. The change request becomes a new generation.
9. Back to step 2. The loop closes — or doesn't.

Nine handoffs. Each one is a place where context gets dropped, formats get misread, and failures happen without anyone being notified. Let's go through the ones that actually bite.

Handoff 1: Intent → LLM (the specification gap)

This is the handoff everyone treats as trivial and nobody should. "Make me a landing page for the spring promo" is not a specification. The model will fill every gap you leave with an assumption, and each assumption is a decision you'll discover later, live, in production.

How it silently breaks: The code is fine. It deploys, it renders, it loads. What's wrong is that the model assumed your conversion goal, your compliance language, your brand constraints — and none of those assumptions are recorded anywhere. Six revisions later, nobody remembers which details were intentional and which were a model's guess that stuck.

The fix: Keep the spec in a file inside the repo — a BRIEF.md or equivalent — and make every generation session start by reading it. Then the spec itself is versioned, diffable, and survives model context windows. The handoff artifact isn't the prompt; it's the persistent document.

Handoff 2: LLM output → version control

LLMs don't have filesystems. Whether you're pasting into an editor, using an agentic coding tool, or wiring output through an API, the code has to cross from the model's context into a git history — and this crossing is where two failure modes live.

Failure mode one: partial files. A long generation gets truncated, and you commit a file with a closing tag missing. It might still "work" — browsers are forgiving — and the breakage surfaces weeks later as an inconsistent bug nobody can reproduce.

Failure mode two: no history at all. If your workflow is "ask the model, copy the file, done," you have no diff. When a change degrades conversion, you can't roll back to the specific prior version because there is no specific prior version — there's just whatever you last pasted.

The fix: Treat the model's output as untrusted input to a normal engineering process. Validate it (even a basic HTML parse catches truncation), commit it with a message that says why the change was made, and never edit directly on the live source of truth.

Handoff 3: Version control → deploy

This is the handoff most people assume is solved, because CI/CD is mature. It is solved — for codebases shaped like normal codebases. AI-generated code often isn't, and the failures are quiet.

How it silently breaks:

• The build passes but the deploy means nothing. A static site with a misconfigured output directory will "deploy successfully" to a folder containing nothing useful. Green checkmark, broken site.
• Secrets don't cross. Your build references an environment variable the deploy environment doesn't have. Locally it worked because it was in your shell. In production, the pixel ID is an empty string and tracking silently dies.
• Non-deterministic regeneration. If your pipeline regenerates code on each deploy rather than deploying committed code, two identical deploys can produce different output. The model is not a build tool. It's a code generator, and generators need to run once, with the result committed.

The fix: Deploy committed code, never live model output. Make the pipeline's success condition "the live URL returns the expected content," not "the build exited zero." A post-deploy check that fetches the page and greps for a known string costs five lines and catches the entire category of silent empties.

Handoff 4: Deploy → live domain

We've written in detail about what breaks when domains sit with legacy registrars, so this is the short version: DNS propagation, stale caches, and nameserver mismatches make this the slowest handoff in the chain — sometimes hours — and it's the one where you can't tell the difference between "still propagating" and "permanently broken" without digging.

The audit question: After a deploy, how long does it take — precisely — for the change to be visible at your domain on a cold connection? If you don't know, you'll misattribute every deploy-related bug to the wrong stage. Cache headers on your static assets are part of this handoff too: an aggressively cached page means your "successful" deploy isn't what visitors see.

Handoff 5: Live site → tracking

The site is live. Now: is the pixel firing? This handoff fails silently more than any other, because a missing pixel produces no error anywhere. The page renders perfectly. The ad platform just receives nothing.

How it silently breaks:

• The deploy overwrote the template section where the pixel snippet lived. The code was correct in the last version; the regeneration didn't carry it forward because it was never in the spec — it was patched in manually.
• A content security policy or consent-management script blocks the pixel on some fraction of loads.
• The pixel fires on the staging URL during testing and on the production URL in reality — or the reverse — so half your validation was measuring nothing.

The fix: Tracking snippets belong in the spec file (Handoff 1), not in manual edits, so regeneration preserves them. And validate the pixel from the live URL after every deploy, not from preview environments. An automated check that loads the page and confirms the pixel request fires belongs in the same post-deploy script as your content check.

Handoffs 6–8: The data loop

This is the newest part of the chain and the least standardized. We've documented the wiring itself elsewhere, so here's the audit view — where the feedback loop degrades.

Handoff 6, tracking → data: Platform-reported metrics lag, get restated, and attribute differently than your analytics does. A revision cycle that reacts to yesterday's numbers is reacting to numbers that will change. Build in a deliberate delay — react to data that's had time to settle.

Handoff 7, data → MCP: The silent failure here is schema drift. Your MCP tool call returns JSON whose shape changed — a field renamed, a metric now null instead of zero — and the agent doesn't error out. It reasons confidently about nonsense. Validation at this seam means checking not just that the call succeeded but that the response has the fields you expect, with plausible values.

Handoff 8, MCP → LLM: The agent's change request becomes a prompt, and this handoff inherits every problem from Handoff 1 — except now the person who wrote the spec isn't in the loop. The model is being asked to revise a page based on data it didn't gather, toward goals it didn't set. If the revision prompt doesn't explicitly restate the constraints (tracking snippets, compliance copy, brand rules), the revision will drop them. Guardrails that live only in the original prompt do not survive revision cycles. They must live in files the model reads every time.

The pattern across all nine

Notice what every fix above has in common: artifacts over conversations, checks over assumptions.

• The spec is a file, not a prompt.
• The code is committed, not pasted.
• Deploy success is a verified page, not a green checkmark.
• Tracking is confirmed from the live URL, not assumed.
• Data responses are validated, not trusted.
• Guardrails are re-read every cycle, not remembered.

The handoffs break because each tool's contract ends at its own boundary, and nobody's job — human or agent — is to own the boundary itself. Once you make those boundaries explicit artifacts with explicit checks, the pipeline stops being a series of demos and starts being infrastructure.

A closing audit checklist

Run this against your own pipeline once, honestly, and you'll find your weakest seam:

1. Is your page spec a versioned file the model reads at the start of every session?
2. Does every deploy verify the live URL contains expected content?
3. Do you know your DNS/cache propagation time cold?
4. Is pixel firing checked from production after every deploy?
5. Does your data-pull step validate response shape before the agent reasons on it?
6. Do revision prompts restate constraints, or assume the model remembers them?

If you answered no to three or more, the tools aren't your bottleneck. The handoffs are — and unlike the tools, nobody is going to market a fix to you. You have to build it.