what shipped this month, and the thread running through all of it.
a month is a long time when you build in public. June had a clear shape though, and it is worth naming before any feature list. the work split in two. the first half was making the agent's edits actually real on the page. the second was the layer around the editing: turning repeated work into one call, helping people who do this for clients know what to charge, and making the whole thing easier to learn.
here is where it stands, and where it goes next.
Respira for WordPress · v7.4.7 the builders got real
the rule i committed to this month: when an agent reports success, that should mean the change is live and correct on the page, not that a database write returned without an error.
on a deep pass through every supported builder i kept finding the same shape of bug. Respira wrote data in a form the builder didn't read, or skipped a step the builder needed to render, and reported success anyway. the page stayed blank or stale, and the agent had no way to know. so the rule changed. a write is not done until the rendered page is loaded and checked.
the two that matter most if you use these builders:
Oxygen 6 builds now produce real, editable sections, headings, text, buttons, and images. before, the agent was emitting element types a fresh Oxygen 6 site does not register, so it gave up and dropped everything into one raw code block. now it writes native Oxygen elements, verified rendering on a live site.
Divi 5 builds the same way. an agent describes a page in the natural shape it reaches for, and Respira maps that onto native Divi modules that actually render, instead of refusing the build and collapsing it to plain text.
alongside those, deleting a global class, a Divi preset, or an Elementor kit colour now leaves a recovery point. and when a value cannot be persisted in a form the builder reads, Respira names exactly what did not land and tells the agent not to retry blindly. none of it is glamorous. all of it is the line between a demo and something you would point at a client's site.
isolated draft vs duplicate-first
the safest-sounding idea in AI site editing right now is the isolated draft. the agent works in a sandbox, you preview, then you publish. it is a real improvement over editing live with no net. but look at where the risk actually sits. an isolated draft moves the danger to the publish step. the moment you publish, the live page becomes the experiment. and in practice that draft is usually scoped to one thing, theme files, while the riskier everyday edits, your pages and your page-builder layouts, still go straight to production.
Respira works in the opposite order. before it changes a page, it duplicates the current state and takes a snapshot. then the edit happens. if it is wrong, the live page is one call from where it was, because the original was never the thing being experimented on. that is duplicate-first: a production firewall, not a staging area, running on every write across sixteen builders. the restore is itself undoable, so a recovery step always has its own way back.
playbooks: the work you repeat, as one call
if you build WordPress sites for a living, a lot of the work is the same shape every time. spin up a service page for a new city. turn a finished project into a case study. rebuild a section from a house template. doing that through an agent step by step works, but you pay for it every time, in tokens and in the chance the agent does it a little differently than last time.
playbooks fix that. a playbook is a workflow you describe to the agent once. Respira saves it on your site as a single typed tool that shows up in the MCP catalog, so the next run is one call: "run the case-study playbook with client Acme, industry SaaS," instead of walking the agent through every step again. you don't write any JSON by hand. the agent authors it for you the first time, and you manage them in wp-admin under Respira, Playbooks.
two things make this safe to hand to an agent. every step still runs through the same audit log and snapshot belt as a normal edit, so a playbook is not a way to slip past your guardrails. and destructive operations are refused at authoring time, so a saved playbook cannot delete pages or restore snapshots on its own. it composes the safe building operations, around forty of them, and nothing that can quietly wreck a site.
the result is the repeatable half of agency work made cheaper, faster, and consistent: one tool call and roughly two hundred bytes of context per run, instead of a fresh instruction-by-instruction session every time.
knowing what to charge
if you edit WordPress sites for other people, two questions decide whether AI is a margin win or a fog you are guessing through. what did the AI actually cost me, and what do i tell the client it was worth. Respira now answers both, and they are two sides of the same job.
the cost side lives in Earn, a tab in the dashboard on every plan. it reads what your Claude Code work actually cost, from your own telemetry: tokens, dollars per session, spend over the last thirty days, a per-model split, and a run-rate forecast for the month. it attributes spend to the project and the client site it belongs to, so the cost of a job is a number, not a vibe. it never sees your prompts, your file contents, or your tool results. only the meter, not the message. on top of the raw cost sits a simple multiplier, because nobody bills at cost. the guidance i ship with it is around 2.5x for a standard retainer, since that has to cover your labour, your QA, and your warranty, and higher for specialty work. the point is not the exact number. the point is that you set your rate against a real cost instead of a guess.
the value side lives in the client report. the plugin can generate a structured activity report for any window of work: how many edits, which pages and posts and products were touched, how many snapshots and rollbacks stood behind the work, before-and-after excerpts of what changed, and, when you give it your hourly rate, an estimate of the hours saved and the money that represents. it comes in framings, and the one most people reach for is the agency client report. it reads like you did the work using a toolchain you chose, because that is what happened, not like a vendor co-wrote your invoice. there is an anonymise option for sharing it publicly, and the snapshots-and-rollbacks line is in there on purpose. "every change was reversible" is a real thing to be able to tell a client.
put the two together and you can do something most people in this space still cannot. quote a number you can stand behind, and afterward show exactly what it bought.
the abilities directory grew up
Respira's job is to connect an agent to WordPress, and increasingly that means connecting it to other plugins, not just core. WordPress 6.9 shipped the Abilities API, the standard way a plugin describes an operation an AI can discover and run. the /abilities page is now a live directory of that whole surface, rebuilt every week from the real registry in CI, not a hand-kept list. as of mid-June it indexes 485 abilities, across Respira's own tools and 20 third-party plugins that reach more than 30 million installs combined: Elementor, Yoast, WooCommerce, ACF, and more.
the part i care about most is the safety layer underneath it. when your agent calls a third-party plugin's ability through Respira, it does not go straight to your database. it passes through Inhale, the gateway that takes a snapshot before the write, logs it, and routes anything destructive through the approval queue. so duplicate-first is not only for the builders Respira knows intimately. it is for the long tail of plugins it has never met.
meet Sage
the honest barrier for a lot of people is not "can the agent do it", it is "what do i even ask". so this month i shipped Sage, an assistant trained on Respira's docs and on the field-tested prompts that actually work. Sage knows the product surface: which builder pages exist, how to connect a client, how playbooks and skills work, and the exact prompt to hand your agent for a job like a hero rewrite or an accessibility pass. when you are stuck, it points you at the right page or the right prompt instead of leaving you to guess.
it is available by voice and by text on respira.press, inside the dashboard, and on WhatsApp, in multiple languages, so you can reach it the way you actually work. it is deliberately a guide, not another thing editing your site. it helps you ask the agent the right thing. the agent, with its guardrails, does the rest.
where this sits in the bigger moment
three things are happening in the wider ecosystem this summer, and Respira lines up with all three.
the recent Claude Code change that separates interactive use from headless, programmatic use has people confused about what counts as what. Respira works entirely in the interactive layer: the browser, the WebMCP panel, and the interactive terminal. there is no Agent SDK or headless automation in the path, so that change does not alter anything about how you use it, and there is no new ceiling to work around. the honest answer is no impact, and that beats a clever one.
the MCP world is moving toward letting a server hand the client a piece of interface to render, instead of only text and tool calls. the proposed MCP Apps direction is essentially that. Respira's WebMCP panel already does a version of it, a real interface inside the browser driven from the server side rather than a wall of raw tool output. i am not claiming a finished standard. i am saying the shape Respira already ships and the shape the spec is converging on are the same shape.
and WordPress core's own AI effort is openly looking for Abilities and experiments to bring into the next release cycle. duplicate-first recovery feels like the kind of primitive that belongs in that conversation rather than locked inside one plugin. it is the safety model the whole platform will need once an agent editing a live site is the default and not the exception. i would rather contribute that pattern upstream than guard it as a moat.
the through-line
an agent that can edit your site is only worth having if you trust what it did, can undo what it should not have, can repeat the work that repeats, and can run the whole thing as a real business. June was me making each of those true. the builders one at a time, playbooks for the work you do over and over, Earn and client reports for the people doing it for clients, the directory and Inhale for everything Respira does not build itself, and Sage so none of it needs a manual.
the next few months are about carrying it past the edge of the plugin, into the clients people already use and the platform underneath them all. it happens in public, so you can watch.
— mihai
Join the conversation
0 comments · Respira accountNo comments yet. Be the first to weigh in.