Problem
WP Codebox has a generic host tool registry and execution/result schema in:
packages/runtime-core/src/host-tool-registry.tspackages/runtime-playground/src/command-router.tspackages/runtime-playground/src/playground-runtime.ts
This registry defines host tool declarations, JSON schemas, policy metadata, validation, execution, and wp-codebox/host-tool-result/v1 result envelopes.
That may be useful as a browser/sandbox transport primitive, but it overlaps with the tool surfaces in Data Machine and Agents API. If it hardens as-is, Codebox risks becoming a second generic tool system instead of a runtime that transports and enforces canonical tool calls from the lower agent substrate.
Desired outcome
Decide and document the ownership boundary for host/client tools:
- Agents API owns generic tool declaration, parameter binding, execution envelope, pending external-tool status, and result/event schemas.
- Data Machine owns product/runtime tool sources and Data Machine-specific tool policies.
- WP Codebox owns browser/sandbox transport, command routing, and enforcement of a resolved policy/tool catalog.
If Codebox needs a local registry, it should be explicitly scoped as a transport adapter over a canonical tool catalog, not an independent tool declaration system.
Acceptance criteria
- Document whether
HostToolRegistry is a Codebox-private transport registry or a public generic tool contract.
- If generic fields overlap with Agents API, align names/shapes with Agents API or wrap a canonical Agents API tool catalog.
- Codebox host tool results either use or map cleanly to canonical Agents API tool/external-tool result envelopes.
- Codebox does not introduce product-specific tool semantics or Data Machine-specific policy into the host tool registry layer.
- Smoke coverage proves a caller-provided canonical tool/policy catalog can be exposed through Codebox host tooling without losing transport diagnostics.
Boundary rule
WP Codebox can own browser commands and sandbox transport. It should not own the cross-product definition of what an agent tool is unless that contract has intentionally moved out of Agents API.
Related
AI assistance
- AI assistance: Yes
- Tool(s): OpenCode (GPT-5.5)
- Used for: Audited cross-repo tool/runtime overlap and drafted this tracker for Chris to review and prioritize.
Problem
WP Codebox has a generic host tool registry and execution/result schema in:
packages/runtime-core/src/host-tool-registry.tspackages/runtime-playground/src/command-router.tspackages/runtime-playground/src/playground-runtime.tsThis registry defines host tool declarations, JSON schemas, policy metadata, validation, execution, and
wp-codebox/host-tool-result/v1result envelopes.That may be useful as a browser/sandbox transport primitive, but it overlaps with the tool surfaces in Data Machine and Agents API. If it hardens as-is, Codebox risks becoming a second generic tool system instead of a runtime that transports and enforces canonical tool calls from the lower agent substrate.
Desired outcome
Decide and document the ownership boundary for host/client tools:
If Codebox needs a local registry, it should be explicitly scoped as a transport adapter over a canonical tool catalog, not an independent tool declaration system.
Acceptance criteria
HostToolRegistryis a Codebox-private transport registry or a public generic tool contract.Boundary rule
WP Codebox can own browser commands and sandbox transport. It should not own the cross-product definition of what an agent tool is unless that contract has intentionally moved out of Agents API.
Related
AI assistance