Respira AER is live: every WordPress site, one conversation

Respira AER is the WordPress agent workspace in the Respira dashboard. It plans, builds, reviews and operates across the sites an account has connected, while keeping their context, approvals and receipts together. AER operates through Respira for WordPress, the secure runtime installed on each site; it is not a chat added to wp-admin. Version 9.0 adds the on-site readiness manifest and Open in Respira AER entry point.

Why it exists

i run more than one WordPress site, and the work does not begin or end inside one site's admin. It moves between sites, briefs, client feedback, checks, approvals and the next request. Most AI-meets-WordPress tools put a chat box inside wp-admin and start the context again on every site. i wanted the workspace above them instead: one operation with durable context, a clear scope for every run, and a record of what changed. A connected site can expose anywhere from a scoped few dozen tools to several hundred, so AER also has to choose the relevant tools rather than hand the whole catalogue to every model on every step.

How a run works

i type the request in plain words, or say it into the microphone in the composer, and pick which sites it applies to, one or all of them. Before the request goes to the model doing the thinking, a smaller, cheaper model from the same provider reads a compact list of that site's tools, names and short descriptions only, and answers with the handful it thinks the job needs. That short list gets merged with a small core set that is always present, and capped, normally at 64 tools and wider on the highest intensity setting, because every provider bills the whole tool list on every step and a model offered the full catalogue picks worse than one offered the right thirty.

Page and content edits go to a duplicate, not the page a visitor sees. In Ask mode, the default, those edits wait until i approve them, and i can also reject the duplicate outright. Plan mode answers with the steps and waits for me to run them. Auto mode runs without asking, the site's own confirmations included; it is there for the runs i have watched work, and it is never the default. Once a change run ends it leaves a receipt: which tools were called, how many tokens went in and out, what the run cost, how long it took, and the recovery information available for that operation. Reversible content work keeps a snapshot or undo; an operation that cannot be duplicated or undone is named before it runs. And a run can remember things about a site on purpose, through a small memory it can write to and read back next time, so the next question does not start from nothing.

Attach the brief, then steer

A request is rarely only words. A message takes up to 20 files and 24 MB: a zip or a whole folder, docx, doc, odt, pptx, xlsx, rtf, rtfd, pages, md, images and PDFs. The text, links and formatting come out of each one, so a deck or a spec reads the way it was written, and any site tool can take an attached file by its name: upload this picture, install this plugin, build a page from this HTML. And a run does not have to be left alone once it starts. Type while it is going and the run reads the note at its next step, then changes course without starting over.

A client can look without a login

Most of the work i do on a site is for somebody else, and the slow part was never the change. It was getting the person who asked for it to look. /run review-link makes a Murmur link: the client opens the page with no login, on any device, taps a spot and leaves a note, typed or spoken. Since plugin 8.9.2 the note has a speak button that uses the browser's own speech recognition, so a client on a phone can say what they mean instead of typing it. The notes come back to the dashboard and to Respira AER, each with the page and the element it points at. /run review-feedback gathers the open notes page by page and turns them into a plan with one step per page, applied on duplicates i approve. Murmur is on the Builder plan and up.

What it is not

It is not a chatbot boxed into wp-admin, tied to one site and one model. It is not a page builder: it works with the one already installed on the site, 17 of them today, and it never tries to replace it. Page and content edits go to a duplicate first; operations that cannot be duplicated are named before they run. And it is not the only interface allowed to reach the operation. Claude, ChatGPT, Codex, Cursor and other agents can connect directly to Respira for WordPress when they are the right execution surface. AER remains the home for the sites, context, plans, previews, approvals and receipts.

Bring your own key, honestly priced

For the public launch, Respira AER runs on a key from Anthropic, OpenAI or Google, pasted in once, or an OpenRouter connection. The key is sealed at rest and only opened inside a run. Respira does not mark up a single token: the provider bills what the request used, and it shows up next to the rest of the AI spend on the account, not as a separate line nobody can trace. A personal ChatGPT-plan bridge through a local Codex runtime exists as a limited test, but it is not a launch dependency or generally available path. Respira AER itself is included in every paid plan and every trial, no separate purchase, and attended runs on one site are included on all of them. Runs that keep going after the tab closes, and runs across several sites at once, draw from a monthly allowance: 20 on Builder, 40 on Builder 10 and 150 on Studio. Maker has none, so Maker stays to attended work on one site at a time. Annual billing raises the allowance by half rather than shrinking it, and a trial gets the Builder allowance so the cloud part can be seen working before anyone picks a plan.

The phone

Respira AER can be added to the home screen like an app: the same workspace, threads, approvals and receipts at phone width, with no separate mobile product to keep in sync. A run that needs my yes waits for it there exactly the way it would on a laptop. Tap the microphone and the browser's speech recognition puts ordinary text in the composer; nothing is sent until i press send.

What the 9.0 site runtime adds

AER lives in the Respira dashboard. Respira for WordPress lives on each connected site and gives AER native access to its builders, memory and safety controls. Version 9.0 makes that relationship visible in wp-admin without moving the AER workspace there.

• Open in Respira AER from wp-admin, so the site you are on is one click from a conversation about it.
• Ready for Respira AER, a checklist on the site that names the one thing to fix when it is not ready. Respira AER reads the same list.
• Murmur in wp-admin: live links and client notes, spoken ones included, next to the pages they are about, as well as in Respira AER.
• Site memory and Art Direction on screen where you work, one click from the page they govern.
• One security answer, wherever you ask: run the security audit from Claude, ChatGPT, Cursor or any other app connected over MCP, from Respira AER, or from the site's own endpoint, and the answer is the same. It includes the known vulnerabilities that match the installed plugins, themes and WordPress version, checked on respira.press against Wordfence Intelligence, each with the version that fixes it. When that database cannot be reached, the audit says so and never reports the site as clean. It runs when you or your agent ask for it.
• Receipts and recovery on change runs, with a snapshot or undo for reversible content work, whichever interface started it.

Respira AER is built for Respira for WordPress 8.9.0 or later. Version 9.0 adds the full readiness and wp-admin entry-point experience described above. The direct agent route runs on MCP server 8.3.25. A fully enabled site exposes 230+ core tools and abilities, and 105 more with the WooCommerce add-on, which is the catalogue the small model reads before it picks. Those numbers are read from the release data when this page is built, not typed into it. The full list of changes is in the release notes.

What is still being proven

Access began with a small release group so real runs could expose the weak edges before a public launch. Background runs, the kind that keep going after the tab closes, are the newest part of the workspace and the part i will watch most closely after launch. The product reports failure plainly and keeps unfinished approvals waiting for a person rather than treating an incomplete run as success.

When something breaks, the R&D tab files a bug report with the thread's state attached: the model, the mode and intensity, the sites and their plugin versions, the last messages with their tool calls and errors, and the run log. You see all of it under "What goes with it" before it is sent, and you can leave it out.

How to start

Respira AER lives at /dashboard/aer in the Respira dashboard, and from 9.0 wp-admin has a button that opens it on the site you are in. It needs a paid plan or a trial and, for the public launch, a provider key set once at /dashboard/settings/aer. The page with everything in one place is respira.press/aer. The direct MCP route is still there for Claude, ChatGPT, Codex, Cursor and the other agents on the MCP setup page; it can use an eligible AI subscription and keeps the conversation and WordPress content out of Respira's servers. The difference, including why the planned official OpenAI and Anthropic integrations belong to Respira for WordPress rather than AER, is in Use the AI subscription you already pay for.

Mihai