You look after a lot of client sites. You cannot open every one of them every morning.
And the one that breaks is never the one you opened.
Short answer: Protuno audits any WordPress site from its address. Connect a site and your own AI app fixes what you approve, with a backup first and Undo after.
What this post is, and is not: a short tour of what Protuno does, updated on 28 October 2026. Every screen in the film below is the real product.
The Protuno launch film, recorded from the live product.
What Protuno Does Today
Seven things, each one live in the product now.
What
What it means
Audit any site
54 checks from the address alone. Connect the Protuno plugin and 31 more read from inside the site, 85 in all.
Read or Execute
Set per site. Read analyses and changes nothing. Execute may change files, the database and settings.
Plain-word findings
Each says what to do next, and Fix in Claude opens your AI app with the request already typed in.
Fix, then prove
A backup is taken before every fix, and the fix can be undone from the run report. The next scan decides whether the finding is closed.
Your own AI app
The AI runs in your own AI app (Claude, ChatGPT, Claude Code, Codex, Cursor and others), on your plan there. Protuno has no chat of its own and no credits.
27 playbooks
Jobs written down step by step before they run. 10 can change a site and 17 only read it.
Routines and reports
Routines run a playbook on a schedule as a task in your AI app (Pro and Agency). Connectors let your agents read your outside platforms, and Pro and Agency add white-label reports.
A Real Fix, Start To Finish
On 5 October, on one of our test sites, Protuno fixed two findings. This is the run, as the report shows it:
Allow search engines to index the site.
Delete the publicly readable debug.log.
Check the site still loads.
Re-run the 2 checks: 2 of 2 confirmed fixed.
It passed in 6.8 seconds. The last two steps are the point: “fixed” means the site still loads and the original checks agree.
The real run report: four steps, none failed.
The Six Super Agents
Six named Super Agents: Wren (Care), Rook (Security), Dash (Performance), Iris (SEO), Till (eCommerce) and Echo (Marketing). Each owns a group of playbooks and looks after its part of every site, and they are live now, inside your own AI app.
When this post was first written, on 6 October, they were not live yet, and the post said so plainly. Since 27 October they are.
Try It On One Site
Pick the client site you trust least. Paste its address at protuno.com and run the audit. It needs no plugin and changes nothing on the site.
Short answer: Protuno is six agents, a catalogue of 27 playbooks (17 that only read a site and 10 that can change it), and 85 checks for running WordPress sites at agency scale. It has been live since 27 October 2026, and the AI runs inside your own AI app. The rest of this post is the September account of where we were, kept as written, including the things we got wrong badly enough to rebuild.
It is also the last of 60 posts on this blog, every one of which came out of actually running one of those checks.
What Protuno is
The six agents as they stood in September, with the playbook counts of that month. Today the catalogue is 27 playbooks, and the agents are live.
Agent
Area
Playbooks (September)
What it covers
Wren
Care
26
updates, backups, cron, certificates, domains
Rook
Security
17
exposure, headers, enumeration, hardening
Dash
Performance
16
TTFB, caching, compression, images
Iris
SEO
20
crawl, sitemaps, orphans, structured data
Till
eCommerce
17
checkout, cart, gateways, orders
Echo
Marketing
15
mail posture, tracking, reporting
That last sentence has appeared at the bottom of all 60 posts here. It will keep appearing until it stops being true, and I would like it to be the thing this blog is remembered for rather than any individual finding.
The five reversals
Each row cost real work to reverse, which is the only reason any of them are worth reading.
What we thought
Where we landed
What moved us
a site audit tool
Super Agents for ongoing operations
auditing is a one-off, agencies have the same problem every month
permission per agent
permission per site: read only or execute
the site is the blast radius, not the agent
our own WordPress bridge
the Soflyy WP Agent Connector
somebody else maintains the hard part, already in the ecosystem
automate the fix
automate the measurement first
three of my own checks returned confident wrong answers in a month
report everything found
report what changed
six sites produced 30 findings and 7 worth reading
Audit tool to operations. An audit is a document. It is true on the day you run it and decorative a fortnight later. Agencies do not have an audit problem, they have the same problem every month on forty sites. Building for the one-off would have been much easier and much less useful.
Two permissions to three. Read-only and execute sounds clean and is unusable. Everything worthwhile gets pushed into execute, which nobody enables, or read-only, which nobody acts on. The middle tier, where the agent proposes and waits, is where the actual work lives, and reading a real ability list off a live site is what convinced me.
Our own bridge to somebody else’s. We were going to build the WordPress connection ourselves. We use the Soflyy WP Agent Connector instead, over the core Abilities API. It is maintained, it is in the ecosystem, and the hard part is not ours to solve twice.
Fix first to measure first. This is the newest and the most expensive. Three times in a month, a check of mine produced a confident wrong answer, and all three are written up. Any check that triggers an unattended change now needs a second, independent measurement to agree with it. That reordered the build.
Report everything to report what changed. Six of our sites produced 30 findings and 7 worth telling anyone about. A report that lists all 30 every month teaches people to stop reading it.
Four of those five reversals share a shape, which I only noticed writing them out. Each one started as a decision that made the product easier to build and ended as a decision that made it easier to trust. Two permission tiers, our own bridge, fixing before measuring, reporting everything: all four were the convenient answer. None of them survived contact with a real site.
Where we actually are
Written so anyone reading this in six months can check whether it was honest.
Piece
State
Detail
agents defined and named
done
six, with their playbook sets
check library
done
85 checks across 8 areas
connector route settled
done
WP Agent Connector, application password auth
permission model
done
three tiers, per check and per site
running against live client sites
not yet
this is the gap, it is the whole gap
public availability
not yet
no date announced, and I am not going to invent one
Update, 28 October 2026: both not-yet rows above have changed. Protuno has been live on protuno.com since 27 October, and the AI runs in the customer’s own AI app, on their plan there. In September, two rows said not yet, and one of them was the only row that matters. Everything above it is preparation, and preparation is the part that is easy to mistake for progress when you are the one doing it.
I am not going to announce a date. I have watched enough software get announced into existence and then arrive as something else, and the cost of that is paid by people who made plans around it. When there is something to use, this blog will say so, plainly, in a post that says what it does and what it does not. That post is Introducing Protuno: Super Agents For WordPress.
What the blog itself produced
The blog was research, not marketing.
Thirty days of writing this blog
Detail
60 posts, one per operational check
each written after running the check, not before
201 graphics from measured data
no stock imagery, every table is a dataset
6 of our own sites audited and published
30 findings, including 10 exposed usernames on two
3 false findings caught before publishing
each by a second, independent measurement
20+ drafts blocked by our own gate
for thin evidence, uncited numbers, or banned phrasing
I want to be clear about the direction of causation, because it is the opposite of how this usually goes. We did not build the product and then write posts about it. The posts are where the checks got tested, and several of them changed the product. When a check was wrong, the post is where it was wrong first, in public, with the correction attached.
The eCommerce work is the clearest case. Probing a checkout without placing an order crashed on the exact failure it existed to detect, which is a bug I would rather find in a blog post than in a client’s store at midnight.
And auditing ourselves in public was uncomfortable in a useful way. Two of our sites hand out ten usernames to anyone who asks. Two DMARC policies enforce on 5% of mail. One domain sits at p=reject with no DKIM I could find. All of that is published rather than quietly fixed first, because the alternative was writing operational advice from invented examples.
The second wave, and what re-checking sixty posts actually found
This post originally closed out sixty posts, each written once. Since then, nearly all of them have been re-checked, every measurement re-run rather than trusted, every table re-verified against the live source rather than reused. That second pass is worth its own honest accounting, because it tested this blog’s own central claim, that a finding worth publishing is one you verified rather than assumed, against the blog itself.
Two posts needed real corrections, not expansions. This post’s own PHP end-of-life figure had undercounted the unsupported share by counting only the three largest dead branches instead of every branch with zero support: the true figure was 38.36%, not 32.8%, and the combined at-risk share was 63.15%, not 57.6%. A separate post’s quoted Google guidance no longer matched the source page, which had been rewritten since the original citation. Both are now corrected in place, with the correction shown rather than the original error quietly removed.
Several posts turned up genuinely new findings during the re-check that the original research missed entirely: a commonly-repeated Apache header rule that does not actually work, confirmed by testing it directly rather than trusting the syntax; a 610 megabyte, actively growing, publicly exposed debug log on one of our own live sites, found while re-verifying a post about exactly that risk; a crawl tool’s own orphan-page report proven wrong a second time, on a fresh crawl, independent of the first catch; a WooCommerce monitoring assertion that passed cleanly on a classic checkout and failed silently on a block-based one, discovered only because the same test was rebuilt on a different install rather than assumed to generalise.
And several findings simply held, exactly as first published: two of our own domains still enforce DMARC at pct=5, unchanged since the day that was first flagged. Two still run DKIM keys at 1024 bits where current guidance recommends 2048. One domain still exposes ten real usernames including a login literally named admin. None of that is a failure of the original research. It is confirmation that publishing a finding does not fix it, and that the honest version of this blog includes going back and saying so plainly when nothing has changed.
What happens next
More of the same, honestly. The check library grows, the unattended tier stays deliberately small, and the connector route stays as it is.
The specific next piece of work is the second-measurement requirement, because it is the one that changes existing checks rather than adding new ones. Every check that could trigger an unattended change needs an independent way to confirm what it found, and for some of them I do not yet know what that second source is. That is a real constraint on how fast the unattended tier can grow, and I would rather it grew slowly than confidently.
If you run WordPress sites for other people and something here was useful, the most valuable thing you can do is run one check across your whole portfolio and look at the shape of the answer. Ten hits means a standard you never set. One hit means a site to go and fix.
That habit is worth more than any tool, including ours, and it is available to you today. Nothing in these 60 posts needed software we have not shipped. It needed a browser, a terminal, and the decision to look.
If you want a starting point, the security and mail posts are where the findings were densest on real sites, including our own. Start there, and expect the first pass to be uncomfortable.
Straight with you as on every post here, one last time, as written in September: the agents were built and named, and not live yet. As of 27 October 2026, they are live.
The second wave changed that sentence not at all, and it changed almost everything around it. Sixty posts became sixty posts checked twice, two real corrections, a handful of genuinely new findings, and a longer list of things confirmed still exactly as broken as the day they were first found. That is what re-checking a body of work actually looks like when it is done honestly: not a victory lap, and not a quiet rewrite. A record of what moved, what did not, and which of those two categories you are still responsible for.
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.
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.
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.
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.
Agencies reporting they are rarely or never profitableBy how much of their revenue recurs
58.3%0% recurring
9.7%25 to 49%
4.5%50 to 74%
The survey is careful about this and so are we: stronger agencies gravitate to retainers, so the model reflects a healthy business as much as it creates one. The gap is still six to one.
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.
The audit takes a domain and nothing else. This is deliberately the lowest-commitment thing in the product, because it is also the fastest way to prove the rest is worth your attention.
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.
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.
The steps are fixed before the run. Your own AI app carries them out one at a time, and a step that changes a site waits for your approval in Protuno. You can read the entire sequence before you allow it, and it does the same thing on Tuesday that it did last Tuesday. There are 27 playbooks today, each switchable per site: 17 only read a site and 10 can change it.
That determinism is the point. An agency cannot audit a vibe. It can audit a list of steps.
Super Agents: named agents that own a group of playbooks
A Super Agent is a named agent that owns a group of playbooks. It has a name and an area it looks after. Wren takes Care, Rook takes Security, Dash takes Performance, Iris takes SEO, Till takes eCommerce, Echo takes Marketing.
They are live now, since 27 October 2026. They run inside your own AI app, on your own plan there. When this post was first written, on 31 August, none of them had shipped, and the post said so.
Step three inside WordPress. The plugin mints the application password, shows it once, and keeps no copy. The password here is masked for publication; on your own site it is a real value you copy and then never see again.
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. Every site starts in Read Only, and only the owner can turn Execute on, in Protuno and never from the AI app.
On top of that, each agent has a trust level on each site: Read, Ask or Auto. A new agent starts at Ask.
Underneath that sit three structural guarantees, and they are structural on purpose rather than promised:
A backup is taken before every fix. Taking one is not the same as proving one, and a backup nobody has restored is a hope with a filename, which is why every fix can also be undone from its run report.
A change can be undone. Undo is on the run report. It is not an incident response you page someone for.
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.
No credits to watch
Protuno does not sell or spend AI credits. The AI runs in your own AI app, on your own plan there, so there is no credit balance to watch. Protuno has three plans: Free, Pro and Agency.
Free covers 3 sites and all 27 playbooks. Pro covers up to 10 sites and Agency up to 25, and both add routines and white-label reports.
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.
Also live, since 27 October 2026. The Super Agents.
Wren, Rook, Dash and the rest now run inside your own AI app, with 27 playbooks between them.
When this post was first written, on 31 August, they were not running on anyone’s sites, including ours, and the post said so.
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. This is the order we planned on 31 August, kept as written because it explains why the safest jobs came first. Many of these playbooks are now live in your own AI app, and the current list is on the playbooks page.
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.
