AI for web agencies is not a chatbot bolted onto your inbox. It is a different way to run client work. We found that out by running our own agency on it. Since April 2026 we have put 6,600+ agent runs through 190+ client projects, for 26 clients.
Nothing here is a forecast. Every example comes from our own delivery records, anonymised.
The short version
- The brief becomes the job: the page, the outcome and the limit.
- Each client gets its own agent and its own sandbox.
- A person approves the plan before anything changes.
- Every change ends with proof you can send to the client.
- Mistakes become written rules, and the rules matter more than the model.
- People still decide, talk to clients and sign off anything that cannot be undone.
The brief becomes the job
The first change is small, and it matters most. You stop splitting work into tickets for different people. You write one clear brief.
A good brief has 3 parts. The page or system it touches. The outcome you want. The limit, such as "do not touch checkout" or "ready before the sale".
Paste in the client's email. Drop in the screenshot. In the Webgentic Orchestrator, the agent reads the client's history, the platform playbook and your house rules before it answers.
Most of the effort moves to the start. A clear brief is now the most useful thing you write. Here is the same job done the old way and with agents.
| Step | Without agents | With agents |
|---|---|---|
| Brief | An email, forwarded and re-read. | One brief: page, outcome and limit. |
| Plan | In one developer's head. | A numbered plan with the risk and the way back. |
| Approval | Easy to skip when busy. | A person approves before anything changes. |
| Change | One developer at a keyboard. | The agent, inside that client's sandbox. |
| Proof | "Done" in a message. | Screenshots, checks and a written validation. |
| Lesson | Lives in one person's memory. | Written down for every agent. |
One agent per client, and a sandbox for each
The Orchestrator has 4 kinds of agent. An agency agent sees the whole agency. A client agent sees one client. A project agent works on one project. Large jobs are split into parts inside the same project, and the project agent checks each part before it reports back.
The split is about containment. A project agent can read and change its own project's files and nothing else. That limit is enforced in code, not left to good behaviour. A job for one client cannot spill into another client's site, even if the agent gets something wrong.
Each agent also keeps its own memory. The client agent knows the contacts, the hosting and the quirks. The project agent knows what was tried last month. You stop briefing from scratch every time.
Plans come before changes, and a person approves them
Every change to a client site starts as a short numbered plan. It names the risk and the way back. You approve it, change it or reject it. Nothing touches a client site until you say so.
Why insist on a person? A confident agent that is wrong is a bigger risk than a slow one. The plan is the cheapest place to catch it. Here is an example plan for a fictional client.
Acme client, size guides
1. Read the product template and the size data.
2. Add a size guide block to the product template.
3. Screenshot 5 products on desktop and phone, and check each one.RISK: low, a template change with no data change.
UNDO: one commit, reversible in place.
When you review a plan, ask 3 things. Does it touch only what the brief named? Is the risk honest? Can it be undone? If an answer is no, send it back.
Proof after every change
A job is not done when the change is made. It is done when you can show it works.
Each substantial job ends with a written validation: what changed, what was tested and what is still open. Visible changes come with screenshots on desktop and phone. Two AI vision models cross-check the screenshots, not one, because one model can miss what the other sees. The note you forward to the client is the validation, the before and after, and the checks.
Proof is also how you catch the problems nobody reports. Here is one we caught.
A homepage that returned 200 for 6 months and showed nothing
Larch client had a PHP site on one of 27 hosts we were upgrading. Before the change, the agent recorded the status code and the page size for every host. One homepage came back with 200 and only 310 bytes. Its siblings were near 150,000.
A leftover setting in a config file pointed at a security plugin that had been deleted. Every request died before the site loaded, and the server still said 200. The logs held 111,484 failures. No uptime monitor could see it, because they only read the status code.
The same record made the upgrade checkable: 25 of the 27 hosts came back byte for byte identical after the PHP switch. The agent also found a second site with the same stale setting, firing on 716 of the last 5,000 lines of its error log.
Example based on a real job, details changed.
The lesson is simple. A status code is not proof. Record what the page looked like before you touch it, then compare. Our guide to AI website maintenance covers which routine jobs are safe to hand over first.
Memory turns mistakes into rules
This is the part we would copy first. A model forgets. An agency with written rules does not.
Every night our system reviews what happened. When something went wrong and was fixed, it writes up what failed, what worked and what to avoid next time. Rules with enough evidence behind them go into the playbooks on their own. A change to a core principle waits for a person to sign off.
So far that is 861 mistakes turned into rules, plus 32 playbooks for platforms such as WordPress, Magento, Drupal and cPanel. An agent starting on a new project gets the rules that fit the job.
Why does this matter more than the model? Models keep changing. We move to better ones as they arrive. The rules are what is yours. They carry your clients, your hosting quirks and your standards from one model to the next.
An accessibility check that only looked at one user
Hale client had an accessibility check on every release, and it passed for 3 weeks. Then an agent ran the same scan as a buyer, with a buyer's data, on a phone-width screen. It found 2 faults the old check could not see: a link told apart from the text by colour alone (WCAG 1.4.1), and 3 tables that scroll on a phone but cannot be reached with a keyboard (WCAG 2.1.1).
The old check opened the seller's own preview page at 800 pixels wide. That page had no company number to link, and its tables did not overflow at that width. The check was fine. What it looked at was too narrow.
The rule we wrote: a page check covers only the user and the width it ran at. Run the scan once as each role the page serves, with the data that user has, at the narrowest width. Expect a round of fixes the first time a new page joins the check.
Example based on a real job, details changed.
Jobs that still need a person
AI for web agencies is strong at the repeatable and weak at deciding what the work is for. Keep these with people.
- Decisions. What to build, what to refuse, and when a request is a bad idea.
- Client relationships. A client wants to hear from someone who knows them. The agent can draft the email. You decide whether to send it and how it sounds.
- Anything irreversible. A DNS change, a deleted database, a payment. If it cannot be undone, a person looks first.
- Judgement on design. The agent can check that a page works at 390 pixels wide. It cannot tell you whether the page feels right for the brand.
The agent also has to know when to stop and ask a person. Here is a case where asking first would have saved a redo.
A call whose answers were never written down
The brief for Northgate client said: analyse the notes and transcript from our call. Neither was attached. The agent said so, then rebuilt the call from the saved answers in the question register and emailed a report: 14 of 18 questions answered.
When the transcript arrived, the true count was 17 of 18. Three answers had been given aloud but never properly typed in: 2 not at all, and 1 saved with only a name changed. The AI summary of the call also misread a price and merged 2 people who share a first name.
The rule we wrote: if the input named in the brief is missing, ask before anything goes out that states a count or a decision. A rebuild from logs is a draft, and what you could not see is unknown, not open. Take figures and names from the transcript, never the summary.
Example based on a real job, details changed.
Pricing and retainers
Hourly billing and agents do not mix. If you sell hours, a faster job means a smaller invoice. That is the wrong way round.
So price the outcome. A retainer becomes a list of what you check, fix and report every month, with the proof attached. The client buys a result and a record, not a block of time.
- Write the retainer as standing jobs. The monthly update, the backup check, the report.
- Schedule the repeat work. A schedule starts the job at the time you set.
- Watch the cost of each job. The Orchestrator records what every job costs, so you can see which work is worth delegating and what to charge for it.
We do not put a price on your retainer here. It depends on your clients and your platforms. The Orchestrator itself is priced on a call, because setup depends on how many clients and platforms you bring. For the wider picture, read how to scale a web agency without hiring first.
How to start with AI for web agencies
Do not roll it out across the whole agency. Pick one recurring job.
- Choose a job you do for many clients. A monthly update and check on each site is a good one. It repeats, it is easy to judge, and a mistake is small.
- Write down what done looks like. List the checks. They become the proof.
- Run it on 1 client. Read the plan. Approve or change it. Read the proof.
- Write down what went wrong. Turn it into a rule before you run the next client.
- Add the next client, then schedule the job.
If you want help, we set up the Orchestrator for you, load your clients and house rules, and run the first real jobs with your team.
