Problem
Data Machine delegates turn sequencing to WP_Agent_Conversation_Loop, but still builds a bespoke turn runner that owns provider request assembly, wp-ai-client dispatch, assistant response normalization, tool-call extraction, request metadata, usage capture, and runtime-specific error handling.
Existing Agents API issues cover mediated tool execution gaps, but the broader provider-turn seam is still implicit. Without a generic provider-turn adapter contract, each runtime that uses the conversation loop may need to write its own adapter shape and normalize assistant turns differently.
Desired contract
Agents API should define a storage-neutral provider-turn adapter contract for conversation runtimes:
- Input: canonical messages, tool declarations/catalog, model/provider/runtime metadata, turn context, budgets, and run/session identifiers.
- Output: canonical assistant message/content, normalized tool calls, usage, request metadata, provider diagnostics, and typed failure information.
- The adapter should compose with
WP_Agent_Conversation_Loop mediated tool execution rather than owning the tool loop.
- The contract should not assume Data Machine, wp-ai-client, a specific provider plugin, or a specific storage layer.
- Data Machine can implement the adapter using wp-ai-client and its provider/model resolution.
Acceptance criteria
- Agents API documents and/or exposes a provider-turn adapter interface or callable contract consumed by
WP_Agent_Conversation_Loop.
- The loop can run with an adapter that returns assistant content and tool calls while Agents API owns continuation, mediation, transcript events, and result normalization.
- Usage, request metadata, provider errors, and diagnostics have canonical fields or namespaced extension points.
- Data Machine can shrink its custom turn runner to provider request construction/dispatch and adapter implementation.
- Smoke coverage proves a fake provider-turn adapter can drive the loop without Data Machine loaded.
Boundary rule
Agents API owns conversation loop contracts and canonical turn/result shapes. Runtime plugins own provider dispatch adapters. Data Machine may be the first full implementation, but the adapter shape must remain provider- and runtime-agnostic.
Related
AI assistance
- AI assistance: Yes
- Tool(s): OpenCode (GPT-5.5)
- Used for: Audited Data Machine's conversation loop adapter needs and drafted this tracker for Chris to review and prioritize.
Problem
Data Machine delegates turn sequencing to
WP_Agent_Conversation_Loop, but still builds a bespoke turn runner that owns provider request assembly, wp-ai-client dispatch, assistant response normalization, tool-call extraction, request metadata, usage capture, and runtime-specific error handling.Existing Agents API issues cover mediated tool execution gaps, but the broader provider-turn seam is still implicit. Without a generic provider-turn adapter contract, each runtime that uses the conversation loop may need to write its own adapter shape and normalize assistant turns differently.
Desired contract
Agents API should define a storage-neutral provider-turn adapter contract for conversation runtimes:
WP_Agent_Conversation_Loopmediated tool execution rather than owning the tool loop.Acceptance criteria
WP_Agent_Conversation_Loop.Boundary rule
Agents API owns conversation loop contracts and canonical turn/result shapes. Runtime plugins own provider dispatch adapters. Data Machine may be the first full implementation, but the adapter shape must remain provider- and runtime-agnostic.
Related
AI assistance