Explore splitting Agents API out of Data Machine

[chubes4]

Data Machine has grown into two layers that are increasingly useful to separate:

1. A generic WordPress agent runtime substrate: agents, conversations, tools, memory, guidelines, message envelopes, run state, and agent calls.
2. Data Machine's automation/product layer: flows, pipelines, handlers, jobs, queues, scheduled automation, retention, content operations, and admin UI.

Prompted by a suggestion from Miguel Lezama (@lezama / migueluy), Chris wants to explore whether the generic layer should become a separate plugin called Agents API, with Data Machine becoming the first major consumer built on top of it.

Naming direction

Mirror the existing WordPress Abilities API precedent:

Surface	Abilities API	Proposed Agents API
Public name	Abilities API	Agents API
Plugin/repo slug	abilities-api	agents-api
Init hook	wp_abilities_api_init	wp_agents_api_init
Register function	wp_register_ability()	wp_register_agent()
Registry class	WP_Abilities_Registry	WP_Agents_Registry
Domain class	WP_Ability	WP_Agent
REST namespace	wp-abilities/v1	wp-agents/v1

Avoid making WP_Agents_API the main conceptual class. Core precedent favors domain objects and registries, not a monolithic API class.

Candidate Agents API scope

Move only primitives that could plausibly be useful to Intelligence, Dolly-like agents, Data Machine, Data Machine Code, or another future plugin without inheriting Data Machine's pipeline model.

• Agent identity and registry primitives.
• Agent ownership / acting context / permission ceiling contracts.
• Canonical message envelopes.
• Conversation runner contracts.
• Conversation store contracts.
• Run-state vocabulary.
• Loop event sink contract.
• Ability-native tool declarations and validation.
• Tool source providers.
• Tool execution result envelopes.
• agent_call primitive.
• Agent memory store interface.
• Guideline-backed memory store primitives.
• Memory/guideline change events.
• Generic prompt/guideline/memory composition.
• Portable agent bundle base primitives if they stay independent of flows/pipelines.

Likely Data Machine scope

Keep Data Machine as the automation engine and product surface built on top of Agents API.

• Flows.
• Pipelines.
• Step types: fetch, AI, publish, upsert, system task, webhook gate, agent ping.
• Handlers: fetch handlers, publish handlers, content handlers, MCP handlers.
• Queue semantics: flow queue modes, config patch queues, batch scheduling.
• Jobs and parent/child orchestration.
• Undo/effect envelopes.
• Retention tasks.
• Admin UI.
• CLI product surface such as wp datamachine flow, pipeline, jobs, retention, post, etc.
• Content operations: alt text, meta descriptions, image/link/indexnow helpers, post/taxonomy/block abilities.

Boundary test

For every class/function, ask:

Could a plugin use this without knowing about Data Machine flows, pipeline steps, handlers, or jobs?

If yes, it is a candidate for Agents API.

Ask the inverse:

Does this know about flow step config, handler slugs, queue modes, jobs, scheduled automation, retention, or DM's content workflow product?

If yes, it should stay in Data Machine.

Suggested migration shape

Do not start by ripping files around. Start by making the seams obvious in-place.

1. Identify the generic runtime primitives already in Data Machine.
2. Rename/refactor them away from Data Machine vocabulary where appropriate.
3. Split pure contracts and value objects first.
4. Split runtime services second.
5. Leave Data Machine adapters behind so AIStep, jobs, flows, and handlers consume Agents API.
6. Let Intelligence and Data Machine Code adopt the generic plugin directly after the substrate stabilizes.

Risks

• Extracting too early into a vague framework that still carries Data Machine concepts under generic names.
• Creating a plugin that looks core-friendly but exposes flow/pipeline assumptions.
• Over-indexing on AI terminology. The better core-shaped term is Agent, not AI Agent.
• Splitting before the contracts are boring enough to survive core review.

Outcome for this issue

This is exploratory. The first useful output is probably a concrete extraction map from current Data Machine classes into three buckets:

• agents-api candidate.
• data-machine stays.
• Needs seam/rename before deciding.

[chubes4]

Miguel shared a concrete plan for turning this from an exploratory split into an implementation path. Capturing the relevant shape here so the issue has the full proposal attached.

Miguel's proposed layer cake

intelligence
  Domain layer: wiki, briefings, digests.

data-machine
  Pipelines layer: fetch -> AI -> publish, flows, jobs, chat UI.

agents-api
  Substrate: lifted wpcom AI Framework + Channel + MemoryStore.

WordPress 7.0+
  Abilities API + WordPress\AiClient + wp_guideline CPT.

agents-api stays minimal and replaceable for wpcom, where it can drop in as a mu-plugin. data-machine keeps its identity around pipelines, scheduling, handlers, jobs, and UI. The duplicated runtime in Data Machine gets deleted.

Locked decisions in the plan

• Two plugins, not one: agents-api as substrate; data-machine as pipelines.
• Plugin slug: agents-api.
• wpcom install shape: wp-content/mu-plugins/agents-api/ plus a tiny loader.
• No backward compatibility for duplicated DataMachine\* runtime classes; hard cut in one release.
• In-RSM wpcom target: side-by-side PoC before 2026-05-22 proving coexistence with existing wp-content/lib/ai/; full Dolly migration stays post-RSM.
• Memory store ownership moves to agents-api.
• agents-api ships both GuidelineMemoryStore and MarkdownMemoryStore, selected via agents_api_memory_store.

Specific Data Machine duplication Miguel identified

Concept	Data Machine file	Agents API replacement
Agent loop	inc/Engine/AI/AIConversationLoop.php	\Agent::run()
AI client adapter	inc/Engine/AI/WpAiClientAdapter.php	runtime/Providers/AiClientProvider
Message DTO	inc/Engine/AI/MessageEnvelope.php	\WPCOM\AI\Message
Persistence	inc/Engine/AI/ConversationManager.php	\WPCOM\AI\Services\Conversation_Storage
Prompt builder	inc/Engine/AI/RequestBuilder.php	Context tree + \Agent::complete_backscroll
Agent registry	inc/Engine/Agents/AgentRegistry.php	\AgentsStore
CLI agents	inc/Cli/Commands/AgentsCommand.php	wp agents-api ...
CLI memory	inc/Cli/Commands/MemoryCommand.php	wp agents-api memory ...
Memory schema	inc/Abilities/AgentMemoryAbilities.php	MarkdownMemoryStore

Data Machine keeps

• inc/Engine/Pipelines/ pipeline templates.
• inc/Engine/Steps/ fetch / AI / publish step types.
• inc/Engine/Handlers/ content handlers.
• inc/Engine/Flows/ flow scheduling state.
• inc/Engine/Jobs/ job runner + Action Scheduler integration.
• inc/Engine/Logger.php pipeline logging.
• inc/Admin/ wp-admin pipeline + chat UI.
• inc/Api/Chat/ wp-admin chat endpoints + chat tools.
• Pipeline abilities such as post query, handler, flow abilities, etc.

Proposed migration sequence

Week 1: Agents API substrate

• Mirror wpcom layout at agents-api/src/lib/ai/.
• Lift MarkdownMemoryStore from Data Machine's SOUL/MEMORY/USER model.
• Replace self-host Conversation_Storage stub with real implementation backed by agents_session CPT and post meta.
• Add mu-plugin/agents-api-loader.php.
• Tag an initial substrate release.

Week 2: Data Machine delegates runtime

• Delete duplicated runtime files.
• Replace internal usages with Agents API runtime classes.
• Declare agents-api as required dependency.
• Make AIStep call Agents API runtime instead of constructing AIConversationLoop.
• Preserve pipeline behavior; only runtime delegation changes.

Week 3: Intelligence + verification + wpcom PoC

• Intelligence switches memory filter usage from datamachine_memory_store to agents_api_memory_store.
• Studio site verifies Agents API CLI, Data Machine pipeline smoke, and Intelligence wiki/briefing/digest smoke.
• wpcom PoC PR installs agents-api as a mu-plugin and proves coexistence with existing wpcom AI classes.

Validation needed before implementing

This is a strong plan, but the current repos have moved quickly. Before turning it into implementation issues, validate current state against the plan:

• Which of the listed Data Machine runtime files/classes still exist after the v0.94+ compatibility and message-envelope work?
• Does the newer canonical MessageEnvelope work map directly to \WPCOM\AI\Message, or should Agents API expose a WordPress-native envelope while adapting to wpcom classes?
• Is Conversation_Storage the public self-host abstraction, or should Agents API own a neutral store contract that wpcom adapts to Odie storage?
• Are public names like \AgentsStore core-shaped enough, or should the long-term surface be WP_Agents_Registry / wp_register_agent() in line with Abilities API?
• Should agents_session be a CPT, custom table, or guideline-adjacent storage?
• Where exactly is the Data Machine chat/session boundary: UI in Data Machine, but generic storage/runtime likely in Agents API?

Proposed next issue after this exploratory one

Create an extraction-map issue that inspects current main and classifies every relevant runtime class into:

• agents-api candidate.
• data-machine stays.
• Needs seam/rename before deciding.

That map should be the implementation checklist before the hard-cut deletion PR.

[chubes4]

Clarifying the intended boundary before this turns into implementation work:

I think Miguel's layer cake is the right direction:

intelligence  -> domain layer
data-machine  -> pipelines / automation layer
agents-api    -> generic agent substrate
WordPress     -> Abilities API, AI Client, guidelines, etc.

The important constraint: Data Machine must not depend on wpcom or Automattic AI Framework vocabulary directly.

So the references in the plan to \WPCOM\AI\Message, \WPCOM\AI\Services\Conversation_Storage, \Agent, and \AgentsStore should be treated as source-material / PoC names unless they are deliberately normalized into WordPress-shaped Agents API contracts.

The desired dependency is:

wpcom AI Framework ideas / implementation experience
        -> informs
agents-api public WordPress-shaped contracts
        -> consumed by
data-machine pipelines
        -> consumed by
intelligence domain features

Not:

data-machine -> wpcom AI Framework classes

And not:

agents-api = public wrapper around wpcom internals

Concrete naming direction should keep mirroring Abilities API where possible:

• WP_Agent
• WP_Agents_Registry
• WP_Agent_Message or equivalent neutral message envelope
• WP_Agent_Conversation_Store_Interface
• WP_Agent_Memory_Store_Interface
• wp_register_agent()
• wp_agents_api_init
• REST namespace wp-agents/v1

wpcom can then provide adapters for its existing internals. Data Machine should only know about agents-api public APIs.

The next useful step is still the extraction map proposed above, but with this extra classification:

• Generic WordPress-shaped API: candidate for agents-api public surface.
• Implementation borrowed from wpcom: useful source material, but must be renamed/adapted before public use.
• Data Machine product concept: stays in Data Machine.
• Intelligence domain concept: stays in Intelligence.

That keeps the shared vision intact while preserving the core-worthy constraint: Agents API should feel like WordPress, not like an Automattic-internal framework exposed sideways.

[chubes4]

In-place untangling plan before extracting Agents API

The right next phase is not to move files into a new plugin. It is to make Data Machine internally behave as if agents-api already exists, while preserving all behavior.

Current:
data-machine owns runtime + pipelines.

Intermediate:
data-machine still owns all files, but runtime contracts are isolated behind neutral seams.

Future:
agents-api extracts those seams; data-machine keeps pipelines and delegates runtime.

Current hard blockers / brittleness points

From the current Data Machine source, the main blockers are:

1. Runtime entrypoint still speaks Data Machine result/payload shape.
   AIConversationLoop::run() is a good adapter seam, but the contract is still AIConversationLoop::execute()'s array shape and the payload carries Data Machine concepts like job_id, flow_step_id, engine, configured_handler_slugs, persist_transcript, etc.

2. AIStep composes too much runtime context itself.
   inc/Core/Steps/AI/AIStep.php builds model/provider, user messages, tool policy, adjacent handler completion tracking, permission context, transcript policy, and then calls AIConversationLoop::run(). That is correct product behavior, but it needs a narrower handoff object before extraction.

3. Tool substrate and pipeline handler plumbing are mixed.
   ToolSourceRegistry has generic static registry behavior and pipeline-specific adjacent handler behavior in the same class. It imports FlowStepConfig, which is a pipeline concept. A future Agents API can own generic tool sources, but adjacent handler tools should remain a Data Machine provider.

4. Tool execution has Data Machine side effects.
   ToolExecutor handles generic ability execution, but also stages Data Machine pending actions and writes post origin tracking. Those are valuable, but the generic executor and Data Machine execution decorators need separation.

5. MessageEnvelope is generic in purpose but Data Machine-branded.
   MessageEnvelope is a strong extraction candidate, but its schema is datamachine.ai.message and callsites treat it as Data Machine's canonical shape. Before extraction, introduce the neutral message contract while keeping compatibility projection in place.

6. Memory store seam exists but is Data Machine-named.
   AgentMemoryStoreInterface, DiskAgentMemoryStore, and GuidelineAgentMemoryStore are already the right shape conceptually. The issue is naming/filter ownership: datamachine_memory_store should eventually become agents_api_memory_store, with Data Machine consuming the new seam.

7. Conversation store seam exists but includes chat-product concerns.
   ConversationStoreInterface composes transcript CRUD, session index, read state, retention, and reporting. Some of this is generic runtime storage; some is Data Machine chat UI/product behavior. Split the contract in place before extraction.

8. AgentRegistry mixes declaration with Data Machine materialization.
   AgentRegistry already mirrors WordPress-style declarative registration, but reconcile() writes the Data Machine agents table, bootstraps access, creates directories, and scaffolds files. A future Agents API can own declaration; Data Machine should own its persistence/scaffold adapter.

9. System tasks and retention live under Engine/AI.
   SystemTask, retention tasks, and content tasks are Data Machine automation/product layer, not generic agent substrate. Namespace placement makes the extraction boundary visually noisy.

10. Filters/hooks are still datamachine_* for generic runtime seams.
    That is fine today, but every generic seam should be cataloged as either staying Data Machine-specific or becoming an Agents API hook later.

Refactor-first phases

Phase 0: Extraction map

Create a current-main extraction map before changing behavior.

Buckets:

• Agents API public candidate: generic WordPress-shaped contract.
• Agents API implementation candidate: generic implementation, but naming/contract needs work.
• Data Machine adapter: glue that adapts pipeline/job/flow concepts into runtime contracts.
• Data Machine product: pipelines, jobs, handlers, queues, admin UI, retention, content ops.
• Intelligence domain: wiki, briefings, digests, domain brains.
• wpcom source material: useful reference, but not public vocabulary.

Phase 1: Contract firewall around the run loop

Goal: Data Machine calls a neutral runner seam without changing behavior.

Introduce in place:

• AgentRunRequest value object or normalized array contract.
• AgentRunResult value object or normalized array contract.
• AgentRunnerInterface / ConversationRunnerInterface.
• Data Machine's existing loop as DataMachineAgentRunner or equivalent internal adapter.

Keep AIConversationLoop::run() as the compatibility facade initially, but make it delegate to the runner interface.

Exit criteria:

• AIStep no longer knows the internal loop class.
• The runner request has no raw engine object.
• Pipeline-only values are grouped under an explicit Data Machine adapter context, not mixed into generic runtime fields.

Phase 2: Split pipeline tool sources from generic tool sources

Goal: Agents API can eventually own generic tool registration/execution, while Data Machine owns adjacent handler tool sourcing.

Refactor in place:

• Keep static/ability-native tools as generic source candidates.
• Move adjacent handler tool source behind a Data Machine provider class.
• Make the tool source registry accept providers without importing FlowStepConfig in the generic path.

Exit criteria:

• Generic tool registry code does not import DataMachine\Core\Steps\FlowStepConfig.
• Adjacent handler tools are clearly a Data Machine provider.

Phase 3: Split generic execution from Data Machine side-effect decorators

Goal: generic tool execution is pure; Data Machine adds product policies around it.

Refactor in place:

• Generic ability execution path: validate input, call ability, normalize result.
• Data Machine action-policy decorator: pending actions / preview / forbidden.
• Data Machine post-tracking decorator: post origin tracking.

Exit criteria:

• The generic executor can run a WordPress Ability without knowing about pending actions, jobs, or post tracking.
• Data Machine still gets identical behavior through decorators.

Phase 4: Neutralize memory store ownership

Goal: memory remains behavior-compatible but is ready to move.

Refactor in place:

• Add neutral alias/filter path in parallel conceptually: agents_api_memory_store as future owner, still wired by Data Machine for now if needed.
• Clarify DiskAgentMemoryStore as MarkdownMemoryStore candidate if it is actually the SOUL/MEMORY/USER markdown file store.
• Keep Data Machine file scaffolding as an adapter, not part of the generic store.

Exit criteria:

• Store contract does not mention Data Machine callers in its conceptual docs except as current implementation notes.
• File scaffolding and registry-driven memory seeds are outside the persistence interface.

Phase 5: Split conversation storage contracts

Goal: separate generic transcript/session persistence from Data Machine chat UI concerns.

Refactor in place:

• Keep transcript CRUD as generic candidate.
• Keep read state, UI listing, reporting, retention cleanup as Data Machine chat product unless proven generic.
• Make transcript storage normalize messages through the neutral message contract.

Exit criteria:

• Agent runtime can persist/retrieve conversation messages without depending on chat UI listing/reporting contracts.
• Data Machine chat UI still uses the aggregate store facade.

Phase 6: Split declarative agent registration from Data Machine materialization

Goal: mirror Abilities API style without losing Data Machine agent rows/access/scaffolding.

Refactor in place:

• Declarative registry: agent slug, label, description, default config, memory seeds.
• Data Machine reconciler: creates datamachine_agents rows, bootstraps access, creates directories, scaffolds files.

Exit criteria:

• Generic registry can exist without a Data Machine table.
• Data Machine reconciliation is a consumer of registry definitions, not the registry itself.

Phase 7: Namespace cleanup and readiness gates

Goal: extraction becomes mechanical.

Readiness gates:

• No generic runtime candidate imports DataMachine\Core\Steps\*.
• No generic runtime candidate requires job_id, flow_step_id, pipeline_id, or handler_slug as first-class fields.
• No generic runtime candidate calls Data Machine job/engine APIs directly.
• Data Machine-specific behavior is reachable through adapters/providers/decorators.
• Contract tests cover runner, message envelope, tool execution, memory store, and transcript store independent of full pipelines.

Implementation principle

Every phase should be behavior-preserving. If a PR changes product behavior, it is too large or in the wrong phase.

The split should become boring before it becomes physical.

The first concrete implementation issue should be the extraction map, not a file move.

[chubes4]

Code-level audit: first low-hanging untanglement

This is the first code-level pass for extracting a clean, reusable agents-api out of Data Machine by gradual, behavior-preserving untangling.

The goal is not to move files yet. The goal is to make Data Machine internally behave like it already consumes a future runtime substrate.

Current seams that already help

• AIConversationLoop::run() is already a central runner facade and supports datamachine_conversation_runner.
• MessageEnvelope is already a canonical normalized message shape.
• AgentMemoryStoreInterface / AgentMemoryStoreFactory already isolate memory persistence.
• ConversationStoreInterface already splits chat persistence behind a factory/filter.
• Tool declaration/execution has moved substantially toward Abilities API-native tools.

Those are good foundations. The issue is that the seams still carry Data Machine product vocabulary.

Hard blockers / brittle points by file

inc/Core/Steps/AI/AIStep.php

AIStep is the biggest product/runtime mixer.

Relevant couplings:

• Builds queue-derived user message and data packet context.
• Resolves adjacent flow steps and required handler slugs.
• Resolves pipeline tool categories.
• Resolves model/provider from Data Machine mode settings.
• Sets WordPress current user and agent permission context.
• Builds a Data Machine payload with job_id, flow_step_id, step_id, engine, pipeline_id, flow_id, persist_transcript.
• Calls AIConversationLoop::run() directly.
• Converts loop results back into Data Machine DataPacket output.

This should remain in Data Machine, but it needs a narrower handoff to the future runtime: a request/result object or normalized array that separates generic run fields from Data Machine adapter context.

inc/Engine/AI/AIConversationLoop.php

The runner is close, but still has Data Machine product concepts inside the loop:

• Uses payload fields like job_id, flow_step_id, configured_handler_slugs, persist_transcript.
• Emits datamachine_log directly.
• Calls RequestBuilder::build() directly.
• Calls ToolExecutor::executeTool() directly.
• Tracks pipeline handler completion inside the generic loop.
• Persists pipeline transcripts through Data Machine chat storage.

The most important future split: generic turn loop vs Data Machine completion policy / transcript policy.

inc/Engine/AI/Tools/ToolSourceRegistry.php

This is the lowest-risk first untanglement.

Problem:

• The class imports DataMachine\Core\Steps\FlowStepConfig.
• It owns both generic static registry tools and Data Machine adjacent-handler tools.
• gatherAdjacentHandlerTools() is pipeline-only behavior and should not live in a future generic tool source registry.

Why this is low-hanging:

• No behavior change required.
• Extract adjacent-handler source into a Data Machine provider class.
• Keep the same default source slug, same returned array shape, same order.
• ToolSourceRegistry becomes closer to an Agents API candidate immediately.

inc/Engine/AI/Tools/ToolPolicyResolver.php

Mixed generic policy and Data Machine product policy:

• Imports Agents, PermissionHelper, and FlowStepConfig.
• Generic pieces: mode presets, ability permission filtering, category filtering, deny/allow filtering.
• Data Machine pieces: pipeline policy args from flow step config, per-agent config from Data Machine agent table, permission helper capabilities.

This is probably second-wave work after ToolSourceRegistry because it has more behavioral risk.

inc/Engine/AI/Tools/ToolExecutor.php

Generic executor mixed with Data Machine side effects:

• Generic: validate tool parameters, execute Abilities API-backed tool, normalize result.
• Data Machine product: action preview / pending action staging, action policy resolver, post origin tracking tied to job IDs.

Future shape: generic ability executor plus Data Machine decorators for pending actions and post tracking.

inc/Engine/AI/MessageEnvelope.php

Good extraction candidate, but branded:

• SCHEMA = datamachine.ai.message.
• Tests assert Data Machine schema.

Do not change this first. Message contract changes are higher blast-radius. Add an adapter/alias later once the rest of the substrate boundary is clearer.

inc/Core/FilesRepository/AgentMemoryStoreInterface.php

Very close to extractable:

• Store is already a dumb persistence layer.
• Scope/read/write/list result objects are well-shaped.

Brittleness:

• Filter is datamachine_memory_store.
• Docs reference Data Machine callers.
• Disk store may be better named MarkdownMemoryStore in Agents API vocabulary.

This is a good later extraction candidate, not the first PR.

inc/Core/Database/Chat/ConversationStoreInterface.php

Useful seam, but too broad for runtime substrate:

• Transcript CRUD is generic.
• Session index, read state, retention, reporting are Data Machine chat UI/product concerns unless proven generic.

Future work: split generic transcript store from aggregate chat product store.

inc/Engine/Agents/AgentRegistry.php

Conceptually close to WP_Agents_Registry, but materially coupled to Data Machine persistence:

• Declarative registration is generic.
• reconcile() writes datamachine_agents, bootstraps access, creates directories, and scaffolds files.

Future work: split declarative registry from Data Machine reconciler/materializer.

Recommended first untanglement PR

Title

refactor(tools): split adjacent-handler tool source from generic source registry

Why first

It is the smallest behavior-preserving cut that makes a future Agents API boundary more real.

It removes this direct pipeline dependency from the future generic tool source registry:

use DataMachine\Core\Steps\FlowStepConfig;

Proposed shape

Add a new Data Machine-specific provider class, probably under a Data Machine namespace such as:

inc/Engine/AI/Tools/Sources/AdjacentHandlerToolSource.php

or, if we want the namespace to make the layer explicit:

inc/Core/Steps/AI/Tools/AdjacentHandlerToolSource.php

Responsibilities:

• Accept ToolManager and resolver args.
• Return adjacent handler tools exactly like the current ToolSourceRegistry::gatherAdjacentHandlerTools().
• Own all FlowStepConfig usage.

Then update ToolSourceRegistry so its default source map points at that provider instead of a method on itself.

Behavior-preserving constraints

• Keep source slug adjacent_handlers unchanged.
• Keep pipeline source ordering unchanged: adjacent handlers first, static registry second.
• Keep returned tool array shape unchanged.
• Keep filters datamachine_tool_sources and datamachine_tool_sources_for_mode unchanged.
• Add a smoke test that proves pipeline mode still resolves adjacent handler tools and non-pipeline modes do not.

Exit criteria

• ToolSourceRegistry.php no longer imports FlowStepConfig.
• Adjacent handler tool lookup lives in a Data Machine-specific class.
• Existing tests/smokes pass.
• No runtime behavior changes.

Second likely untanglement PR

After the source split, extract pipeline policy args out of ToolPolicyResolver::getPipelinePolicyArgs() into a Data Machine-specific adapter/helper.

That removes another FlowStepConfig dependency from a class that otherwise looks like a future generic tool policy resolver.

Third likely untanglement PR

Split ToolExecutor into:

• Generic ability/tool executor.
• Data Machine action-policy decorator.
• Data Machine post-tracking decorator.

This is higher value but higher risk than the tool-source split.

Bottom line

The first implementation should not touch agent loops, message envelopes, memory storage, or wpcom naming.

Start with the smallest pipeline leak in the future generic substrate:

Move adjacent-handler tool sourcing out of ToolSourceRegistry and into a Data Machine provider.

That is the first low-hanging fruit toward building Agents API in place.

[chubes4]

Added concrete tracking issues for the in-place untanglement series:

• Untangle tool policy: move pipeline policy args out of ToolPolicyResolver #1562 — extraction map: classify current runtime surface.
• Agents API extraction map: classify current runtime surface #1563 — split adjacent-handler tool source out of generic source registry.
• Untangle tool sources: move adjacent-handler source out of generic registry #1564 — move pipeline policy args out of ToolPolicyResolver.
• Untangle tool execution: split generic executor from Data Machine decorators #1565 — split generic tool executor from Data Machine decorators.
• Untangle agent registry: split declarative registry from Data Machine materializer #1566 — introduce neutral agent runner request/result boundary.
• Untangle memory store: neutralize ownership before Agents API extraction #1567 — neutralize memory store ownership before extraction.
• Untangle conversation storage: split transcript store from chat product facade #1568 — split transcript store from chat product facade.
• Untangle run loop: introduce neutral agent runner request/result boundary #1569 — split declarative agent registry from Data Machine materializer.

Suggested order:

1. Untangle tool policy: move pipeline policy args out of ToolPolicyResolver #1562, because it verifies the map against current main and prevents drift from this planning thread.
2. Agents API extraction map: classify current runtime surface #1563, first low-risk implementation PR.
3. Untangle tool sources: move adjacent-handler source out of generic registry #1564, next tool-substrate cleanup.
4. Untangle tool execution: split generic executor from Data Machine decorators #1565, higher-value but more behavior-sensitive tool execution split.
5. Untangle agent registry: split declarative registry from Data Machine materializer #1566, run-loop contract boundary after tool substrate is cleaner.
6. Untangle memory store: neutralize ownership before Agents API extraction #1567 / Untangle conversation storage: split transcript store from chat product facade #1568 / Untangle run loop: introduce neutral agent runner request/result boundary #1569 can run in parallel once Untangle tool policy: move pipeline policy args out of ToolPolicyResolver #1562 is complete, because memory, conversation storage, and agent registry are mostly independent.

The north star remains: no behavior change, no new plugin yet, no wpcom public vocabulary. Gradually make the future extraction boundary clean inside Data Machine first.