Done is not a receipt

The agent finishes the patch. Tests pass. The scheduler sees exit zero and starts the next task. A development server is still running, the last external action has no acknowledgement, and a provider charge has not settled.

Those can all be true at once. Task completion is one decision. Effects, cost and workload ownership need their own evidence before the next action can safely depend on them.

Our earlier filesystem lab compared an invocation filter with a resource boundary. This follow-up asks a more operational question: what should the harness tell the scheduler after the worker stops? We built fixed contract fixtures and a small real Docker experiment, then packaged the useful decisions into a harness operations kit.

A useful receipt changes the next action

A receipt should identify the authorized task, the worker's claim, the independently checked postcondition and the state of consequential effects. It should also point to remaining workloads, unsettled costs and known gaps in capture. Those are separate fields because they can disagree.

A read-only review can complete without a diff. A failed workflow can have a confirmed partial effect. A denied invocation can follow an earlier action whose outcome remains unknown. A completed patch can leave a deliberately retained service, but that service still needs an owner and a valid lease.

The contract fixture deliberately refuses to advance after false success, missing evidence, contradictory effects or incomplete capture. It accepts a verified no-op only when the task permits one. This is constructed behavior in a small reference implementation; it is not a measured failure rate for coding agents.

An operator's Aider issue report (opens in a new tab) about exit status helped motivate this question. We have not reproduced that report. The fixture makes the broader distinction testable without relying on a particular client's bug or parsing a transcript for the word “done.”

A busy port does not grant ownership

We started two synthetic services in separate Docker containers. Each served its session, run, generation and build marker over internal loopback. No host port was published. The driver reached each service through its immutable container ID and checked the marker.

A second bind to the occupied port produced a conflict. Both original services still answered with their expected markers. A child started in a new process session remained observable inside its owner's container. Removing the first container left the second service answering correctly; final inventory confirmed both owned containers had been removed.

This is a narrow but useful composition: container ownership survives a child detaching from its parent process session. The experiment did not test every descendant escape, shared host helper, remote job or operating system. It also did not test a browser discovering the right service through a production reverse proxy. The markers are routing evidence within trusted fixtures, not authentication of a hostile endpoint.

The lease and stale-generation decisions are reference controller checks around those real containers. We used a simulated clock to require retention approval before expiry, and a simulated missing acknowledgement to preserve cleanup as unknown. These are explicit contract examples, not measurements of a production supervisor's recovery behavior.

Keep uncertain charges reserved

The mock budget ledger has ten abstract units. Eight concurrent requests each reserve three units. Atomic admission permits three and refuses five. A separate fixture keeps a six-unit reservation while an acknowledgement and cancellation outcome remain unknown. Settlement later records four charged units and releases the remainder.

The relevant invariant is settled charges plus sufficient outstanding reservations staying within the declared ceiling. An unsupported price must not silently become zero; an unavailable accounting store must not permit unreserved dispatch. Retry and fallback paths are billable attempts too.

This ledger is deliberately local and in memory. It does not establish distributed atomicity, provider billing bounds, routing completeness or real cancellation behavior. A price-bound violation is a broken contract, not a claim that a ledger can undo the charge. Existing gateways already implement reservation; the practical next step is to apply the budget contract to the gateway you actually run.

Preserve the contract when the model changes

Two synthetic adapter shapes normalize to the same receipt decision. Unknown schemas are rejected. A terminal denial stops the route; a known-safe transient failure has a fixed attempt ceiling; an unknown effect requires reconciliation. These checks demonstrate what we want an adapter contract to preserve.

They do not establish equivalence between models or compatibility with current provider SDKs. They also do not show that “permission denied” is better than a detailed explanation at preventing adversarial retries. That needs a separate model study. The useful implementation decision today is to keep machine-readable outcome classes, authorized recovery paths and enforcement independent of the worker's interpretation of an error sentence.

Start with the handoff that is currently unreliable

The lifecycle, budget and change scenarios in the harness boundary review have reference-fixture runs since October 23, 2026, including a LiteLLM 1.106.2 proxy whose per-key cap, with or without its database, did not hold against an unpriced model, a pricier fallback or a timed-out request; read those records before relying on a gateway budget. The operations kit includes a quickstart, receipt guide and JSON envelopes, session ownership record, budget contract, plugin authority inventory, incident packet and adapter/denial contract. The templates start with unknown fields and NOT RUN checks. They are ready to adapt to an actual workflow; filling them in does not certify it.

The inventory compares a fictional plugin update whose signature is valid but whose write grant, endpoint and execution location changed. The incident packet preserves a disagreement between tool output, a transient mutation and a receiver acknowledgement, including a missing capture interval. Neither is an automated scanner or redactor.

Run the lab and read its method, complete results and limits. Then map one failure case onto your existing scheduler or supervisor. The improvement to look for is concrete: a legitimate no-op accepted, a duplicate effect avoided, a service handed off with an owner, or an unknown outcome left visible until someone can resolve it.