Flavor Agent — demo

Part of the Flavor Agent case study · see also the governance model.

Flavor Agent is a WordPress-native governance layer for AI-mediated changes: bounded recommendations, review-gated mutation, server-side attribution, freshness checks, and drift-safe undo.

The demo principle is simple: AI can request style work and inspect its trail, but approval remains a WordPress admin decision.

In-editor (governed UI)

1. Settings > Flavor Agent readiness — Connectors-owned text generation plus plugin-owned pattern/docs/embedding configuration.
2. A Block Inspector recommendation with bounded inline apply and undo.
3. A Global Styles or Style Book recommendation in review-first mode.
4. Settings > AI Activity with a pending external style apply.
5. Approve or reject the row; inspect provenance, freshness evidence, before/proposed/after, undo state, and — when a signing key is configured — the row’s attestation verify affordance.
6. Pattern recommendations in the native inserter shelf as browse/rank-first.

Programmatic — external agent via MCP

The same governance model an outside agent sees, end-to-end against a live site.

1. Discover. discover-abilities on the universal default server returns only the read/preview surface (16 public abilities); the seven recommend-* and four apply/activity tools live on the dedicated flavor-agent MCP server. Neither server exposes an approve/decision tool — approval stays admin-only in wp-admin.
2. Read. execute-ability on a read-only ability (e.g. get-active-theme, or a preview-recommend-* signature preflight) runs without invoking the AI Connector.
3. Propose. recommend-style returns a bounded, preset-backed operation plus review/apply freshness signatures, and records a diagnostic activity row.
4. Request. request-style-apply with the operation, the live currentConfig, and those signatures creates a pending row and mutates nothing; stale input is rejected as drift.
5. Approve. An administrator approves the pending row in Settings > AI Activity; a second freshness check runs against the live entity before the change applies.
6. Attest & verify. get-activity returns the row’s attestation.verifyUrl; with a signing key configured, anyone can fetch the envelope, JWKS, and live subject-state and verify the Ed25519/in-toto statement independently — no credentials.
7. Reverse. undo-activity restores the before-state when the live document still matches the recorded after-state, and emits a chained revert attestation.

Presenter note: attestation is key-gated — without a base64 Ed25519 secret it records no attestation rather than a fake one. The external MCP client authenticates with a WordPress Application Password over HTTPS.

The centerpiece evidence is not a successful apply. It is the boundary: external agents can request a governed style apply, read activity, and request undo, but no approval ability is exposed.