A Worker Self-Report Is Not a Lifecycle Outcome
Aug 17, 2026
Adding a bounded AI worker looks like a subprocess feature. It rarely is. The real work is integrating package identity, lifecycle admission, host authority, provider capability enforcement, process supervision, payload storage, and empirical CLI behaviour — without turning the worker layer into a second workflow controller.
The design point that holds the rest together is simple: a worker's self-report must not become a lifecycle outcome directly. Observation, validation, and terminal-outcome recommendation are separate concepts. Disagreement should fail away from success.
The problem
A host that can spawn an AI CLI and read its transcript can appear to "dispatch work." That framing understates four recurring risks:
- treating source-tree knowledge of an engine as if it were the published consumer API
- storing worker payloads where they can leak into child environments or contaminate the repository evidence layout
- lacking a safe dispatch abstraction, so the worker path starts acting like a second controller
- treating "the CLI has a non-interactive command" as proof that every requested capability is enforceable
When those concerns collapse into one implementation, the system starts trusting the worker's own verdict. That is the quiet authority leak: the process that performed the work also nominates the durable success state.
What actually happened
One delivery that added native bounded worker dispatch stayed usable because it kept the layers apart:
- engine-free dispatch for the worker process
- host-side pure outcome derivation
- completion forwarding through the session host
- immutable external payload storage
- separately invoked live proofs
The critical spec rework was the outcome mapping. The host owned a total mapping from worker results to recommended terminal outcomes. Every row was tested, including substitution attempts. When the worker's report and the host's derivation disagreed, the path failed away from success rather than inventing a compromise.
Payload storage needed the same boundary discipline. A named external evidence root — required, defaultless, preflight-validated, and withheld from child environments — replaced an older in-repo temporary layout that was intentionally treated as legacy and non-reusable. Naming the contract mattered more than choosing a folder.
A published-package gate also mattered. Fake-backed work could proceed. Work that needed a new public engine surface correctly stopped until a published package exposed the required API. Once package bytes and public exports were available, the dependency-bound track resumed from a recorded preservation point rather than being rebuilt informally through deep imports or host emulation.
Evidence progressed deliberately: negative boundary fixtures and static no-second-controller checks; fake-provider tests; real engine-store integration; then segregated live proofs for specific capabilities. Unit tests were not treated as proof of CLI behaviour. Live timeout proof showed that the first cleanup stage was sufficient in practice; the later escalation stage remained covered by automated tests and the limitation was recorded rather than overclaimed.
Residuals stayed narrow and explicit. One provider remained live-unproven for some capabilities; unsupported capability mappings were refused rather than papered over with fallbacks. Credential management, payload retention policy, and broader isolation certification were deferred instead of invented.
The lesson
Bounded worker dispatch needs three explicitly separate concepts:
- Process observation — what the subprocess did, emitted, timed out on, or left behind.
- Output validation — whether the observed result satisfies the contract.
- Terminal-outcome recommendation — what durable lifecycle state the host is willing to record.
Only the host should own the third. A worker may recommend. It must not authorise.
Provider support should be capability-specific. A CLI that can run non-interactively is not automatically a CLI that can safely enforce every sandbox or write mode you want. Record the contract before live execution; represent unsupported mappings as refusals.
The broader principle
High-boundary worker features are authority-and-evidence integration problems. Package identity, lifecycle authority, payload externality, and live provider behaviour are separate concerns. Collapsing them produces either unsafe shortcuts or unverifiable "it ran" claims.
Gates should match that shape. Let independent safe tracks progress while blocking only the dependency-bound track. Preserve identity and provenance so implementation remains bound to the accepted design, not an earlier rejected draft. Keep static, fake, integration, and live evidence distinguishable through closeout.
How to apply it
- Start with a dependency gate whenever a planned capability depends on an unpublished external package or API; define what can proceed independently.
- Specify worker-result derivation tables and disagreement behaviour before implementing adapters.
- Require a named external evidence-root contract, including child-process environment treatment, before writing payload-store code.
- Record provider CLI contracts before live execution; refuse unsupported capability mappings instead of inventing fallbacks.
- Treat a live proof that exercises only the first cleanup stage as sufficient only when later stages have strong automated coverage and the limitation is recorded.
- Keep the worker layer from becoming a second workflow or recovery controller: no invented completion capability outside the public surface.
- Make terminal records easy to consume: final identity, final verification, residuals, merge status, and which earlier partial evidence is superseded.
