Current behavior
/export (openagents.coder.atif_export.v1) captures plugin activity three ways, none typed:
- The loaded plugin's tool definition rides in
agent.tool_definitions (correct, keep).
- The load act itself — usage errors,
manifest_unreadable, and the success line — survives only as free text in extra.notices, with the artifact digest truncated (sha256:7c724f993da2…).
- The invocation is a normal agent-step
tool_calls entry with no plugin provenance.
An ATIF consumer reading steps cannot tell a plugin ran, which plugin, or which exact artifact.
What the spec provides (ATIF v1.7, harbor rfcs/0001-trajectory-format.md)
- v1.5+:
source: "system" steps may carry an observation for "system-initiated operations (e.g., subagent delegation, context management, environment reset, checkpoint creation)". A plugin load is exactly this class — a capability-surface change.
ToolCallSchema.extra is designed for per-call metadata ("e.g., timeout, retry count, tool version").ObservationResultSchema.extra for custom result metadata.
Contract
- On
/plugin load (success or refusal), append a source: "system" step: message is the human notice; observation.results[0] has source_call_id: null and extra typed as {event: "plugin_loaded" | "plugin_load_refused", code?, plugin: {name, version, artifact_digest (full sha256, never truncated), bytes, abi, timeout_ms, capabilities: {mounts: [], hosts: []}, manifest_path, tool_name}}.
- Stamp every plugin-backed tool call's
tool_calls[].extra with {plugin: {name, version, artifact_digest}} — per-invocation attribution, mirroring the tool.ran thread event and feeding the registry's usage counters from traces as well as threads.
- Full digests everywhere machine-read; prose may stay truncated.
extra.notices stays as-is for interface chatter.
Source: docs/plugins/2026-08-24-coder-plugin-demo-shape.md and OpenAgentsInc/openagents.com docs 2026-08-24-registry-network-strategy.md (usage receipts are the registry's substrate).
Current behavior
/export(openagents.coder.atif_export.v1) captures plugin activity three ways, none typed:agent.tool_definitions(correct, keep).manifest_unreadable, and the success line — survives only as free text inextra.notices, with the artifact digest truncated (sha256:7c724f993da2…).tool_callsentry with no plugin provenance.An ATIF consumer reading
stepscannot tell a plugin ran, which plugin, or which exact artifact.What the spec provides (ATIF v1.7, harbor
rfcs/0001-trajectory-format.md)source: "system"steps may carry anobservationfor "system-initiated operations (e.g., subagent delegation, context management, environment reset, checkpoint creation)". A plugin load is exactly this class — a capability-surface change.ToolCallSchema.extrais designed for per-call metadata ("e.g., timeout, retry count, tool version").ObservationResultSchema.extrafor custom result metadata.Contract
/plugin load(success or refusal), append asource: "system"step:messageis the human notice;observation.results[0]hassource_call_id: nullandextratyped as{event: "plugin_loaded" | "plugin_load_refused", code?, plugin: {name, version, artifact_digest (full sha256, never truncated), bytes, abi, timeout_ms, capabilities: {mounts: [], hosts: []}, manifest_path, tool_name}}.tool_calls[].extrawith{plugin: {name, version, artifact_digest}}— per-invocation attribution, mirroring thetool.ranthread event and feeding the registry's usage counters from traces as well as threads.extra.noticesstays as-is for interface chatter.Source: docs/plugins/2026-08-24-coder-plugin-demo-shape.md and OpenAgentsInc/openagents.com docs 2026-08-24-registry-network-strategy.md (usage receipts are the registry's substrate).