Flavor Agent — governance model

Part of the Flavor Agent case study · see also the demo.

Every change to a production site raises the same questions: who changed what, was it authorized, and can you prove the rollback? AI doesn’t get new questions — it gets the same ones, asked faster. Flavor Agent answers them structurally. The shorthand: AI proposes. WordPress approves.

AI Activity detail panel showing a Global Styles request failed state and recorded request metadata. — Bounded precondition: a Global Styles request failed closed and preserved the diagnostic row instead of silently dropping the rejection.

One precondition underneath everything below: the model can only propose what bounded schemas and operation catalogs can express. Proposals outside that vocabulary are rejected and preserved as diagnostics — never silently dropped.

Who changed what?

Every recommendation request and every applied change writes a server-side record with provenance — which provider, which model, which prompt, which route. An administrator can audit it without editor access. The compliance record lives on the server, not in someone’s browser session.

Verifies the audit contract · § Attributed

AI Request Logs table showing request time, operation, provider and model, token count, duration, and success status. — Attributed: AI Request Logs expose the request time, operation route, provider/model, token field, duration, and status outside the editor.

Was it authorized?

Structural and theme-level changes never apply silently — each one passes through an explicit review step before it touches the site. Change control enforced in the layer, not promised in a policy. Only narrowly bounded attribute updates qualify as inline-safe, and that classification is itself versioned and tested.

Verifies the review gate · § Reviewed

Verifies inline-safe bounds · § Bounded

Did anything change since?

A recommendation is only valid against the context it was generated for. Before anything applies, live state is checked against the recorded contract — if the site moved underneath it, a human edit or another process, the action is blocked instead of executing on outdated state. Unauthorized-change detection, on by default.

Verifies the drift checks · § Fresh

AI Activity search results showing recommendations blocked by stale context with a selected detail panel. — Fresh: stale-context rows are recorded as blocked outcomes, proving Flavor Agent refuses to act on moved-underneath state.

Can you prove the rollback?

Every recorded change can be undone — and an undo only executes while the live site still matches the recorded post-apply state. Drift blocks the rollback rather than letting it clobber later human edits. A provable rollback is one that cannot destroy work that happened after it.

Verifies the undo contract · § Reversible

AI Activity search results showing an applied style change with undo blocked status in the detail panel. — Reversible: undo can be blocked after drift, so rollback does not clobber later human edits.

AI agents are the newest actor passing through this layer, not the reason it exists. External agents get the same validation, review, and audit contracts through the WordPress Abilities API and MCP that the editor gets first-party — they can request changes, read scoped activity they are authorized to access, and undo eligible executed style rows. What they never get is approval. That stays with your team, in WordPress admin, on every apply.

External agents reach exactly four governed external-apply abilities — Global Styles / Style Book applies they can request, read status on, list, and undo. Approval is deliberately not an ability: the admin decision stays in Settings > AI Activity, guarded by manage_options, with a second freshness check at approval time.