AI Approval Queue for WordPress, Agent Memory and Skills
Run an AI approval queue for WordPress with GoBuildWP Pro: hold agent writes for a person, give agents lasting memory and site instructions, reuse skills.
These three features answer three different questions about an agent working unattended: what needs a person before it happens, what the agent is allowed to remember between sessions, and what it should already know about how your site is built. Approvals is the one with teeth, since it stops an operation rather than shaping it. Memory is the one to be careful with, because anything stored there is content a future prompt will act on.
What you will do 6 steps
Decide what the queue should hold
Set the approval policy
Check who gets the email
Review a held write
Add site instructions
Save durable memory
When an approval queue is the right control
Safety profiles decide what is possible. Confirmation gates decide whether a destructive call proceeds. The approval queue decides whether a person sees a change before it happens, which is a different question and the right one for production sites with more than one operator.
It is set as a policy. Policy modes are off, writes and destructive. The initial policy is off; the legacy enabled switch migrates to writes and disabled migrates to off. Inspect the saved policy before connecting. Each agent credential can override the default with its own mode, including a trusted mode that lets routine edits run and holds destructive writes and code execution, and rules can always hold or never hold one ability or a family of them. Reads are never held, and a site that used the old on/off switch keeps that behaviour until someone saves a policy.
Holding every write is most valuable for unattended sessions, bulk operations, anything touching commerce or customer records, and any workflow where the person prompting the agent is not the person accountable for the site. It is usually unnecessary on staging.
Reviewing a held write
When the queue holds a write, the agent receives a structured response saying the operation is pending rather than a success. That distinction matters: a well-behaved agent will report that the change has not happened yet instead of claiming it is done.
Pro emails the site's admin address when a write is waiting. There is no recipients setting; a developer can send it elsewhere with the wppilot_pro_approval_notify_recipient filter. Make sure that address is monitored, not a personal inbox nobody reads, or the queue becomes a place changes go to be forgotten.
The Approvals screen shows the ability name and the arguments it was called with, not a diff. Read them, including the target, before approving. Approving without reading is worse than not having a queue, because it manufactures a paper trail that implies review happened.
A host that renders MCP Apps can show a held call as an approval card, with its input masked for secrets and email addresses, who asked and when. Behind the card sit wppilot/approval-list-requests and wppilot/approval-decide, and a decision there counts only when a person confirmed it: through the client's own confirmation prompt, a one-time wp-admin link or Chat. An agent's own confirm=true is refused, so on the default confirmation setting the card hides its buttons and points to this screen.
- The admin email address, or the filtered recipient, is monitored
- Reviewers know which abilities are high-impact
- Held writes are cleared on a defined cadence
- Rejections are fed back to whoever prompted the agent
Site instructions and persistent memory
Site-wide instructions are prepended to what every connected agent receives. Use them for durable operating rules: which safety profile applies, which builder the site uses, which conventions to follow, what must never be touched without asking.
Persistent memory is Pro and lets approved context carry across conversations, so an agent does not relearn your stack every session. Keep it factual and operational. It is not a place for credentials, customer data, or anything you would not want an AI provider to receive.
Both are inputs to a model, not access controls. Nothing written in an instruction or a memory grants or removes authority; the safety profile, the enabled abilities and the WordPress capabilities still decide what can run.
Skills for repeatable work
User skills are available in Free. Pro memory and the approval queue are separate controls. Skills guide how a particular job should be done on WordPress: the sequence, the checks, the ordering that keeps a change reviewable. Pro adds plugin-aware skill packs for the integrations you have installed.
Use a skill when a workflow will be run more than once. Encoding the read-before-write sequence in a skill is more reliable than hoping each prompt includes it.
- Instructions describe the site, not the task of the moment
- Memory contains no credentials or personal data
- Skills exist for the workflows your team repeats
- Everyone knows instructions are guidance, not permission
The Approvals and Memory screens in Pro
Setting up the AI approval queue for WordPress, field by field
The quick switch is on GoBuildWP, Settings: Require approval for writes, off by default. Turning it on makes Hold every write the default for every agent, and any agent that tries to change something is told the call was queued. Reads are never held, so an agent can keep inspecting the site while it waits.
The Policy section sets a default of Off, Hold every write, or Hold destructive and critical writes. Off removes the queue's hold; all other site gates still apply. The destructive mode covers operations the Free plugin rates destructive or critical and leaves code execution to the safety profile. A client's Trusted mode holds destructive writes and code execution while allowing routine writes. Named ability rules can override queue behavior for one ability or a family. Inspect the saved policy, select Save policy and verify a bounded held request.
- Default for every client: the mode most agents get
- Clients: a different mode for one credential, such as Trusted for a well-tested script
- Ability rules: Always hold for the abilities that must never run unreviewed
- Save policy, then confirm a test write is held as expected
Working the queue
The Approvals screen heads its list with Waiting for review and a count. Each held call shows the client that asked, the ability and the arguments it sent, with Approve and run or Reject. Approve and run executes the call at that moment, not when it was requested, and checks the ability's own permission again for the person approving, so a call held overnight runs against the site as it is in the morning and only if the approver may run it.
Email me when a write is held is on by default and goes to the site's admin address. The notice names the ability and how many calls are waiting, never the content of the change, and at most one is sent per quarter hour however busy the agent is. That limit means the email says go and look, not here is everything that happened; the screen is the record.
What the Memory screen holds
GoBuildWP, Memory lists every saved memory with its name, type and when it was last updated. Each memory has one of four types, User, Feedback, Project or Reference, which tells an agent how to treat it: a preference of the person, a correction to how the agent worked, a fact about this site's work, or a pointer to where something lives. Add new memory writes one by hand; Edit memory and Delete manage the rest, and a deletion cannot be undone.
The Memory abilities control at the top switches the agent-facing side on or off. With it enabled, agents can list, read, write and delete memories through wppilot/memory-list, wppilot/memory-get, wppilot/memory-save and wppilot/memory-delete. Disabling it hides those abilities and keeps every existing memory, so it is the safe way to pause memory while you review what has accumulated.
Questions this guide answers
How is the approval queue different from a safety profile?
Safety profiles decide what is possible and confirmation gates decide whether a destructive call proceeds. The approval queue decides whether a person sees a change before it happens, which matters most on production sites with more than one operator.
What does the agent see when a write is held?
A structured response saying the operation is pending rather than a success, so a well-behaved agent reports that the change has not happened yet instead of claiming it is done.
Can persistent memory be used to grant an agent more access?
No. Site instructions and memory are inputs to a model, not access controls. The safety profile, the enabled abilities and the WordPress capabilities still decide what can run.
What should not go into agent memory?
Credentials, customer data, and anything you would not want an AI provider to receive. Anything written there is read back into a later prompt, which makes a stale fact worse than no fact; review what has accumulated periodically.
When is a skill worth creating?
When a workflow will be run more than once. Encoding a sequence such as read-before-write in a skill is more reliable than hoping every prompt includes it.
Review noteRequirements and credential methods follow the shipped GoBuildWP source (WordPress 6.9+, PHP 8.0+). Client menus, account plans and third-party behaviour can change; use the installed version and live schema. Our evidence standard.
Inspect the held request and sanitized arguments, then approve or reject deliberately. Follow the recorded decision and execution result; a hold is not a rendered diff or a successful write. If execution fails, read its error before a retry. See the reference for decision retention and supported states.