A financial advisor we work with launched a book in September. The week it came out, he wanted the website to stop saying when it was coming and start saying “Now live: order here.” As far as he knew, that was one page. So he asked the site’s agent to change that page.
The agent came back and said the release date was on six other pages. Did he want those changed too?
He did. It made the changes on a draft copy of the site, he looked, he said go. That is a small thing. It is also the whole idea in miniature. Something that knows what your site contains, does the work, and checks with you before it matters. Scale that up from one page to everything a website is supposed to be doing, and you have a workforce.
What can an AI workforce do for a website?
Think about what a good agency does for a website in a month, and then imagine it happening continuously, without a ticket, with a person approving the parts that matter. Then think about what you pay for that month today: the retainer, the freelancer who does the bits the retainer does not cover, and the plugins and tools that each do one piece of it. A workforce is one monthly cost for the whole job, and it does not go up when you ask for more.
It keeps the site healthy without being asked. Uptime at three in the morning. Security patches the week they ship. The broken link a visitor would have found first. The form that quietly stopped posting to the CRM after a settings change on the CRM’s side, reconnected the same morning. Page speed watched per page, so the one that got heavy gets noticed before the conversion rate does.
It keeps the site current. The product that launched is no longer “coming soon” on any page, because the agent found all seven. The seasonal campaign page is retired on the date it should be. The team page matches the org chart. The pricing table changes when pricing does. The ordinary edits, the typo in a title, the runtime on a film listing, the floor plan swap, happen in minutes because someone on the marketing team typed them in plain English. Those are table stakes. Anyone can edit a page. The point is that nobody has to remember to.
It keeps the site found. It watches the questions your buyers are asking ChatGPT, Perplexity and Google, where you appear, which sources get quoted instead of you, and what a competitor answers that you do not. When it finds a question you have no page for, it does not send you a report about it. It writes the brief.
It keeps the site moving. Drafts arrive in your voice, from your own material, with every claim flagged for a source, ready for a person to edit and approve. The case study that has been in draft since spring gets finished because something kept bringing it back.
It keeps the site converting. A headline tested against another. The offer that stopped working, noticed and swapped. The right message to a returning visitor instead of the generic one.
And it tells you what happened, in a short weekly note and a longer monthly one, with the decisions pulled out from the data.
You already know what your site should be doing. The page for the new office. The answer to the question buyers keep asking ChatGPT. It is good work, and it keeps losing to this week’s priorities. A workforce exists so it stops losing.
An agent is an AI with a job description
A chat assistant waits for you to ask it something. It knows what you paste in, it answers, and it forgets. An agent has a role, the way a person on an org chart does. It knows what it is responsible for, what it is allowed to change, when to check in, and who it hands work to. It runs on a schedule, so the uptime check happens whether or not anyone remembered. And every action it takes is logged.
That difference shows up when you compare the three places you can get one. The right-hand column is what we build and run for our clients as part of an AI-native website.
| A chat assistant | Agents inside a software platform | Your Lynton website team | |
|---|---|---|---|
| Knows your business | Only what you paste in, every time | Only what lives in that platform | Everything, from one shared knowledge base about your company |
| Works without being asked | No | Within that product’s features | Yes, on a schedule, with a weekly note and a monthly report |
| Can change your website | No | Inside that vendor’s page builder | Yes. Draft-site preview, your approval, then live |
| Works with other agents | No | Rarely | Yes. Each agent has one job and hands work to the next |
| Shows you everything it did | No | Partly | Every action logged, in a dashboard you can open any time |
The middle column is where most companies will first meet an agent, because every platform vendor is adding them. They are useful as far as they go. They go as far as that product’s features, on that product’s terms, and they keep you inside it. An agent that lives in your page builder is a side project of a software company. Your AI vendor is your next lock-in problem covers what that costs over time.
The roles a website workforce needs
A workforce is a set of roles, not one assistant with a long prompt. Each role has one job, so it can be held to a standard and given only the permissions that job needs. All of them read the same knowledge of your business, and they hand work to each other. One job each, one shared brain, and the work passes between them. Here is the minimum roster.
The site agent. Responsible for a website that stays fast, secure and working, and for changes that get made when you ask. Watches uptime, security updates, page speed, broken links, and the forms and tracking that feed the CRM. Fixes the routine things itself and brings you the rest. Takes requests: “add a page for our Chicago office” comes back as a private preview, you approve it, it goes live. This is the role that runs on our clients’ sites today, and everything in the book-launch story was this agent.
The discoverability agent. Responsible for knowing how buyers find you, in search and in the answers LLMs give, and what to do about it. Watches the questions buyers ask, where you appear, which sources get quoted instead of you, and what competitors answer that you do not. Because it can see what the rest of the team shipped, it can tell you what moved and why. Hands content gaps to the content agent and technical fixes to the site agent.
The content agent. Responsible for keeping your content plan moving, in your voice. Watches the calendar and the pages going out of date. Brings you drafts written from your own material, every claim flagged for a source. Hands approved pieces to the site agent to publish.
The reporting agent. Responsible for turning everything the others did into something a person can act on in five minutes. Pulls the week’s changes, the speed and health numbers, the search and AI visibility movement, and the form submissions that reached the CRM, and writes the note. Flags what needs a decision and leaves out what does not.
The conversion agent. Responsible for what happens after a buyer arrives. Watches which pages lose people, proposes a headline or an offer test, runs it on approval, and reports what won. Hands winning changes to the site agent to make permanent.
Which of these are running on a given site, and which are coming, is a question for the team you work with. Ask us and we will tell you exactly which ones run on the websites we build today. The point here is the shape: one job each, shared knowledge, and hand-offs, so adding a role never means rewriting the others.
How a request moves through the team
The reason for separate roles is control, not capability. An agent with one job can be given narrow permissions: the content agent can draft but not publish, the site agent can publish but not decide what to write, the discoverability agent can recommend but not change a page. Every agent can read everything the others know. None of them can do the others’ jobs. When one finds something another should act on, it hands it over with the reasoning attached.
Here is one request, start to finish: a question your buyers are asking that your site does not answer.
-
Notices buyers asking an LLM how long a migration takes, and that a competitor is the one being quoted. Writes a brief with the question, the competitor's answer, and what yours should cover.
-
Drafts the page in your voice from your own case studies and proposals. Flags two statistics that need a source and one claim it could not verify.
-
Open one screen with the draft and a preview. Fix the claim, approve the rest.
-
Builds the page, checks links, speed and structured data, publishes it, and writes the change to the log.
-
Watches the new page. Reports when LLMs start quoting it, and which competitor it displaced.
-
Puts one line in Monday's note: the question, the page, the first citation, and the date.
Six steps, one approval, and the person in the middle spent five minutes on it. The same shape works for a broken form, a slow page, or a product launch. What changes is which agent starts it.
Your analytics, your SEO platform, your uptime monitor: each one hands you numbers and waits for someone with the time to act. That someone is now a team.
The more of the team you run, the more each agent knows, and the better the next recommendation gets. That compounding is the thing a single tool never gives you, because a single tool only knows its own corner. It is also why multi-agent systems are growing faster than the software stacks underneath them can support.
What a workforce should report, and what you should hold it to
A team you cannot see is a team you cannot trust. Whatever runs your site should put these in front of you, on a schedule, without being asked.
Health. Is the site up, is it patched, are there broken links or pages returning errors, are the data sources connected. This is the floor. If the workforce cannot tell you this every week, it is not watching.
Speed, per page. Not one score for the site. The events page and the gallery page have different jobs and different weights. You should be able to see which page got slower, when, and what was added to it.
Changes. Every request anyone made, who made it, what the agent did, when it went live, and how to undo it. This is the log that makes approval mean something.
Visibility. Clicks from search, average position, and visits that came from an LLM. Which questions you are being quoted for, and which a competitor owns. This is the number that will matter most in two years and that almost nobody tracks today. Measuring AEO impact is harder than it sounds, which is exactly why it belongs on the agent, not on a person.
Leads. Form submissions that reached the CRM, and the ones that did not. A workforce that reports traffic and not leads is reporting the wrong thing.
Content shipped against plan. What was drafted, what was approved, what went live, what is overdue.
Then the cadence: a short note each week with what happened, why it matters, and what is next, and a fuller report each month. Both should pull the decisions to the top and leave the raw numbers underneath for anyone who wants them. One client asked us, the day we handed over the dashboard, whether their requests would sit in a queue waiting for us. The right answer is no queue, a few minutes, and a log that shows exactly where each request is. If you cannot get that answer, ask why.
Agents propose. People publish.
Nothing should reach your visitors until a person approves it. You decide how much each agent may handle on its own, from “only report to me” to “fix routine problems and tell me after”, and you can change that at any time, per agent. Every change comes with a draft-site preview, a record of who did what and when, and a way to undo it.
Reconnecting a form that stopped posting to the CRM is routine, and most teams want that handled without a call. A new page is not routine, so it waits. The line between those two is yours to draw, and the log shows you where it was drawn every time.
A workforce can err in two directions. It can publish something wrong, which is the fear everyone names first. Or it can ask for confirmation so often that the person doing the approving stops reading what they are approving. The second is more common and more dangerous, because it looks like safety. The fix is the same for both: narrow permissions per agent, a preview for anything visible, and autonomy that widens as the log earns it. Who is accountable when an agent publishes something wrong is a question to settle before the first one does. The answer should be a person, named, on your side or your partner’s.
Why most websites cannot host a workforce
An agent can only act on what it can reach, and most websites were built to be reached by a person with a mouse.
Four things have to be true for an agent to change a site safely. The content has to be addressable: a release date is a field the agent can find, not a sentence somewhere inside a page. There has to be a preview: a draft copy of the site where the change can be seen before it is live. There has to be rollback: a way to put things back exactly as they were. And there has to be a log: a record of what changed, when, and on whose say-so.
A page builder provides none of the four. Content is stored as blocks of formatted text inside a database the vendor owns. The only way in is the vendor’s editor, built for clicking, or the vendor’s API, metered and limited to whatever the vendor chose to expose. There is no draft copy of the whole site, only a draft of one page. There is no rollback beyond “undo” inside the editor. And the log, if there is one, shows that a user logged in, not what they did. That is the general case we make in Bolt-On AI vs. AI-Native, and it is why every vendor’s built-in agent can write you a paragraph and almost none can safely change your site.
A site built as a content repository provides all four by default. Every page and every record is a file. Every change is a diff that can be previewed, approved, reverted and attributed. The agents read the same files your team edits. That is what AI-native means in practice, and it is why the workforce comes with the website rather than being bolted onto the one you have. Move the site first. Then the agents have something to work on. Five Signs Your Website Has Fallen Behind Your Business is the test for whether yours is ready.
What you get
Your people spend their time on decisions.
The routine work, the uptime, the patching, the broken link, the form that silently stopped posting, gets handled and reported instead of discovered at the worst moment. The research arrives before you ask for it: which question your buyers are asking, who is being quoted instead of you, which page is slipping. The requests your team makes get made, from a preview, the week they are decided. And the site gets better at this over time, because every role you add knows what every other role has already learned.
We spent sixteen years as a HubSpot partner running websites and marketing for clients, and we know exactly which parts of that work are routine and which need a person, because we billed for both. A workforce does the first kind. Your people do the second.
The research is free. So is the diagnosis. 60 seconds →