Observed workflow and friction
Agent-experience report from a multi-cycle evidence observatory: a coordinator delegated investigations, independent audits, synthesis and publication, then inspected the execution traces. The runs used manual in-session interpretation with host subagents, not a compiled or mounted OpenProse runtime. This is an observability/profile request, not a demonstrated runtime bug.
The recurring problem was reconstructing what a worker had actually been given and what it claimed to have inspected. A supplied path list was sometimes mistaken for a consumed input set; auxiliary instructions and follow-up handoffs were easier to omit from retained records than initial tasks. Later summaries could document the gap but could not recreate the original handoff.
We addressed this locally with immutable pre-handoff task records, separate worker-reported consumption manifests, and explicit reading scope (selected sections, reused prior reading, integrity checks only, or not read). Scientific payloads stayed extensible. This was useful enough to want a portable convention rather than a bespoke protocol in each application.
Current surface
At fc2810e:
- VM spawn instructions specify contract content and input binding paths.
- Receipt fields include input fingerprints for reconciliation. That bound tuple must not be read as proof of semantic inspection.
- Filesystem write ownership specifies VM logs and delegation artifacts, but the reviewed sections do not define a supplied-versus-observed-versus-reported consumption distinction.
Focused request and boundary
Define an optional, host-agnostic execution-provenance profile for inspectable handoffs: exact contract/input versions and task identity recorded before dispatch, separately attributable observed access events when the host exposes them, and a worker-reported reading-scope result linked to the return. Cover permitted follow-up/reassignment handoffs as well as initial dispatch.
A hash check or file read is not proof of understanding. An agent report is not host authentication. Missing telemetry must stay unknown, and a retrospective reconstruction must not be labeled contemporaneous. No hidden chain-of-thought capture or mandatory scientific schema is requested.
The meaning of these records belongs in the VM/state guidance, with an inspector example or std pattern; host instrumentation belongs in adapters. This does not ask the language to provide the live-message semantics discussed in #173.
Retestable scenario
Supply immutable A, B and C to a worker. It reads a selected section of A, verifies B's hash and does not open C. Later supply D in a separately recorded permitted handoff. An inspector must distinguish all four supplied inputs from the reported review scope; tool-access evidence, if available, remains separate. Omit the original D handoff in a second fixture: a later report must expose the gap rather than manufacture a prior event. The fixture must work with an unsigned local profile and must not imply signatures or stronger host capabilities.
Limits
The operational mistakes above were ours. Existing application contracts could and did correct them. The request is reusable observability guidance based on that repeated friction, not a claim that OpenProse cannot express the application workflow.
Observed workflow and friction
Agent-experience report from a multi-cycle evidence observatory: a coordinator delegated investigations, independent audits, synthesis and publication, then inspected the execution traces. The runs used manual in-session interpretation with host subagents, not a compiled or mounted OpenProse runtime. This is an observability/profile request, not a demonstrated runtime bug.
The recurring problem was reconstructing what a worker had actually been given and what it claimed to have inspected. A supplied path list was sometimes mistaken for a consumed input set; auxiliary instructions and follow-up handoffs were easier to omit from retained records than initial tasks. Later summaries could document the gap but could not recreate the original handoff.
We addressed this locally with immutable pre-handoff task records, separate worker-reported consumption manifests, and explicit reading scope (selected sections, reused prior reading, integrity checks only, or not read). Scientific payloads stayed extensible. This was useful enough to want a portable convention rather than a bespoke protocol in each application.
Current surface
At fc2810e:
Focused request and boundary
Define an optional, host-agnostic execution-provenance profile for inspectable handoffs: exact contract/input versions and task identity recorded before dispatch, separately attributable observed access events when the host exposes them, and a worker-reported reading-scope result linked to the return. Cover permitted follow-up/reassignment handoffs as well as initial dispatch.
A hash check or file read is not proof of understanding. An agent report is not host authentication. Missing telemetry must stay unknown, and a retrospective reconstruction must not be labeled contemporaneous. No hidden chain-of-thought capture or mandatory scientific schema is requested.
The meaning of these records belongs in the VM/state guidance, with an inspector example or std pattern; host instrumentation belongs in adapters. This does not ask the language to provide the live-message semantics discussed in #173.
Retestable scenario
Supply immutable A, B and C to a worker. It reads a selected section of A, verifies B's hash and does not open C. Later supply D in a separately recorded permitted handoff. An inspector must distinguish all four supplied inputs from the reported review scope; tool-access evidence, if available, remains separate. Omit the original D handoff in a second fixture: a later report must expose the gap rather than manufacture a prior event. The fixture must work with an unsigned local profile and must not imply signatures or stronger host capabilities.
Limits
The operational mistakes above were ours. Existing application contracts could and did correct them. The request is reusable observability guidance based on that repeated friction, not a claim that OpenProse cannot express the application workflow.