Agent Control Delivery Evidence: Delivery and Outcome Reconciliation

Status first

draft-abak-agent-control-delivery-evidence-01 is an individual IETF Internet-Draft, not an RFC or IETF standard. Revision -01 was published 4 September 2026, has intended status Informational, and expires 8 March 2027 unless updated or replaced.

The draft addresses a narrow but important agent-runtime problem: a system may decide to stop, suspend, revoke, constrain, cancel, quarantine, hand off or override an operation, yet evidence that the control was decided or dispatched does not establish that every intended enforcement point received it, applied it or produced the intended effect.

The document deliberately does not define a receipt format, wire protocol, authorization system, policy language, transparency service or audit regime. It defines the evidence distinctions that another protocol, runtime, telemetry system or profile would need to preserve.

Caution

This work is not a UHP extension. No UHP binding, HarnessRouter integration or native adoption relationship is established by the draft. Its value here is architectural: it gives precise language for claims about whether lifecycle controls actually crossed and took effect at the relevant enforcement boundaries.

Reconcile cancellation across every required target

Suppose a parent task delegates to two child runtimes. A cancellation is emitted once; the parent receives it, child A confirms enforcement, and child B produces no observation before the deadline. The aggregate result is not “cancelled everywhere.” Preserve a bounded obligation table tied to the instruction identity and resolved target-set revision.

Required target	Receipt	Enforcement	Effect observation
Parent runtime	Observed	Applied	Parent no longer admits work
Child A	Observed	Applied	Child execution stopped
Child B	Missing within window	Unknown	Unknown

The example is illustrative, not a measured run. Missing evidence from B does not prove B continued or stopped. Check the declared observer/window and retain malformed or conflicting observations rather than dropping them from the population. A successful cancel HTTP response is only one observation in this chain.

Current AIREP README, rechecked 4 October, targets v0.2.0-beta.1, with four artifact families, reconciliation and Python/Node verification; it still declares experimental, not stable, and keeps v0.1 frozen under its own rules. Its demo distinguishes a completed evaluation from an incomplete governance outcome. That is a useful precedent for runtime release: exit zero or accepted stop must not be displayed as proof of every intended effect.

The core evidence chain

The draft separates a control into several observations that are often collapsed into one word such as “sent” or “stopped”:

Evidence stage	What it establishes	What it does not establish
Policy/control decision	A component decided that behavior should change	That an instruction left the issuer
Issuer-side emission	A specific control instruction crossed the declared issuer boundary	That a target received it
Required-target resolution	Which enforcement targets were required for this reconciliation run	That any target received or applied the instruction
Receiver-side observation	A named enforcement target observed and matched the instruction	That the target enforced it successfully
Enforcement outcome	The target applied, refused or failed to apply the control	That the intended external/runtime effect was observed
Effect observation	An observer saw the resulting controlled state or behavior	That every required target was reached unless the target population is reconciled

The reverse inference is unsafe too. Missing acknowledgement or receiver evidence does not automatically prove non-delivery: evidence export can be delayed, an observer can fail, records can expire, clocks can disagree, identifiers can mismatch or evidence can be suppressed.

Instruction-target obligations

Revision -01 strengthens the multi-target case. When one control must reach more than one enforcement point, the reconciliation unit is an instruction-target obligation, not merely the parent instruction.

That distinction matters for distributed agent systems. A single cancel operation may fan out through a gateway, broker, sidecar, worker, tool runner or multiple delegated runtimes. A record that one branch received or enforced the instruction cannot be generalized to the other required targets.

A bounded reconciliation therefore needs an explicit Required Target Set or a deterministic rule for resolving it. Each required target can then be accounted for independently as observed, enforced, refused, failed, missing or otherwise unresolved under the applicable profile.

This prevents an aggregate claim such as “the task was stopped everywhere” from being inferred from one successful receiver observation.

Stable identity and content binding

The draft requires a stable control-instruction identity across issuer, transport, receiver, enforcement and reconciliation observations. If retries create distinct delivery attempts, the profile must also define attempt identity or an equivalent rule so evidence from different attempts is not silently merged.

Observations used for correlation also bind the instruction identifier to a digest of the exact instruction or a declared canonical projection. The applicable profile must identify the digest algorithm, canonicalization and projection rules.

That still has a strict limit: a matching digest establishes correspondence to bytes or a declared projection under the named algorithm. It does not prove semantic correctness, authority, truth or successful enforcement.

Bounded negative evidence and total reconciliation

One of the draft’s useful contributions is its treatment of negative and aggregate claims. “No receipt was found” is weaker than “this bounded reconciliation population was completely examined and this target had no matching receiver observation within the declared window.”

The draft therefore separates:

• positive observations — evidence that a particular stage was actually observed;
• bounded negative observations — evidence that a declared source/population/window was examined without finding the required observation;
• total reconciliation — accounting for the complete bounded set of instruction-target obligations rather than reporting only successful ones;
• population conservation — aggregate counts must reconcile to the declared population instead of silently dropping malformed, conflicting, duplicate, orphaned or indeterminate cases.

This is primarily an evidence-quality rule. It makes “all controls delivered” or “none were received” auditable claims with declared scope rather than labels derived from incomplete telemetry.

Security boundary: signed does not mean observed

The draft is explicit that cryptography cannot erase the observation boundary. A valid signature proves control of a signing key over signed bytes; it does not prove that the signer actually observed the asserted real-world event.

Likewise, a stable identifier or digest can help detect substitution and correlation errors but cannot prove that a control was authorized, semantically equivalent, successfully enforced or produced the intended outcome. Observer compromise, replay, identifier reuse, wrong-target binding and evidence suppression remain relevant threats.

For stronger claims, profiles may therefore require independent observation, freshness rules, commitments/nonces, explicit target-set accounting or other corroboration — while also recognizing the privacy and linkability cost of replicating more evidence.

Implementation evidence: AIREP is experimental

The draft’s Implementation Status section cites the AI Runtime Evidence Protocol (AIREP) as an experimental author-side implementation source for several of these distinctions. AIREP is a separate proposed evidence format, not an IETF standard and not part of UHP.

AIREP keeps v0.1 frozen under its own verification rules; its current v0.2 implementation target is v0.2.0-beta.1, explicitly experimental and not stable. The earlier v0.2.0-alpha.1 reference is historical and does not define current availability. The AIREP repository includes a control-delivery profile and reconciliation material, which is implementation evidence for the draft’s ideas rather than proof of standardization or broad adoption.

Relation to UHP lifecycle controls

UHP standardizes the client-to-server contract for running complete harnesses, including lifecycle operations such as cancellation and session handling. The Agent Control Delivery Evidence draft asks a different question: what evidence justifies saying that a lifecycle control crossed every required runtime boundary and actually took effect?

For a UHP deployment, the two layers can be kept separate:

Question	UHP	Agent Control Delivery Evidence draft
How does a client request/observe protocol lifecycle behavior?	Standardized by UHP	Out of scope
Which internal enforcement points must receive a control?	Implementation-specific unless UHP explicitly defines otherwise	Must be declared/resolved for the evidence claim
Does dispatch prove receipt?	No general inference	Explicitly no
Does receipt prove enforcement?	No general inference	Explicitly no
Does enforcement prove observed effect everywhere?	No general inference	Explicitly no; reconcile required targets and effect observations
Defines a wire protocol?	Yes, UHP is an HTTP contract	No; format-independent evidence requirements

A practical consequence is that a UHP server returning a protocol-level cancellation or deletion result should not be treated as automatic evidence about every internal runtime, worker or external effect unless the implementation actually observes and reconciles those enforcement boundaries.

That is an implementation-assurance concern around UHP, not a change to UHP conformance itself.

Source-pinned implementation pattern: Hermes makes connection outcomes backend-owned

A fresh post-v0.21.3 Hermes change provides a concrete, source-verified example of the same evidence discipline for connection/setup operations. PR #109517 first folds local MCP setup and managed app connections into one manage_connections surface backed by a server-owned connection operation. PR #110574, merged as ee2f5629b885c87395357d77714658716b08b708 on 14 September 2026, then moves managed connectors onto that operation instead of letting the Desktop renderer and model independently drive polling and completion.

The important boundary is not the card design. It is who is allowed to establish an outcome:

• one tool call creates one operation with a fixed target set, per-target states, one backend-owned deadline and exactly one settlement;
• target transitions pass through a closed transition table with named actors; for managed connectors, only the backend watcher may mark a target connected — the renderer cannot claim success merely because the user clicked a button;
• the backend reads the gateway once per operation tick and emits connection.update snapshots; the Desktop becomes an observer/controller of the operation rather than a second polling authority;
• the model does not receive OAuth/sign-in links in the Desktop path and does not receive an intermediate result while the operation is open; it receives the reconciled per-target outcomes only after settlement;
• resume replays the live operation and its server deadline, rather than reconstructing completion from local UI state;
• user continuation, deadline expiry and turn interruption terminate the same operation lifecycle instead of creating competing completion paths.

PR #110843, merged immediately afterward as 1ab32b212b3828be8239bd68ac3687756bf7c5c2, changes presentation only: it keeps the same backend/wire/store ownership while simplifying the connection card. That distinction matters because UI wording is not evidence of connection success; the authoritative state still comes from the operation.

This maps cleanly onto the draft’s evidence vocabulary. A user click or model request is a decision/input, the backend operation is the bounded target population, the gateway watcher supplies receiver-side observation, and the final per-target operation state is the reconciled outcome. None of those stages should be silently promoted into the next one.

Caution

This is Hermes runtime evidence, not an implementation of draft-abak-agent-control-delivery-evidence-01. The Hermes PRs do not claim the draft, do not emit its evidence objects, and do not change UHP, MCP or ACP wire semantics. The value is architectural: the implementation independently demonstrates why ownership, target identity and settle-once reconciliation matter when a harness spans model, backend, renderer and external authorization systems.

Source-pinned implementation pattern: Hermes stop now reaches detached background delegation

Hermes PR #115616 merged on 19 September 2026 as b71359066cbd8987b4b06ca7ea3bb3c556df41ea. It fixes a concrete control-delivery gap: a turn-level hard interrupt reached the agent’s _active_children, but background delegate_task units had been detached at dispatch so they could outlive the turn. A user could therefore issue /stop, receive a stop response for the foreground turn, and still have the detached child continue running and wake the chat later.

The patch makes the required target population explicit in code rather than treating the foreground agent as the whole execution tree:

• gateway busy /stop and the idle /stop tail now call tools.async_delegation.interrupt_for_session for that session’s detached units; /new shares the busy helper and keeps its existing idempotent reset semantics;
• TUI/Desktop session.interrupt fans out by the owning UI session and spawner identity, while a viewer session is not allowed to stop another execution surface’s work;
• the ACP adapter’s cancel path performs the same session/spawner-scoped fan-out; CLI /stop was already process-wide through interrupt_all and did not need the new path;
• deeper delegation is stopped recursively because nested delegations beyond the background root are synchronous and therefore remain in each child’s _active_children fan-out;
• an interrupted child now completes with status: interrupted, preserves its last real assistant text as the partial summary, and keeps the synthetic Operation interrupted. marker as the error rather than losing the useful work-in-progress.

Upstream’s PR records two regression tests that were red on the stated pre-fix origin/main and green on the patch, plus live gateway and TUI/WebSocket reproductions. In the gateway live repro, the pre-fix grandchild continued ticking and no completion arrived within 150 seconds; after the fix the registry was empty by the +12 second observation and the interrupted completion wake arrived about 1.0 second after /stop. Those measurements are upstream PR evidence, not independent UHP-site benchmarking.

At the original 19 September cutoff, Hermes main was 03fee43ca344ead7245a3b0ae20d38de0ae75642, fourteen commits ahead of the merge with b7135906 as its merge base. The published stable at that cutoff was Hermes Agent v0.21.3 / v2026.9.14; this was development evidence at that date. Current stable is v2026.9.24 / Agent v0.21.5. A fresh GitHub ancestry check on 4 October confirms b7135906 is included in that tag, so the stop fan-out is released behavior; the original upstream timing measurements remain pinned to their reviewed revision.

The evidence lesson is narrower than “stop succeeded”: detached execution changes the required target set. A foreground interrupt is issuer-side action toward one enforcement point; it does not establish that separately owned background work received or enforced the control. The fix closes that gap by resolving and addressing the session’s detached delegation records, then returning each stopped child as an interrupted completion with partial output.

Caution

This is Hermes runtime/adapter behavior, not a change to UHP cancellation, ACP wire semantics, or the Agent Control Delivery Evidence Internet-Draft. PR #115616 also leaves a separate interrupted-turn replay/persistence duplication concern identified in its issue discussion untouched. The evidence here supports stop fan-out and partial-result finality, not a blanket claim that every interruption/replay path in Hermes is resolved.

Why this matters for harness engineering

Modern harnesses increasingly cross process, sandbox, broker, provider and delegated-agent boundaries. Controls are therefore distributed operations, not merely UI state changes.

The draft provides a useful vocabulary for incident response and safety testing:

• distinguish decision, emission, receipt, enforcement and effect;
• identify every required enforcement target before making an “all stopped” claim;
• bind observations to stable instruction/attempt identity and content;
• preserve malformed, conflicting, duplicate and missing cases in reconciliation rather than dropping them;
• qualify negative claims by the population, source and observation window actually examined.

The Hermes connection-operation example adds one implementation-level corollary: do not let a presentation surface become the authority that proves its own success. Keep the authoritative state transition with the component that can observe the relevant external system, then project that state to the UI/model.

The Hermes stop example adds another: a detached worker is a separate enforcement target even when it was spawned by the foreground turn. Cancellation semantics must follow runtime ownership, not only the original parent/child relationship visible at dispatch time.

These principles complement HarnessRisk, which measures whether adversarial effects succeed across the harness lifecycle, Hermes, which tracks upstream harness behavior, and UHP security, which describes protocol security boundaries. None of them substitutes for the others.

Evidence boundaries

1. Work in progress. Internet-Drafts can change, expire or be replaced; revision -01 is not a stable standard.
2. Informational target. The draft defines evidence requirements rather than a normative agent transport or control protocol.
3. No UHP binding. No reviewed source establishes a standardized mapping from these evidence observations into UHP fields or events.
4. AIREP is separate and experimental. Its implementation status should not be promoted into IETF adoption or UHP adoption.
5. Hermes is an implementation analogy, not draft adoption. Its connection-operation and stop-propagation lifecycles preserve similar ownership/reconciliation distinctions but do not implement or claim the Internet-Draft.
6. Evidence is claim-scoped. Cryptographic integrity, receiver observation and effect observation establish different things; one should not be silently promoted into another.
7. Current-main is not stable release. Hermes PR #115616 is downstream of v0.21.3; it must not be attributed retroactively to that tag. Later release inclusion is a separate ancestry check.

Related pages

Read UHP lifecycle for protocol lifecycle semantics, UHP security for protocol security boundaries, Hermes for the upstream harness/runtime boundary, and HarnessRisk for lifecycle-oriented adversarial safety evaluation.

Primary sources

• IETF Internet-Draft — draft-abak-agent-control-delivery-evidence-01
• I-D announcement for revision -01
• AIREP implementation repository
• AIREP v0.2.0-alpha.1 prerelease
• Hermes PR #109517 — one connection operation for managed connectors and local MCP setup
• Hermes PR #110574 — managed connectors move onto the backend-owned connection operation
• Hermes PR #110843 — connection-card presentation follow-up
• Hermes PR #115616 — /stop reaches detached background delegation
• Hermes merge b7135906 — stop fan-out and interrupted partial-result finality
• Hermes Agent v0.21.3 / v2026.9.14