Evolve Refine from Notes into collaborative and agentic editorial workflows

What problem does this address?

The current implementation treats Review Notes and Refine from Notes as separate, manual steps. This limits the potential for a more cohesive, collaborative, and automated editorial workflow. So following up from #289 let's explore some iterations of Refine from Notes, including real-time collaboration, agentic workflows, and deeper integration with emerging AI interfaces.

What is your proposed solution?

These are exploratory enhancements and could be split into separate issues and PRs after further scoping. Its important to balance automation with user control and transparency of changes, so let's ensure there are reasonable human interactions to start a process, consider if we should interject review points along the way, and how to present the result to a human once AI updates are completed.

1. Real-Time Collaboration with "WordPress AI" user

Introduce a "WordPress AI" user (probably needs to be an actual user, but perhaps RTC allows for a virtual user?) that participates in editing via Real Time Collaboration.
AI-generated refinements appear as live edits in the editor.
Changes are visible and attributable, consistent with other collaborators.

2. Unified “Review & Refine” agentic flow

Combine Review Notes + Refine from Notes into a single pipeline:
- AI generates Notes (annotations)
- User reviews/accepts suggestions
- AI applies accepted changes in one pass
Reduce friction from multi-step workflows and enable a more cohesive editorial experience.

3. Integration with Chat Workspace (Chat experiment: Integration outside the editor and outside single-task AI use #282)

Surface workflows as named agent actions:
- “Review my draft”
- “Refine my draft”
Allow users to trigger these flows from both:
- Post Editor
- Chat Workspace
Ensure consistency between editor-native and chat-driven experiences.

4. Note resolution + revision traceability

When a Note is resolved via refinement:
- Add a comment from "WordPress AI" confirming the change
- Link to a visual revision/diff for that specific update
May require an auto-save per Note refinement

Moving this out a couple releases to allow the RTC functionality within Gutenberg to stabilize post-WP 7.0 so we can better integrate there (and thus require a specific Gutenberg version for this integration to work until WP 7.1 comes out with RTC included).

@jeffpaul

Since this issue is explicitly scoped as exploratory and split-friendly, here's a proposed breakdown based on what's buildable now vs. blocked:

Items 2 (Unified Review & Refine flow) and 4 (Note resolution traceability) can move forward now, building on the existing Editorial_Notes/Editorial_Updates experiments from #289. Note that #507 already covers part of item 4 (linking to Visual Revisions). Proposed split:

PR 1 — Refactor Editorial_Updates to refine + autosave per individual note, instead of the current batch-of-4 with a single autosave. This is a prerequisite for accurate per-note traceability and for a real accept/reject UX per note.
PR 2 (depends on PR 1) — Note resolution traceability: post a "WordPress AI" comment resolving each note on refinement, linking to that note's specific revision.
PR 3 (depends on PR 1) — Unified "Review & Refine" flow: merge the Editorial_Notes and Editorial_Updates sidebar UX into one pipeline — generate notes, let the user accept/reject/resolve individually, then refine only the accepted ones in a single pass. Keeps the human checkpoint @jeffpaul flagged earlier in Implement Refine from Notes batch processing and progress indicator #289 (no full auto-apply).

Items 1 (RTC "WordPress AI" user) and 3 (Chat Workspace integration) aren't buildable yet:

Item 1 depends on Introduce agent users to give AI agents an auditable identity #923 (agent identity) landing, plus Gutenberg real-time collaboration stabilizing. Worth noting RTC was pulled from both WP 7.0 and 7.1 over race-condition/server-load issues — it's back to testing with no confirmed target release, so this is further out than originally expected.
Item 3 depends on Chat experiment: Integration outside the editor and outside single-task AI use #282, which is still in design (no implementation to integrate with yet).

Plan to start on PR 1 and work through PR 2/3 from there, and revisit items 1 and 3 once their blockers clear. Let me know if this split makes sense or if you'd prioritize differently.

Item 1 doesn't need to wait for RTC. The Presence API plugin already shows who has a post open, and an agent can join from core's ability hooks:

add_action( 'wp_before_execute_ability', function ( $name, $input ) {
	$user_id = get_current_user_id();
	if ( 'core/edit-content' !== $name || ! wpai_is_agent_user( $user_id ) ) {
		return;
	}
	$room = 'postType/' . get_post_type( $input['id'] ) . ':' . $input['id'];
	wp_set_presence( $room, 'agent-' . $user_id, array(), $user_id, null, 60 );
}, 10, 2 );

wp_after_execute_ability removes the row, and the 60-second expiry covers a failed run. Agent labelling follows #923 (WordPress/presence-api#549).

@josephfusco

@josephfusco good reframe — verified the approach and it checks out: wp_before_execute_ability/wp_after_execute_ability are real core Abilities API hooks, and wp_set_presence() exists in WordPress/presence-api. presence-api#549 already scopes the agent-labeling side of this against #324, and correctly notes it follows #923.

To be clear on where things stand: this doesn't remove the blocker, it replaces a vague one with a concrete, more tractable one. Item 1 no longer needs to wait on full Gutenberg RTC (which is back to testing with no confirmed release), it needs:

Feat[Experiment]: Add Agent Users, dedicated accounts for AI agents #961 (Agent Users) — wpai_is_agent_user() doesn't exist in develop yet; PR is open, unmerged, currently blocked on review.
presence-api#549 — the row-labeling work itself is an open, unimplemented checklist.

Once #961 merges, this is a real, lighter-weight path for item 1 since it only needs presence/attribution, not live co-editing merge logic.

One open question for @jeffpaul / @dkotter: this approach means taking a dependency on presence-api, itself an experimental feature plugin. Worth deciding whether that's a soft/optional integration (degrades gracefully if presence-api isn't active) or something we'd want to handle differently, before this becomes a PR.

Tracking item 1 as unblocked-in-sequence behind #961 rather than "blocked on RTC" — will pick this up once #961 lands.

@jeffpaul

@jeffpaul @dkotter on the dependency question: RTC is a proposed consumer of presence as well, and WordPress/gutenberg-sync-engines#120 proposes requiring the Presence API plugin there. The plugin is built so presence and post locks can go into core ahead of RTC, and that path is tracked in WordPress/presence-api#550.

Until then, a function_exists( 'wp_set_presence' ) guard keeps the integration optional, and once presence is in core, the check always passes.

I think I'm fine with having a dependency on presence-api, though we can't take the approach of using the Requires Plugins header as that would require the presence-api be installed to use the entire AI plugin, which we're talking about just a single feature within the plugin.

We'd need to decide if we

Directly vendor the presence-api plugin, similar to what we're doing right now for the Secrets integration
Or automatically install the plugin when this particular feature is turned on, similar to what we're discussing in Add MCP Access experiment: adapter auto-install and ability exposure controls #992

I'd likely suggest option 2 here since the presence-api is already on WP.org

Navigation Menu

Repository navigation

Evolve Refine from Notes into collaborative and agentic editorial workflows #324

What problem does this address?

What is your proposed solution?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Evolve Refine from Notes into collaborative and agentic editorial workflows #324

Description

What problem does this address?

What is your proposed solution?

Activity

jeffpaul commented on May 18, 2026

zeus2611 commented on Aug 30, 2026

josephfusco commented on Sep 25, 2026

zeus2611 commented on Sep 27, 2026

josephfusco commented on Sep 27, 2026

dkotter commented on Sep 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions