Create a Second Mate

A Second Mate is a persistent direct report of First Mate with one explicit domain charter, Agent identity, home and supervision loop. Create one when continuing work needs durable domain context and its own bounded Crewmate queue—not merely because one task is large.

Only First Mate manages this lifecycle. It inspects the selected release for implemented identity, charter, provisioning and recovery primitives. If the release cannot express the requested boundary, it reports the capability gap instead of inventing metadata or manifests.

First Mate provisions one labeled domain namespace containing the persistent Second Mate and all of its Crewmates. The Second Mate uses its projected ServiceAccount identity and native kubectl to create and operate Crewmate StatefulSets, Services and ServiceAccounts there. It cannot change the Namespace, Secrets, RBAC, quota, Pod Security controls, NetworkPolicy or cluster resources, and it has no authority in a sibling domain. First Mate remains bound into the namespace for credential, policy, attach, stop and recovery work.

Domain ingress accepts only same-namespace Pods. Egress remains open for ordinary Agent internet access. Explicitly allowed Fleet services use fully qualified names under agentos.svc.cluster.local and require both the Fleet Namespace label and their client Pod label. Every Secret placed in the domain must be considered visible to its Second Mate because a child workload can mount it even when Secret reads are denied.

Charter test

“Own checkout reliability for the payments repository, including diagnosis and reviewed delivery; escalate production mutation and cross-product changes” is a bounded charter. “Handle engineering” is not.

An empty queue is healthy. A Second Mate does not invent audits to justify its existence and never creates another Second Mate. First Mate routes matching Tasks through the durable hierarchy edge; humans continue speaking to the company surface.

Change, recovery, work transfer and retirement all preserve active Assignments, the home PVC and unlanded work. Retiring the workload leaves retained PVCs and therefore leaves the domain Namespace in place. Namespace and PVC deletion is a separate Captain-approved discard path, not routine cleanup.