A Straight Answer About How the Work Gets Done
Most agencies are either quietly using AI and hoping nobody asks, or loudly claiming to use AI in ways that don’t survive a follow-up question. Neither is a good look, so here is the actual picture: what we’ve automated, how it’s wired, and — the part that matters more — where we deliberately keep a human in the loop.
The Setup
Every site we manage is reachable over SSH with WP-CLI available. That combination is unglamorous and it is the whole foundation, because it means anything that can be done in the WordPress admin can be done from a command line, which means it can be scripted, which means an agent can do it.
On top of that sits a set of purpose-built agents. Each one has a narrow job, a defined set of tools, and a specific definition of done. They are not one general-purpose assistant with the keys to everything — that architecture fails in ways that are expensive to discover.
The QA agent
Given a page or template we just built, it loads the site across five viewport widths, drives whatever flow is on the page, captures what it sees at each size, and classifies what’s wrong: layout breaks, console errors, accessibility failures, contrast problems, images without dimensions. It fixes what’s mechanically fixable in the source, re-runs, and reports what’s left.
This replaced the least reliable part of any build — a human remembering to check the tablet breakpoint at 6pm on a Friday.
The audit agent
It crawls a site and returns the technical picture: status codes, redirect chains, title and description problems, heading structure, schema validity, Core Web Vitals, orphaned pages, index bloat. What used to be a multi-hour pass with a desktop crawler and a spreadsheet is now a command, and because it’s a command it can run on every client site rather than the ones that happen to be top of mind.
The reporting agent
It pulls analytics, search, and keyword data, assembles the monthly picture, and writes a first-draft summary of what actually changed and why. A person reads and edits it before it goes anywhere near a client.
The triage agent
When Search Console flags coverage or indexing problems, it reads the report, matches each item to the right site, diagnoses it against the live install, and proposes the fix. Approval is per item, not per batch.
The Guardrails, Which Are the Interesting Part
Giving an agent shell access to production is a genuinely bad idea without constraints, and most of the engineering here went into the constraints rather than the capabilities.
Nothing destructive runs unattended. Read, diagnose, and report are automated. Write operations against a live site — schema changes, redirects, content updates, plugin work — surface as a proposal for a human to approve. The agent’s advantage is that it can look at four hundred things and tell you which six matter. That advantage does not extend to deciding which six should change.
A restore point comes first. Any change that touches the database or theme files is preceded by a backup, verified before the change proceeds rather than assumed.
Staging before production for anything structural. Major version upgrades and template changes get tested somewhere that isn’t the client’s live site during business hours.
Everything client-facing is reviewed by a person. Every report, every email, every published word. An agent can produce a competent draft. It cannot know that this particular client’s board meets Thursday, or that the last conversation ended badly, or that a number needs framing rather than stating.
Confirm before alerting. Automated systems that cry wolf get muted, and a muted monitor is worse than none. Our fleet sweeps require a problem to appear twice before anyone’s phone rings — the reasoning is in how we think about maintenance generally.
What This Changes for a Client
Three things, concretely.
Small things stop waiting in a queue. The most common failure in agency work isn’t that hard problems go unsolved, it’s that easy problems sit for three weeks because they’re not worth interrupting anyone over. When the diagnosis is free and instant, the threshold for acting drops.
Every site gets the attention that used to go to the loudest one. Manual processes concentrate on whoever emailed most recently. Automated ones don’t have favorites — the quiet client’s certificate gets checked on the same schedule as the noisy one’s.
The work that reaches a person is the work that needs one. Nobody here spends their day comparing plugin version strings. They spend it on the judgment calls, which is what you were paying for regardless.
What We Don’t Do
Worth being equally clear about, since the AI-in-marketing conversation has an honesty problem.
We don’t publish machine-written content to client sites without a human writing or substantially rewriting it. We don’t let an agent make strategy decisions. We don’t run unattended writes against production. We don’t use AI to generate fake reviews, synthetic testimonials, or backlinks. And we don’t pretend the tooling is more autonomous than it is — most of what we’ve built is very good at finding things and deliberately conservative about changing them.
That balance is the point. The failure mode of AI in this industry isn’t that the tools are weak. It’s that people wire them up without the constraints, ship something confidently wrong to a client site, and then have to explain it.
Why Any of This Matters to You
If you’re evaluating web partners right now, “do you use AI” is the wrong question — everyone will say yes. The better questions are:
- What specifically is automated, and what does a person still do?
- What happens before an automated process changes something on my live site?
- Who reads the output before I do?
A shop that has thought about this will answer in specifics. A shop that hasn’t will answer in adjectives.
If you want to see what our tooling says about your current site — the technical audit, the AI visibility read, the security and version exposure — send us the URL. It costs us a command to run, so there’s no charge and no obligation attached to it.
