When you let a language model change a website that real customers are visiting, the hard questions are mostly not about prompting. They are about limits. How many times may the model think before it has to act? How much does it see on each call? And what happens when it gets something wrong?

At Orivox we answer those three questions with three blunt mechanisms: a fixed call budget per turn, a predictable context assembled the same way every time, and a Git commit after every turn. This post goes through each one, with the numbers we measured.

The shape of one turn

An edit "turn" starts when a site owner types a request, in Hebrew or English, such as "make the FAQ cards dark". The web app checks the account, queues the job and takes a project lock. The editing service puts the page together in memory, with the shared header and footer included, and asks the planner model what to do.

The planner has two ways to respond. It can answer in plain words, or it can call a tool. There are 11 tools. The important one takes a list of small, named operations that target elements by a stable id. Python applies those operations, runs its checks, saves the page and commits the result. The model itself never writes a file.

Everything below depends on that split. The model proposes, and deterministic code decides.

A budget of six model calls

Only some tools end a turn. An edit call does. Every other tool returns a result to the planner so it can keep going: reading another page, looking at a screenshot of the rendered page, reading a page the owner linked to (with their consent), pulling a palette from an image, generating an image, and so on.

That is useful, and it is also how an agentic loop wanders off: a planner that can always ask for one more screenshot can burn calls on a request that needed one class change.

So each turn has a fixed budget of six model calls. Inside that budget the planner can gather what it needs: check the other page, look at the render, then emit its operations. When the budget runs out, the turn ends.

In practice, a hard cap has a few effects:

• Cost per turn has a ceiling. You can work out the worst case before you ship, not after the bill arrives.
• Latency has a ceiling too. Turns run in Redis-backed job queues, so a web request never waits on a model. A slow call can't tie up the site, and a bounded loop can't hold a project lock forever.
• It pushes the design toward cheap, decisive actions. If the useful information isn't reachable in a few calls, the fix is usually a better tool or better context. Raising the cap rarely helps.

What fits in about 42K tokens

The second limit is context. On every turn the planner gets a full, predictable request of about 42,000 input tokens, built the same way each time. Here is the breakdown, measured with Gemini's own token count:

Two things stand out.

First, the owner's actual request is a rounding error. Nearly all the tokens go to rules, tools and the page. Context engineering here mostly means deciding how the page is represented.

Second, the rules and tool definitions add up to about 26,000 tokens and are identical on every turn. Because they never change, they are cached, so the fixed part of each request is fast and inexpensive. If you build something similar, put the stable material at the front and keep it byte-for-byte stable. Caching only helps if the prefix really is the same each time.

Raw HTML beat the clever summary

I expected a compact JSON summary of the page (element ids, roles, short text) to beat raw HTML. It is the kind of preprocessing that seems obviously right.

We benchmarked both on real edit requests. Raw HTML gave the planner the same understanding at about half the tokens of the JSON summary, and with raw HTML the planner sees every element on the page instead of whatever the summarizer decided to keep.

My guess is that models have seen a huge amount of HTML and none of our private summary format.

The summary is still useful. Very large pages switch to it automatically, so a single oversized page can't take over the context. But it is the fallback, not the default.

Small answers on purpose

On the output side, the numbers are much smaller. Across 24 benchmark runs, the median planner output was 141 tokens. That is a handful of operations, not a rewritten page.

This follows directly from asking for operations instead of documents. A request like "make the FAQ cards dark" turns into a few class changes on specific elements, and nothing else on the page moves. Short outputs are quicker to generate, cheaper, and much easier to check. You can validate, log and replay a list of operations before anything touches disk.

Git is the undo button

Budgets limit how much the model can do in one turn. They don't make what it does safe. For that we rely on version control.

Every edit turn is a Git commit in the project's own repository. Before the first edit, the original site is committed as a baseline, so the owner can always get back to the version they started with. Undo is a restore, not a reconstruction. The planner even has a tool for restoring an earlier version, so "go back to how it was yesterday" is a normal request rather than a support ticket.

Some rules keep that history trustworthy:

• One owner of history. The editing service owns each project's Git repository. The web app never runs Git against a project. When it has to write files itself, it takes the lock, writes, and asks the editing service to commit.
• One writer at a time. A single project lock, held in Redis, covers the whole turn across every process. Two changes can never interleave on the same site.
• Checks before commits. Every save goes through deterministic Python guards. A save can never empty a live page, moved text keeps every sentence, the business logo and the contact form's privacy notice are protected, and a claim of success needs a real change. Each guard is pinned by a replay test.

With a commit per turn, a strange edit isn't an incident. It's one commit you can look at and roll back. The model doesn't need to be perfect. It needs to be bounded, checked, and reversible.

Takeaways

If you are putting an LLM in charge of edits to something live, here is what I would carry over:

1. Cap the loop. Choose a model-call budget per turn and enforce it in code.
2. Measure your context. Count tokens per component. You will probably find the user's request is the smallest part.
3. Cache the stable prefix. Rules and tool schemas that don't change should be cached.
4. Benchmark your representation. Our "smarter" summary was worse than raw HTML at about twice the cost.
5. Ask for operations, not artifacts. Small outputs can be validated and replayed.
6. Commit every turn. Commit a baseline first, then one commit per change, with a single owner of the history.

I spent many years in product development before building this, and the lesson I keep coming back to hasn't changed: build for the bad day. On a bad day, the budget, the guards and the Git log keep the problem small.

This is how the editor at Orivox works today, and I'm happy to compare notes with anyone building something similar.

Disclosure: AI assisted in drafting this article from the author's technical write-up; the author reviewed and edited the final text.

Zahi Raifer is a software developer with 23 years of experience in AI development, Python, .NET and databases, and the founder of Orivox.

This is a conceptual tour for developers curious about exposing something stateful and slightly messy, like a website, to an agent. I'll stay at the level of protocol concepts and design decisions, not any one vendor's implementation.

A 60-second refresher on MCP

MCP is an open protocol that standardizes how an AI client (a chat app, an IDE, an agent runtime) talks to external capabilities. A server exposes three main kinds of things:

• Tools: functions the model can call, each with a name, a description, and a JSON Schema for its inputs.
• Resources: readable data the client can pull into context, addressed by URI.
• Prompts: reusable, parameterized templates a user can invoke.

Servers run locally over stdio or remotely over HTTP (Streamable HTTP in the current spec). For a hosted site builder, remote is the natural choice: nothing to install, just a URL. Remote servers authenticate users with OAuth, and since many MCP clients are public clients that can't keep a secret, PKCE is the usual flow.

Designing the tool surface

The temptation is to mirror your REST API one-to-one. Resist it. A REST API is designed for programmers who read docs; a tool list is designed for a model that reads descriptions and guesses. A few principles that matter more than usual:

Name tools after intentions, not endpoints. create_site_from_brief tells the model when to use it. POST /v2/projects does not.

Write descriptions as instructions. The description is effectively part of the prompt. Say what the tool does, when to prefer it over a sibling, and what the model should do with the result ("return the preview URL to the user").

Choose granularity deliberately. A site builder could expose one giant build_website tool, or forty tiny ones (set_heading_text, set_button_color...). Too coarse and the agent can't make targeted edits. Too fine and it burns turns and context on trivia. A workable middle ground for site generation tends to look something like:

• create a site from a natural-language brief
• list and inspect a user's sites
• read the current structure of a page
• apply an edit, described in natural language or as a structured patch
• generate a preview link
• publish or unpublish
• connect a domain

Return things the model can act on. After a create or edit call, the most useful payload is short: an ID, a status, and a preview URL. Dumping the whole generated HTML back into context is usually a waste of tokens.

Generation is slow, so plan for it

Tutorial tools return instantly. Building a website does not. Depending on complexity, generation can take anywhere from several seconds to a minute or more.

You have a few options:

1. Block and wait. Fine if generation reliably finishes within the client's timeout.
2. Job pattern. Return a job ID and expose a get_job_status tool. Agents are not always patient pollers, though.
3. Progress notifications. MCP supports progress updates for long-running requests, which lets a client show something better than a spinner.

Whichever you pick, make the tool description explicit about it. A model that doesn't know a build is asynchronous will cheerfully tell the user "your site is live!" before anything exists.

Guardrails for actions with consequences

Some operations in a site builder are harmless (generate a draft). Some are public (publish to the open web). Some cost money (register a domain). An agent shouldn't treat them the same way.

Patterns worth adopting:

• Separate draft from publish. Generation and editing should never implicitly make anything public.
• Make consequences visible in the schema. A publish tool that requires a confirm: true argument, plus a description stating that the user must approve, nudges the model to ask first.
• Lean on client-side approval. Many MCP clients ask the user before running a tool. Mark destructive or costly tools clearly so clients and users can treat them differently.
• Scope OAuth tokens narrowly. If a token can only touch the sites belonging to the user who authorized it, a confused agent can do far less damage.
• Validate server-side anyway. Generated content still goes through the same checks as content from a human editor. The model is a user, not a trusted component.

Errors are part of the conversation

When a tool call fails, a model reads the error and decides what to do next. That makes error messages a design surface.

"400 Bad Request" teaches the model nothing. "The domain example.com is already connected to another site. Ask the user whether to move it." gives the agent a sensible next step. MCP lets a tool return an error result as regular content, which is often better than a protocol-level failure precisely because the model gets to see and reason about it.

What people actually do with it

Once a site builder speaks MCP, a few use cases fall out naturally:

• Conversation-first creation. Someone already chatting with an assistant about their new bakery can ask for a website without switching apps.
• Agent workflows. An agent setting up a small business (drafting a menu, writing a Google Business description) can add "publish a one-page site" as one more step.
• Agencies and freelancers. Spinning up first drafts for several clients from a list of briefs, then refining each by hand.

A real-world example

This isn't hypothetical. Orivox, a Hebrew-first AI website builder, runs a remote MCP server at mcp.orivox.org, and it's listed in public MCP directories. You add it to an MCP-capable client as a connector, sign in, and then ask for a site in plain language. If you want to see the product the connector sits on top of, here's the Orivox AI website builder.

Takeaways

Treat tool names and descriptions as prompt engineering, design for slow operations from day one, keep a hard line between drafting and anything public or paid, and write errors that tell the model what to do next. The protocol itself is small. Most of the craft is in deciding what an agent should be able to do, and what it should have to ask permission for.