Building Protuno: Five Things We Changed Our Minds About.
Sixty posts, six audited sites and three false findings later, here is where Protuno actually is and what we got wrong on the way.
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
| 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
| 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
| 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
| 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.
Comments