The AI agent web team: an operating model for running a B2B website with agents

Start with functions, not tools. Each agent owns one job, works from written rules and cannot merge its own work. That separation is what makes the output reviewable, and it is the same separation a good human team has between the person who builds and the person who checks.

Notice the last column. Most agents notify nobody when their checks pass. People hear about exceptions and approvals, not routine work.

The experiments agent follows the method in our guide to A/B testing without an experimentation platform.

Every change, from a typo to a new template, arrives as a pull request with a preview deploy. The pull request holds the brief, the evidence and the decision. Nothing reaches production without one, and nothing is merged by the agent that wrote it.

1. Intake: a request, a scheduled finding or a brief becomes a task with an owner agent and a written acceptance check.
2. Build on a branch: the owner agent makes the change on its own branch and never touches the main branch directly.
3. Self-check: the agent runs the type check, the build and its own function’s checks, and attaches the results.
4. Preview: the host builds a preview URL, so reviewers look at the real page rather than a description of it.
5. Review board: specialist agents review the pull request against their rules and comment or block.
6. Fix loop: the owner agent addresses each comment until the board passes.
7. Human approval: the named approver checks the preview and merges, or sends it back with a reason.
8. Deploy and notify: the merge deploys, changed URLs are submitted to search engines, and scheduled agents watch the next checks.

Version control gives you what most CMS audit logs try to: who changed what, when, why and who approved it, with a one-step revert when something goes wrong.

The review board is a set of agents that review other agents’ work. On our own site it covers design, UX and CRO, accessibility, SEO and GEO, and claims. Gates decide which reviews block a merge and which person approves.

Keep the gates few and written down. A gate nobody can explain becomes a gate everybody bypasses.

Some work has no request behind it. Scheduled agents run on a timer and only open a pull request or send a notification when something has changed.

• Daily site health: broken links, redirect chains, missing titles, pages that dropped out of the sitemap.
• Indexing: after each deploy, changed URLs are submitted through IndexNow, which Microsoft Bing, Naver, Seznam.cz, Yandex and Yep support; pages crawled but not indexed are reviewed in Search Console.
• AI crawler checks: robots rules still allow the search crawlers you want, such as OpenAI’s OAI-SearchBot, and llms.txt still lists current pages.
• Performance drift: lab runs on key templates, with field Core Web Vitals reviewed as the data builds up.
• Tracking: a test form submission confirms that events and CRM fields still arrive.
• Content freshness: pages with dated facts, prices or statistics are flagged for review.

Notifications go to the person who owns the decision, in the channel they already use, with the preview link and the one question they need to answer. If a message does not need a decision, it is a report, and reports go in a weekly digest.

Agents do the work. People own the decisions and the accountability. On our own site, and in the builds we scope for clients, the split looks like this.

• Strategy and priorities: which pages, offers and markets matter this quarter.
• Approval of every merge to production.
• Facts: the approved claims file, client names, prices and partnerships.
• Brand and positioning decisions.
• Final calls on experiments: ship, iterate or stop.
• Access, budgets and vendor contracts.

Governance is mostly configuration. Agents get least-privilege access: they can open pull requests but not merge to the main branch, and they never hold production secrets or CRM admin rights. Branch protection enforces the human approval. Customer data stays out of agent context unless a written policy allows it. Every action is in the version history.

Security reviews get easier, not harder. There is no CMS admin panel exposed to the internet on a static site, the deploy is a build of a reviewed commit, and rolling back is reverting a commit.

We will not give you a savings percentage, because it depends on your stack, your publishing volume and who you already employ. What we can show is the reasoning.

A typical in-house or agency web team covers the roles below, full time or in part. In the agent-run model, the routine work of each role moves to an agent, and the role becomes a reviewer or approver. Often one person covers several of them.

For a reference point on cost, the US Bureau of Labor Statistics reports a median annual wage of $92,650 for web developers in May 2025, and $99,520 for web developers and digital designers combined. It projects employment in that group to grow 5% from 2025 to 2035. If the agent-run model means one fewer developer to hire, that is the order of magnitude to compare against agent usage and review time. Your market, seniority and benefits will change the figure.

Time works the same way. A change that waited a sprint in a ticket queue becomes a pull request the same day, and the person’s time goes into review, which for most changes is a few minutes of looking at a preview. That is reasoning, not a measured benchmark, so measure it on your own backlog.

This is the core argument of our pillar on enterprise headless without a DXP: the licence is the smaller cost and the team is the larger one.

We run planconversion.com this way in English, French and Italian. One day in practice: on November 9, 2026, our own Lighthouse runs flagged menu buttons just under the 24 pixel minimum tap target. An agent opened the fix as a pull request, the review board checked it, a person approved the merge and the next measurement confirmed it. The same day an agent tried inlining all CSS to speed up first paint; the live measurement showed mobile first paint got slower, so a second reviewed pull request reverted it. Two changes, two approvals, a few minutes of human time each.

The static build is what lets the checks stay cheap. Because every page is generated as complete HTML, with metadata, schema, the sitemap and llms.txt produced by code, the SEO and GEO agent inspects one build output instead of chasing settings across a CMS admin panel.

The results are public, and we explain the build behind them in how we scored 100 on PageSpeed Insights.

If you are weighing the model against a platform, read our comparison of agent-run headless vs Contentful, Storyblok and Sanity.

For clients we deliver the same model through our website development service.

Testing runs the same way as our conversion rate optimization work, with agents building variants and people deciding what ships.

Search and AI visibility follow our generative engine optimization method from the first build.

This is how we built and run our own site. If you want the same results, talk to our team and we will come back with a full solution for your stack.