This map classifies Data Machine’s current agent/runtime surface for the Agents API extraction. The in-repo module phase is complete: Data Machine now consumes the standalone extra-chill/agents-api package/plugin for public contracts while keeping Data Machine product adapters in this repository.

Parent issue: Explore splitting Agents API out of Data Machine

Strategy update: Agents API blocker: update extraction docs around in-repo module strategy

Related blockers: standalone extraction umbrella, standalone skeleton plan (docs), in-repo module boundary, candidate relocation, wp-ai-client dependency contract, built-in loop ownership, backend-only boundary, agent category/capability metadata, REST surface decision, registration lifecycle, core-shape readiness checklist, one-shot AI boundary, and ai-http-client removal.

Namespace Map

Public contracts inside agents-api/ use neutral AgentsAPI... namespaces. Data Machine imports these contracts as a consumer; no compatibility alias ladder is maintained while Data Machine remains pre-1.0.

Current Strategy

The first phase built Agents API as an in-repo module:

data-machine/
  agents-api/
    agents-api.php
    inc/
    tests/
  inc/
    ...Data Machine pipelines/product code...

Data Machine now treats the standalone extra-chill/agents-api package/plugin as that substrate:

• agents-api must not import Data Machine product namespaces.
• Data Machine may import and consume agents-api as product code.
• agents-api owns runner interfaces, value objects, and generic contracts first; Data Machine keeps AIConversationLoop and the built-in compatibility runner while they still carry Data Machine job, flow, handler, logging, transcript, and legacy result-shape assumptions.
• Data Machine keeps flows, pipelines, jobs, handlers, queues, retention, pending actions, content operations, and admin UI.
• agents-api is backend-only and invisible by default: no admin menus, screens, human CRUD forms, React apps, or Data Machine product UI.
• Data Machine and other product consumers own any admin/product UI they build on top of the substrate.
• Standalone extraction means the bounded module now lives in its own plugin/repo with plugin bootstrap, release, dependency, and distribution ceremony.
• ai-http-client is not future architecture. It is only packaging precedent for bundled-then-extracted code.
• The future provider primitive is wp-ai-client, not Agents API. ai-http-client dies as part of #1027 / #1633.
• One-shot AI operations call wp-ai-client directly. Durable agent runs use Agents API, and Agents API provider code consumes wp-ai-client directly inside that runtime.
• Data Machine pipeline AI steps should not move to Agents API solely for provider dispatch. They only need Agents API when the product needs durable runtime semantics such as sessions, locks, memory composition, event sinks, multi-turn tool loops, or portable agent declarations.

Abilities API  -> actions and tools
wp-ai-client   -> provider/model prompt execution
Agents API     -> durable agent runtime behavior
Data Machine   -> automation product built on those substrates

Target Vocabulary

Mirror the WordPress Abilities API shape instead of importing Data Machine product names or host-specific implementation names into the public contract.

Registration Lifecycle

wp_agents_api_init intentionally mirrors the Abilities API registration window where practical: the module wires registry initialization to WordPress init, callbacks register definitions only while the public hook is running, and reads after initialization do not replay the hook.

The remaining intentional divergence is product ownership, not hook timing: Data Machine owns today’s materializer, tables, agent directories, access rows, scaffolding, and admin/CLI product surfaces while standalone Agents API owns only backend registration vocabulary and generic runtime contracts.

Boundary Rules

Use these checks before moving anything:

• If a plugin can use it without knowing about flows, pipeline steps, handlers, queues, jobs, or Data Machine content operations, it is an Agents API candidate.
• If it translates Data Machine concepts into runtime concepts, it is a Data Machine adapter.
• If it owns flows, jobs, queues, handlers, scheduled automation, retention, admin UI, or content ops, it stays Data Machine product.
• If it uses host-specific provider, storage, or implementation vocabulary directly, treat that code as source material only until normalized behind WordPress-shaped contracts.
• If it only needs to execute a single prompt/model request, it should use wp-ai-client directly instead of introducing Agents API.
• If it needs durable agent runtime behavior, it should use Agents API and let that runtime call wp-ai-client directly for provider execution.

Backend-Only UI Boundary

Agents API is a generic WordPress-shaped substrate. It should be usable by any plugin that wants to register, run, persist, or observe agents without adopting Data Machine as a product.

agents-api may own backend contracts and implementations for:

• registration vocabulary and registries.
• runtime request/result/message contracts.
• memory, transcript, tool, event, and permission-ceiling contracts.
• direct public WordPress APIs such as Abilities API and wp-ai-client.
• durable agent runtime behavior built above those public APIs.

agents-api must not own product/admin surfaces:

• admin menus, screens, list tables, settings forms, or React admin apps.
• human agent CRUD screens or workflows.
• Data Machine flow, pipeline, chat, bundle, queue, job, retention, or content-operation UI.

Substrate CRUD is allowed when it is backend-only and generic: interfaces/services for definitions, sessions, memories, transcripts, tools, and run state. Product CRUD belongs to consumers: screens, forms, routes, workflows, and opinionated management UX. Data Machine may provide those product surfaces while consuming agents-api; the dependency direction must not reverse.

Category And Metadata Boundary

Abilities API categories are not copied into Agents API v1.

Core’s Abilities API uses categories because abilities are many small executable actions. Category registration validates ability definitions, powers REST category discovery, and lets clients filter GET /wp-abilities/v1/abilities by action class. Agents are different: an agent is a runtime definition whose executable surface is its abilities/tool declarations, memory policy, run request, and permission ceiling.

The v1 boundary is therefore:

• No WP_Agent_Category, WP_Agent_Categories_Registry, or wp_register_agent_category() in the first standalone module.
• No category-based permission, tool policy, memory policy, or REST visibility.
• Data Machine UI grouping stays Data Machine product behavior.
• Future WP_Agent metadata can carry descriptive fields such as type, capabilities, or annotations, but those fields are non-authoritative unless a later issue gives them explicit semantics.

If a future REST or UI consumer proves category parity is needed, it should be added with Abilities API-style registration timing and validation instead of inferred from free-form metadata.

REST Boundary

wp-agents/v1 is reserved for a future backend substrate REST namespace, but the first standalone extraction should ship without public REST controllers.

Reasons:

• The PHP contracts are the extraction target; REST would freeze unsettled persistence, visibility, run-state, session, transcript, and permission decisions.
• Data Machine already owns product REST for flows, pipelines, jobs, chat/session switcher, agent files, bundles, and automation UI under datamachine/v1.
• A generic run endpoint must use AgentConversationRunnerInterface and generic request/result schemas, not Data Machine Action Scheduler jobs or pipeline execution vocabulary.

Reserved future shape:

Standalone skeleton docs should state that wp-agents/v1 is intentionally absent in v1. Adding REST later requires route schemas, permission callbacks, visibility flags, and non-goals that keep Data Machine product REST out of the substrate.

Bucket Summary

Current EngineAI Namespace Split

The current namespace is intentionally mixed while extraction stays in place. Treat DataMachineEngineAI as a staging namespace, not as an extraction boundary. Grep for the class or subnamespace below before assuming a file is part of the future Agents API runtime.

Exit rule for this in-place phase: do not physically move broad namespaces just because they sit under EngineAI. Move only once a class is generic by dependency direction, vocabulary, and tests; otherwise document it as a Data Machine adapter or product surface.

Built-In Loop Ownership Decision

The standalone agents-api package does not own Data Machine’s built-in loop implementation yet. Its current ownership line is the generic contract surface: runner interfaces, request/result value objects, message envelopes, runtime tool declarations, and collaborator contracts that a loop can depend on without knowing Data Machine product concepts.

Data Machine keeps AIConversationLoop and BuiltInAgentConversationRunner until the compatibility loop no longer needs Data Machine-owned assumptions. The loop must stay outside agents-api while it knows about or directly preserves any of these product concerns:

• job, flow, pipeline, flow-step, handler, or queue payload keys.
• Data Machine logging and transcript metadata.
• adjacent-handler completion semantics.
• historical AIConversationLoop::execute() result normalization.
• ai-http-client / chubes_ai_* provider compatibility.

Future extraction can move a generic loop only after those concerns are pushed behind collaborators such as completion policy, transcript persister, provider caller, request assembler, event sink, and Data Machine adapters. Until then, the enforceable boundary is: agents-api defines the contract shape; Data Machine owns the built-in compatibility loop that implements it for existing pipelines and chat callers.

Agents API Public Candidate

These are closest to generic public contracts. Most should be extracted as contracts/value objects before services.

Agents API Implementation Candidate

These are plausibly generic implementations, but should not move until naming and Data Machine assumptions are removed.

Data Machine Adapter

These should stay in Data Machine as compatibility glue if a generic runtime plugin appears.

Conversation Storage Boundary

Conversation storage is split in place, but only the narrow transcript surface is ready to treat as a generic Agents API candidate.

Do not decide an agents_session CPT, host-specific conversation storage, or a new Agents API filter name in this in-place clarification. The current goal is only to make the dependency direction obvious: Data Machine chat product consumes transcript persistence; transcript persistence does not require Data Machine chat product behavior.

Data Machine Product

These should stay in Data Machine. They may consume Agents API later, but should not move into it.

Intelligence Domain

Data Machine should not absorb Intelligence-specific vocabulary during extraction.

Host-Specific Source Material

These are reference points only. Do not expose them as public Data Machine or Agents API vocabulary.

Hook Name Map

This map records the in-place hook vocabulary while Data Machine still hosts the Agents API substrate. Generic runtime seams should use Agents API-shaped names; Data Machine product and compatibility seams keep Data Machine names. Hard-cut hook renames assume active cross-repo consumers are updated in lockstep; this slice’s known companion is the Intelligence tier-3 runner adapter update in Automattic/intelligence#285.

Hook And Filter Classification

Test Coverage Map

These tests currently pin the substrate most relevant to extraction.

First Seams To Make Boring

1. Consume extra-chill/agents-api as the standalone package/plugin boundary before moving broad code into that repository.
2. Split pipeline policy translation out of ToolPolicyResolver so the resolver no longer imports or reads FlowStepConfig.
3. Split AgentRegistry into a pure registry and a Data Machine reconciler that creates database rows, access rows, directories, and scaffold files.
4. Rename and stabilize message/result/store interfaces in place before moving namespaces.
5. Split provider request assembly from RequestBuilder so Data Machine directives/logging stay adapter behavior and provider dispatch targets wp-ai-client, not ai-http-client.
6. Split ToolExecutor into ability-native runtime execution plus Data Machine product hooks for pending actions and post-origin tracking.
7. Decide whether Agents API owns persistence tables or only contracts plus optional stores.
8. Keep host-specific provider and storage classes behind adapters. No public contract should require implementation-specific message, agent, or conversation-storage DTOs.

Non-Goals

• Do not move files as part of this map.
• Do not move broad runtime implementations into the standalone repository until their dependency direction, vocabulary, and tests prove they are generic substrate rather than Data Machine adapters.
• Do not rename runtime classes before the target contracts are settled.
• Do not make Data Machine or Agents API depend on host-specific provider or storage vocabulary.
• Do not make Agents API depend on ai-http-client; that package is only a packaging precedent and a removal target.
• Do not move Data Machine flows, pipelines, jobs, handlers, queues, retention, content ops, or admin UI into Agents API.
• Do not move Intelligence wiki/briefing/domain-brain vocabulary into Data Machine or Agents API.