# Session ownership and handoff record

Rethinking Agents · v0.1 · October 1, 2026

**A port is a location, not an owner.** Use a supervisor unit, cgroup or container created for the task and retain its immutable identity. A PID can be reused; a name can point to a replacement; a detached process can outlive its parent.

## Before starting — NOT RUN

| Field | Record |
|---|---|
| Session, task and activation owner | UNKNOWN |
| Supervisor/container ID and creation identity | UNKNOWN |
| Lease ID / generation / issued-at / expires-at | UNKNOWN |
| Build or artifact identity | UNKNOWN |
| Expected endpoint and identity-check mechanism | UNKNOWN |
| Allowed bind addresses / port range | UNKNOWN |
| Descendant containment boundary | UNKNOWN |
| Cleanup authority and recovery owner | UNKNOWN |
| Inventory source and capture health | UNKNOWN |

Reserve a port by binding it, not by checking and later assuming it stayed free. Start the intended workload inside its ownership boundary. Verify session/build identity at the endpoint reached by the browser or test. A self-reported marker is useful routing evidence; it is not cryptographic authentication of a hostile server. Use the supervisor's trusted identity and stronger transport authentication where the threat model needs it.

## On conflict or restart

- Busy port: leave the listener untouched; choose an authorized alternative or stop with a conflict.
- Lost inventory: mark ownership UNKNOWN. Reconcile with the supervisor; do not infer it from a process name.
- Restarted supervisor or service: revalidate immutable identity and generation. Reject stale lease/stop requests.
- Parent exited: inspect the whole ownership boundary. A new process session does not remove a child from its container/cgroup.
- Cleanup failed: retain the inventory entry and report unresolved work. An attempted stop is not an acknowledgement.

## Retain a service deliberately — NOT RUN

- Original lease expiry: UNKNOWN
- Requesting and approving principal: UNKNOWN
- Approval recorded at: UNKNOWN; must precede original expiry
- Same workload identity and current generation verified: UNKNOWN
- New expiry and maximum lifetime: UNKNOWN
- Permitted clients/network scope: UNKNOWN
- Cost owner and teardown owner: UNKNOWN
- Revocation/expiry enforcement: UNKNOWN
- Receiving session acknowledgement: UNKNOWN

A late note cannot retroactively authorize an orphan. Retained work is independent of whether the task itself completed. This record does not implement a lease service; use an existing supervisor or orchestrator to enforce the recorded lifetime.

## Worked handoff — fictional, NOT RUN

Session A owns container C-A, generation 3, build B-42. Session B's check reaches B-41 on an occupied endpoint. B rejects the mismatched identity, leaves C-A running and selects a different authorized endpoint. A requests retention before expiry, naming the next owner and an expiry. A stale generation-2 cleanup is refused; the generation-3 owner later ends C-A and verifies absence. If that verification is unavailable, cleanup stays UNKNOWN.

## Review evidence

Record the before/after workload inventories, exact selected IDs, endpoint markers, lease decisions and teardown acknowledgements. The [runtime lab](https://rethinkingagents.com/research/harness-operations-lab.md) uses synthetic Docker workloads; its lease checks are reference policy decisions, not a production supervisor integration. Host-side helpers and remote jobs require their own ownership records.