Written 4 Aug 2026 · a design pass, not a measurement · revisit with real telemetry the week after launch.
Nothing is running yet, so there is no baseline to profile. Everything here comes from the check catalogue, the connector contract, and arithmetic. Figures marked measured were established earlier in this project. Everything else is an estimate and is labelled as one.
01 · The thing that will actually break
2 playbooks, free forever, on every connected site.
That is a recurring cost that grows with adoption and is paid for by nobody, which makes the whole free tier turn on one question: does a free-tier Super Agent run ever call a language model? If yes, the free tier is a liability that scales with success. If no, it is close to free.
Cost per Super Agent run
Rule based, no model
~$0.001measured
Through Sonnet
$0.068 to $0.21measured
Applied to the free tier, priced as if both ran every day
100 connected sites200 runs per day
Rules: $6/moModel: $410 to $1,260/mo
1,000 connected sites2,000 runs per day
Rules: $60/moModel: $4,100 to $12,600/mo
10,000 connected sites20,000 runs per day
Rules: $600/moModel: $41,000 to $126,000/mo
Vulnerability Watch runs every morning; Plugin Updates runs weekly. The real run count is lower than this table, which takes two runs per site per day on purpose — a ceiling is the only figure worth planning against.
Decision
The 2 free Super Agent playbooks contain zero model calls. Not a cheaper model. Zero.
02 · This is achievable, and that is the point
Walk the steps and ask which one needs judgement
Smart Safe Update is the playbook behind Plugin Updates. Every step is a connector call, a comparison or a threshold.
01
Pre-flight readiness
Decide whether to run at all. If there are no updates, or the site is already in maintenance, it exits here and does nothing.
No model
02
Smart backup
Take a fresh backup labelled for this run. It never modifies a backup that already exists.
No model
03
Verify backup integrity
Confirm the backup is actually restorable before a single file is touched. If it is not, the run stops here and nothing is updated.
No model
04
Check requirements and compatibility
Give every plugin with an update a verdict and put the queue in order. Changes nothing.
No model
05
Apply updates safely
The only step that changes anything. One plugin at a time, with a health check after each, and an immediate rollback of that plugin if the site errors.
No model
06
Visual regression
Compare the key pages before and after to catch layout breakage that returns a 200. Skipped entirely when no screenshot tool is connected.
No model
07
Smoke test critical pages
Once everything has settled, confirm the homepage, checkout and contact form still work end to end. Reports only, because step five already handled rollback.
No model
08
Final report and cleanup
One short report, then put back everything step one changed and release the run lock.
No model
Vulnerability Watch is the same shape: a version list compared against a published feed, and the question of whether it is reachable on this site is a lookup against the vulnerability record, not an inference. It reports and it alerts. It does not update, deactivate or edit anything, so there is no judgement call in it either.
Deterministic is better here. The same input produces the same action every time, it is auditable when a client asks what touched their site, and it cannot invent a plugin name into a destructive call. Models earn their cost on the paid Super Agents, where somebody is paying for the thinking.
03 · Concurrency, given the connector contract
One channel, and it shapes everything
A signed HTTPS request to the site’s own connector plugin, which exposes everything WordPress can do. No MCP, no SSH, no application passwords, no database credentials. That single constraint shapes the whole design.
01
The site is the bottleneck, not us
Concurrency limits belong per site, not global
A backup on a 4GB site takes as long as it takes, and it runs on the client's shared host. A global concurrency number tells you nothing useful and will either starve big sites or hammer small hosts.
02
One run per site, always
Two Super Agents updating the same site at once is a corrupted install
This needs a real lock, not a convention. Claim work with a row level lock so two workers can never take the same site. SKIP LOCKED is what makes this safe across many workers with no coordinator, paired with a unique partial index so a site can only ever have one run in flight.
SELECT site_id FROM agent_queue
WHERE state = 'ready' AND run_after <= now()
ORDER BY run_after
FOR UPDATE SKIP LOCKED
LIMIT 1;
CREATE UNIQUE INDEX one_run_per_site
ON agent_runs (site_id) WHERE state IN ('running','awaiting_approval');
03
Do not run every site at 05:00
Spread deterministically, or you build your own thundering herd
Twenty thousand simultaneous outbound requests is a self inflicted spike, and it puts a herd on shared hosts that will get us blocked. Hash the site id into a slot instead. Deterministic means the same site lands in the same slot every day, so “why did this run at 04:12” is answerable, and it survives a restart without reshuffling.
slot = hash(site_id) % 720 // 720 slots across a 12 hour window
04
Verify is the expensive step in wall clock
Not the update. Budget for it.
Updating a plugin is one call. Loading the pages that matter, twice, and comparing them is many. Worker sizing should be driven by step 7, not step 5.
04 · Failure modes worth designing for now
Because designing later means designing after it hit a client
High
Backup fails or times out
Abort the run. No verified backup, no change. Never proceed.
High
Verify is ambiguous — page changed for unrelated reasons
Compare against a capture taken minutes earlier, not a stored baseline. Hash a stable subtree, not the whole body.
Medium
Site goes down mid update
Roll back on the next reachable connection, and say so loudly.
Medium
Host rate limits or blocks us
Back off per host, not per site. Several client sites often share one host.
Medium
Connector deactivated mid run
Treat as an abort, not an error. Revoking is allowed at any moment.
Low
Rollback itself fails
This is the one that ends the company. Page a human. Never let it fail silently.
That last row is why steps 2 and 3 are not negotiable, and why the rollback inside step 5 has to be tested harder than any other part of the system.
05 · What cannot be answered until there is telemetry
Three unknowns, named rather than guessed
Wall clock per run — sets how many workers are needed
unknown
Real distribution of site sizes — sets backup cost
unknown
False rollback rate — decides whether anyone trusts it
unknown
The two free playbooks launch 18 Aug 2026. See what is coming for the order everything else lands in, or the six Super Agents for what each one will do.