Introducing Protuno - Your Agency Automated the Wrong Half of the Job.
The writing got faster. The work that actually loses you clients did not move at all.
A client asks you a question once a year, usually over email, usually in a sentence that sounds casual. Is the site alright?
You answer yes. You are almost always right. But be honest about what that yes is made of: you opened the site last Tuesday, it loaded, nothing has come in on support, and the last time anything went wrong you found out within a day.
It is a good guess built from good instincts. It is still a guess.
The uncomfortable version of the question is the one nobody asks out loud.
Will this site crash? Not today.
Some Sunday, on a certificate you did not know had 9 days left, on a plugin that was pulled from the directory in March, on a PHP version that went end of life while you were busy shipping someone else’s redesign.
None of those three is a hypothetical.
Patchstack counted 1,614 plugins and themes removed from the WordPress.org repository during 2024 over security issues the developers never fixed, and a removed plugin stays installed and active until somebody notices.
A removed plugin does not uninstall itself. It stops receiving updates, it stops appearing in the search box, and nobody on your side gets an email about any of that.
The PHP one is worse, because it is not even a secret. 39.0% of WordPress installs are running PHP 8.1 or older, all of which are past end of life, with 7.4 alone accounting for 17.3%.
And php.net publishes every one of those dates years in advance. Nobody reads them.
Protuno exists because that question deserves an answer made of evidence instead of instinct.
The unbilled half hour on every client site
Every agency runs on work that never makes it onto an invoice.
The design goes on the invoice.
The build goes on the invoice.
The other thing does not: the half hour on a Tuesday when somebody opens a client site, takes a backup, runs four plugin updates, loads the homepage to check it still answers, clicks through to the checkout because one of those plugins touches Woo, and closes the tab.
Nothing to show a client, nothing to bill. Skip it for three weeks and one day it stops being a half hour and becomes a Saturday.
Now multiply it.
Fifteen sites, twenty, forty.
The work does not scale linearly; it scales worse, because each site accumulates its own history: the one on a legacy theme, the one whose owner installs plugins without asking, the one you inherited with a database nobody has ever cleaned.
And in most agencies there is nobody to hand the work to. The Admin Bar surveyed 622 people running WordPress agencies and found the median team size is one. One person, the whole portfolio, every Tuesday.
That same survey found that of agencies with no recurring revenue at all, 58.3% report being rarely or never profitable, which is the arithmetic underneath everything else in this post: the invisible work is exactly the work a retainer would pay for, and it is the first thing to go when there is no retainer protecting it.
The Admin Bar, 2026 agency survey, 622 respondents across 51 countries.
It is not a niche service either. In the previous year’s survey, of 1,233 web professionals, 93.1% said they sell this work, which made it the single most-offered service on the entire list.
Almost everyone sells it. Almost nobody has the hands to deliver it at the standard they described while selling it.
Why the site that fails is the quiet one
Ask anyone who looks after twenty client sites how they decide which one to open. The honest answer is that they open the noisy one. The client who emails. The site that broke last month, so it feels owed.
The one they touched most recently, because it is already in a tab.
That is a reasonable way for a person to triage and a terrible way to run a portfolio. The site that fails is almost never the one on your mind. It is the quiet one.
The client who never writes. The install you inherited two years ago and have not thought about since.
You cannot fix that by being more disciplined. Fifteen sites times a real check is more hours than the retainer pays for, and everybody in this industry has quietly agreed to price the work as though it does not take that long.
The standard slipped, and dashboards did not stop it
Nobody decided this. It happened one busy week at a time.
Checks that used to be weekly became monthly. Backups exist, but nobody has restored one, so nobody actually knows whether they work. Uptime is monitored on the homepage only, so a broken checkout on a store can run for a week without tripping anything.
The certificate renews automatically, until the automation breaks quietly and nobody is watching the thing that was supposed to be watching.
You can see the drift in public data, which is the uncomfortable part, because it means it is not only your portfolio. 24.3% of WordPress sites are running 6.8 or older. That is not one forgotten install in a corner.
It is close to a quarter of the most-used CMS on the web sitting several releases behind, looked after by people who would tell you, sincerely, that they keep their sites up to date.
The tools most agencies use are, if you look at them plainly, dashboards. Very good at telling you something is wrong. Not built to do anything about it.
So the alert arrives, and the alert becomes a task, and the task waits for a human with enough context to act on it.
Detection was never the bottleneck. The half hour afterwards was, and it still is.
WordPress core is moving slowly, and saying so
WordPress core has spent the last year building the plumbing for exactly this: an Abilities API that lets a site declare what it can do, and an MCP adapter that lets software ask.
And the people building it are being careful in public. Read access shipped. Write access was deferred. The contributors arguing for caution are the ones closest to the code.
That is the right instinct, and it is the same one this product is built on. Reading a site is safe. Changing one is not, and anything that changes a site should have to say so first.
How the free site audit works
Put a domain in the box on the homepage. There is no step two. No plugin, nothing installed, and you do not have to own the site to run it.
54 checks run against what the address can tell us from the outside, across certificates, security, performance, SEO, mail and DNS, commerce. Every one is read-only. Nothing is written, nothing is changed, and the site does not know it is being looked at any more than it knows a visitor arrived.
What comes back is a score, and underneath it the findings that produced it. Not only a grade. A certificate expires in 9 days
rather than Security: B minus
. Every one is written so you can forward it to a client without reading it first, because a report you have to translate is a report you will not send.
The full list of what it checks, and what changes once a site is connected, is in the documentation.
Connecting a site, playbooks, and Super Agents
An address only tells you so much. Connecting a site adds 31 checks that can only be read from inside the install: which plugins are actually active, what version of PHP is really running, whether the debug log is writing to a file anyone can download.
It takes about two minutes and the whole of it is: install a free connector, look at the list of things the site says it can do, and paste a credential your own WordPress created. The plugin keeps no copy. You can revoke it from your user profile at any moment, without asking us, and the connection dies immediately.
The three steps are written out here.
Playbooks: a fixed sequence of steps
A playbook is one job, written out step by step before it ever runs. Take a backup. Check the backup is sound. Apply these updates. Load the site. Walk the checkout. If the site stops answering, put it back.
No model decides at runtime what looks reasonable. You can read the entire sequence before you allow it, and it does the same thing on Tuesday that it did last Tuesday. Seventeen are built and switchable per site today, with more designed across the catalogue.
That determinism is the point. An agency cannot audit a vibe. It can audit a list of steps.
Super Agents: playbooks that run on a schedule
A Super Agent is a standing brief over a set of playbooks. It has a name, an area it looks after, and a schedule. Wren takes Care, Rook takes Security, Dash takes Performance, Iris takes SEO, Till takes eCommerce, Echo takes Marketing.
None of them is released yet. They are built and named and not live, and we would rather say that here than let you find it out on a client site.
How permission and rollback are enforced
The part we care most about is also the part that took the longest.
It is not hard to build something that logs into a WordPress site and changes things. It is hard to build something an agency will actually let near a client site.
Those are different problems, and most of this category solves the first one and hopes you do not notice.
So the design rule is one sentence: nothing writes to a client site because a machine felt confident.
Permission is set per site, and there are two settings. Read Only: it analyses and reports, and never changes the site. Execute: it may change files, the database and settings. A site you connect as a live site starts in Read Only. A staging site starts in Execute.
You set that per agent, and an agent only ever runs the playbooks you have attached to it.
Underneath that sit three structural guarantees, and they are structural on purpose rather than promised:
A backup has to be proved before anything writes. Taking one is not the same as proving one. A backup nobody has restored is a hope with a filename.
If the site stops answering after a change, the change comes out. The rollback is not an incident response you page someone for. It is part of the playbook that made the change.
On a site set to Read Only, the tools that could change anything are taken out of the run before it starts. The vulnerability watch reports rather than patches. An instruction is a policy. Taking the tool away is a good deal stronger than a policy.
Run history: the record of what happened
Every run across every site lands in one place, newest first. A playbook started on four sites is four runs, each with its own report.
This is the least exciting screen in the product and possibly the most important commercially.
An agency that can show a client what was checked, when, and what was done about it is going to win work from one that cannot.
Talent has nothing to do with it.
Proof does.
Credits and the visible balance
Work costs credits, and the balance is visible on every screen. That is a deliberate choice against the industry norm of discovering your usage at the end of the month.
If a playbook is expensive, you should feel it before you schedule it across forty sites, not after.
What is live today, and what is not
We would rather you heard this here than found it yourself after signing up.
Live today. The free audit. Put in a domain, get 54 read-only checks back across certificates, security, SEO and performance, with the literal finding written out.
It works now. It is the part of this you can use in the next two minutes.
Also live. The connector plugin, the abilities check, the credential flow and the dashboard. You can connect a site today and it stays connected.
Not live yet. The Super Agents.
Wren, Rook, Dash and the rest are built and named, their playbooks are written and counted, and not one of them has shipped.
They are not running on anyone’s sites today, including ours.
We could have written this post in the present tense and left you to work out after signing up which agents actually run. Plenty of launches do.
But the entire argument above is that you should be able to trust software near a client site, and a company that overstates its own release dates has already answered the question of whether it can be trusted with a backup.
The shipping order, from least risk to most
The sequence is chosen for blast radius, not for demo value.
First: the playbooks that only read, and the updates behind a backup that has been checked.
Plugin updates on a schedule.
A vulnerability watch that runs every morning and reads what is actually installed against the advisory feeds, telling you the morning something you run becomes a problem.
Reading a feed every morning is a machine’s job. It always was.
Then: database cleanup, uptime and certificate watch. The first group where the before and after is measurable, which is our bar for charging for something.
Then connectors. One integration layer, released once, rather than four integrations on four dates. You point it at something you already run, or paste an API or MCP server address, see what it can do, and grant only the parts you want.
Then the silent failures: deliverability, the backup verifier, licence expiry. A form that says thank you and throws the message away. A backup nobody has ever restored. A licence that lapsed and quietly stopped the security updates.
Last: the malware cleaner and WPDoctor. The two with the widest brief and the most to get wrong. They ship after the rollback path has been proven by the simpler agents, because the correct order to earn trust in is the boring one.
It would have been faster to ship the impressive playbooks first and add the safety net later. It also would have been the wrong product. An agency does not need software that is usually right about a client site.
What changes for the person doing the work
The interesting change is not that a machine does the updates. It is what happens to the person.
Right now the skilled part of your job and the mechanical part are welded together. The same person who can architect a migration is also the person clicking update, because it has to be somebody they trust.
The most expensive judgement in the building gets spent on the cheapest task on the list.
Pull those apart and the day changes shape. The mechanical work runs whether or not anyone got to it, on every site, at the same standard.
The person moves up a layer: reading what happened, deciding what to allow, handling the one case that genuinely needs a human, and talking to the client before the client notices anything.
That is a better job. It is also a better business, because it is the first time the fifteenth site costs roughly what the first one did.
We think that is where this whole category goes. Software does not replace the agency. It lets an agency carry more sites without proportionally more people, and finally get paid for work that was always invisible.
And the answer to the question at the top of this page stops being a guess.
Will this site crash? Probably not, and here is the certificate expiry, the backup that was restored to prove it works, the update that was applied on Tuesday and the checkout that was walked afterwards.
Not a feeling.
A record.
Who is building Protuno
Protuno is built by POSIMYTH.
Our products run on more than 500,000 WordPress installs, which means we have spent years on the receiving end of the thing this product exists to fix: the support ticket that starts with an update nobody watched, on a site nobody opened.
We are not arriving at WordPress operations from the outside with a general-purpose agent and a hope. We already know what breaks, because for a decade it has been breaking on installs that run our code.
Claim your free site audit
Do not use a demo site. Use a real one you look after and have not opened in a fortnight. The pitch is that plain: we think it will find something, and we think you would rather know.
Comments