Summary
Data Machine and Data Machine Code now use a generic runtime metadata convention on tool declarations/results to avoid hardcoding product-specific tool names in the agent loop. Track whether that contract should move into Agents API as substrate-owned tool runtime semantics.
Related shipped PRs:
Current state
Data Machine currently reads tool metadata in its caller-managed turn runner:
runtime.duplicate_policy = repeatable lets safe inspection tools be called repeatedly with identical parameters.
runtime.completion_signal = progress lets state-changing tools trigger immediate missing-completion assertion nudges.
This solved a product-boundary bug: Data Machine core should not know about Data Machine Code extension tool names like workspace_read, workspace_git_status, or create_github_pull_request.
Why this may belong in Agents API
Agents API already owns neutral pieces of the conversation substrate:
- tool declarations
- optional tool-call mediation
- tool execution result shape
- completion policy callbacks
- iteration budgets
- transcript persistence
If duplicate-call policy and runtime result metadata are generic behavior, the contract should be documented and/or implemented in Agents API rather than remaining a Data Machine convention.
Proposed direction
- Define a generic tool runtime metadata shape for declarations/results, likely under
tool_declarations[*].runtime and tool_result.runtime.
- Preserve product-agnostic keys such as:
duplicate_policy: repeatable
completion_signal: progress
- Have Agents API mediated tool execution propagate normalized runtime metadata into
tool_execution_results.
- Consider whether duplicate-call prevention should become an optional Agents API loop policy instead of caller-managed Data Machine behavior.
- Keep product-specific completion assertion wording/policy in Data Machine unless/until a generic substrate abstraction emerges.
Acceptance criteria
- Agents API has documented semantics for runtime metadata on tool declarations/results.
- Generic mediated tool execution preserves that metadata in tool execution results.
- Data Machine can eventually delete local helper glue or treat it as compatibility only.
- No product-specific tool names or Data Machine Code assumptions are introduced into Agents API.
Summary
Data Machine and Data Machine Code now use a generic
runtimemetadata convention on tool declarations/results to avoid hardcoding product-specific tool names in the agent loop. Track whether that contract should move into Agents API as substrate-owned tool runtime semantics.Related shipped PRs:
Current state
Data Machine currently reads tool metadata in its caller-managed turn runner:
runtime.duplicate_policy = repeatablelets safe inspection tools be called repeatedly with identical parameters.runtime.completion_signal = progresslets state-changing tools trigger immediate missing-completion assertion nudges.This solved a product-boundary bug: Data Machine core should not know about Data Machine Code extension tool names like
workspace_read,workspace_git_status, orcreate_github_pull_request.Why this may belong in Agents API
Agents API already owns neutral pieces of the conversation substrate:
If duplicate-call policy and runtime result metadata are generic behavior, the contract should be documented and/or implemented in Agents API rather than remaining a Data Machine convention.
Proposed direction
tool_declarations[*].runtimeandtool_result.runtime.duplicate_policy: repeatablecompletion_signal: progresstool_execution_results.Acceptance criteria