You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -26,6 +26,7 @@ Treat `data-machine/agents-api/` like WordPress core substrate while it still li
26
26
27
27
-`agents-api` must not import Data Machine product namespaces.
28
28
- Data Machine may import and consume `agents-api` as product code.
29
+
-`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.
29
30
- Data Machine keeps flows, pipelines, jobs, handlers, queues, retention, pending actions, content operations, and admin UI.
30
31
- Later standalone extraction means moving the already-bounded module into its own plugin/repo and adding plugin bootstrap, release, dependency, and distribution ceremony.
31
32
-`ai-http-client` is not future architecture. It is only packaging precedent for bundled-then-extracted code.
@@ -93,6 +94,20 @@ The current namespace is intentionally mixed while extraction stays in place. Tr
93
94
94
95
Exit rule for this in-place phase: do not physically move broad namespaces just because they sit under `Engine\AI`. Move only once a class is generic by dependency direction, vocabulary, and tests; otherwise document it as a Data Machine adapter or product surface.
95
96
97
+
## Built-In Loop Ownership Decision
98
+
99
+
The in-repo `agents-api` module 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.
100
+
101
+
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:
102
+
103
+
- job, flow, pipeline, flow-step, handler, or queue payload keys.
104
+
- Data Machine logging and transcript metadata.
105
+
- adjacent-handler completion semantics.
106
+
- historical `AIConversationLoop::execute()` result normalization.
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.
110
+
96
111
## Agents API Public Candidate
97
112
98
113
These are closest to generic public contracts. Most should be extracted as contracts/value objects before services.
This audit records the remaining work after the first in-place untangling wave. The boundary is now mostly visible: Data Machine owns pipelines and automation; the future Agents API owns generic agent runtime primitives. The next phase is to make those primitives live behind an in-repo `data-machine/agents-api/` module boundary while they still ship with Data Machine.
10
10
@@ -27,6 +27,7 @@ Treat `data-machine/agents-api/` like WordPress core substrate while it still li
27
27
-`agents-api` owns the WordPress-shaped agent runtime vocabulary and contracts.
28
28
- Data Machine consumes `agents-api` as product code.
29
29
-`agents-api` must not import Data Machine product namespaces.
30
+
-`agents-api` owns runner interfaces, value objects, and generic contracts first; Data Machine keeps `AIConversationLoop` and the built-in compatibility runner until the loop no longer carries Data Machine job, flow, handler, logging, transcript, or legacy payload/result assumptions.
30
31
- Data Machine keeps flows, pipelines, jobs, handlers, queues, retention, pending actions, content operations, and admin UI.
31
32
- Later standalone extraction means moving the already-bounded module into its own plugin/repo and adding plugin bootstrap, dependency, release, and distribution ceremony.
32
33
@@ -72,7 +73,7 @@ Before standalone extraction, the in-repo module should satisfy these gates:
72
73
73
74
### 1. Runner Facade
74
75
75
-
`AIConversationLoop` still carries the old runtime name and owns built-in loop execution. It should not be physically extracted until the generic loop and the Data Machine completion/transcript policies are separated further.
76
+
`AIConversationLoop` still carries the old runtime name and owns built-in loop execution. It should not be physically extracted until the generic loop and the Data Machine completion/transcript policies are separated further. The current decision for [#1634](https://github.com/Extra-Chill/data-machine/issues/1634) is to keep `AIConversationLoop` and `BuiltInAgentConversationRunner` in Data Machine, while `agents-api` grows the runner contracts and value objects that a future generic loop would consume.
76
77
77
78
Target shape:
78
79
@@ -81,6 +82,7 @@ Target shape:
81
82
-`AIConversationLoop` remains a Data Machine compatibility facade until callers are moved to the new name.
82
83
-`AgentConversationCompletionPolicyInterface` and `AgentConversationTranscriptPersisterInterface` are in-place runtime collaborator seams; Data Machine provides the current handler-completion and transcript adapters.
83
84
- A future `AgentConversationLoop` or `WP_Agent_Runner` should not know about `job_id`, `flow_step_id`, `pipeline_id`, or handler completion policy.
85
+
- The built-in compatibility loop must not move into `agents-api` while it preserves historical `AIConversationLoop::execute()` result normalization, Data Machine logging/transcript metadata, adjacent-handler completion, or `ai-http-client` / `chubes_ai_*` provider compatibility.
0 commit comments