company-org-operator

name	company-org-operator
description	Operate Company OS Organization through governed Store/API/Action contracts. Use when a Governance Agent needs to inspect, propose, or manage Humans, Agent Memberships, OrgUnits, roles, reporting, permissions, and capability lifecycle without confusing standing actors with one-off Agent Team members.

Company Org Operator

Operate the Company OS Organization surface. This skill is a procedural capability, not product authority. It helps an Agent inspect and prepare Organization changes while respecting Human approval, permissions, and the boundary between durable Agent Memberships and one-off execution members.

Select the Company Store

Before reading or writing Company OS records, identify the Company Store. Prefer one of:

harness company current
harness --company <company-id> company org ...
HARNESS_COMPANY=<company-id> harness company org ...

If no Company is selected, harness company ... falls back to the current project-derived compatibility Store. Treat that as legacy compatibility, not the target Agent Company Workspace boundary.

To move legacy Company OS rows into a real Company Store, use harness company migrate-from-project --from-project <project-id|path> --id <company-id>. It copies only company_os_*.jsonl; it does not migrate execution records, provider sessions, prompts, or runtimes.

Load the contracts

Before proposing or executing a durable Organization change, read:

• docs/current/company-os/organization-and-actors.md
• docs/current/company-os/governance-agent-workspaces.md
• docs/current/company-os/collaboration-and-agent-work.md
• docs/current/company-os/implementation-truth-matrix.md
• docs/current/company-os/skill-contracts.md
• docs/current/company-os/governance.md

If repository files, schemas, API code, or acceptance checks conflict with this skill, the canonical implementation contract wins.

Use $dogfood-company-os when the task is the repeated cross-system self-hosting loop. This Skill owns only Organization reads and changes inside that loop.

Operating boundary

Organization owns who exists and who may act:

• HumanMember
• AgentMember / durable Agent Membership
• external collaborator or service actor
• OrgUnit
• role and reporting relation
• permission and authority profile
• membership lifecycle
• organization change proposal and approval path

Organization does not own:

• Work lifecycle or milestone status.
• Docs content and module structure.
• Finance commitments or payments.
• Mission, Mission Log, AgentTeamRun, MemberRun, provider-native sessions, or workflow steps. Historical Wave rows are Legacy read-only evidence only.

An AgentMember is the single durable company agent identity. Company membership stores only its canonical ActorRef(kind=agent_member) plus organization responsibility and permission-policy refs. A MemberRun is one execution attempt bound to that identity, TeamRun, workspace and provider session. Never create a second company-owned agent identity, copy runtime payload into Organization, or infer identity from display names.

Docs page integration

Business Docs pages may show responsible humans, AgentMembers, external collaborators, and services in right rails or module cards. Those UI appearances are references only. Organization remains the source of truth for who exists, who reports to whom, and who may act.

When a page contract references actors, require:

• explicit ActorRef kind: human, agent, external, or service;
• OrgUnit / membership / role when relevant;
• permission and capability refs when the page expects the actor to execute or approve an action;
• escalation path or Human gate for sensitive operations;
• no authority inferred from a profile card, avatar, prompt, skill list, or chat participation.

If a page exposes an Agent detail or governance panel, it may reuse UI components from Agent Team member pages, but the underlying object must remain a durable Organization actor, not a MemberRun.

Gateway-facing Agent Memberships

Business-facing Agent Memberships may receive input through external gateways such as WeCom, GitHub, email, social platforms, ecommerce/logistics systems, or future plugins. Organization owns the durable Agent identity, role, permissions, tools, skill refs, maintained Docs, accepted Work classifications, and escalation policy. The gateway service is an intake adapter or service actor; it does not grant authority to the Agent.

An Agent detail workspace should show Org identity, current Work records, maintained Docs, permission/capability refs, plugin capabilities, account/message/order or metric summaries, and recent gateway events. Agent-specific knowledge such as merchant FAQ, reply policy, content guidelines, customer requests, or evidence should remain in Docs/Relations and be loaded as context, not stored as a different Agent-specific database.

Plugin view extensions may add an Agent detail panel such as "merchant inbox", "social account status", "content performance", or "logistics blockers". The panel must render Company OS records or scoped connector projections and link back to source Documents, Work records, and evidence. It must not infer authority from a logged-in platform account, phone session, profile card, or plugin installation.

For GitHub, $connect-github-company-os owns repository facts and delivery links. Organization owns which durable actor may triage, write, review, merge, release, or change repository permissions; a valid gh login does not grant that company authority.

Current interface state

Organization records exist through the Company OS Store/API. The first dedicated harness company org ... command family is implemented for inspection and Human administrative authoring of actors, OrgUnits, Memberships, declared actor status, and permission/capability refs.

Use:

harness company org list [--actor-kind human|agent|external|service] [--status <status>] [--unit <org-unit-id>]
harness company org query --actor <actor-id> [--actor-kind human|agent|external|service]
harness company org query --unit <org-unit-id>
harness company org query --membership <membership-id>
harness company org create-human \
  --id <human-id> \
  --display-name <name> \
  --responsibility <summary> \
  --authority <human-admin-id>
harness company org create-agent \
  --id <agent-membership-id> \
  --display-name <name> \
  --role <role> \
  --responsibility <summary> \
  --authority <human-admin-id> \
  [--execution-agent-member-ref <agent-member-id>] \
  [--skill <skill-id> --tool <tool-id> --permission <policy> --capability <capability>]
harness company org create-unit \
  --id <org-unit-id> \
  --name <name> \
  --purpose <purpose> \
  --authority <human-admin-id> \
  [--parent-unit <id> --human-lead <human-id> --agent-lead <agent-id>]
harness company org add-membership \
  --unit <org-unit-id> \
  --actor <actor-id> \
  --actor-kind human|agent|external|service \
  --role lead|member|advisor|observer|external_partner \
  --authority <human-admin-id>
harness company org transition-actor \
  --actor <actor-id> \
  --actor-kind human|agent|external|service \
  --status active|invited|paused|ended|archived \
  --authority <human-admin-id>
harness company org update-permissions \
  --actor <actor-id> \
  --actor-kind human|agent|external|service \
  --permission <policy-ref> \
  --authority <human-admin-id>

The nested operator aliases are also available:

harness company org actor list
harness company org actor show --actor <actor-id>
harness company org actor create-human --id <human-id> --name <name> --responsibility <summary>
harness company org actor create-agent --authority <human-admin-id> --id <agent-id> --name <name> --role <role> --responsibility <summary> --permission <policy-ref> --capability <capability-ref>
harness company org actor update-status --authority <human-admin-id> --actor <actor-id> --status active|paused|ended|archived
harness company org unit list
harness company org unit show --unit <org-unit-id>
harness company org unit create --authority <human-admin-id> --id <unit-id> --name <name> --purpose <purpose> --human-lead <human-id> --agent-lead <agent-id>
harness company org unit update-status --authority <human-admin-id> --unit <unit-id> --status active|paused|archived
harness company org membership list
harness company org membership assign --authority <human-admin-id> --unit <unit-id> --actor <actor-id> --actor-kind human|agent|external|service --role lead|member|advisor|observer|external_partner
harness company org membership update-status --authority <human-admin-id> --membership <membership-id> --status active|invited|paused|ended

Current v1 boundary:

• Writes use the existing Human administrative authoring surface. The authority must be an active Human with company_os.admin.
• The CLI does not yet implement a governed OrgChangeProposal lifecycle, multi-party approval workflow, promotion policy, retirement evaluation, or capability-review record type.
• For permission expansion, new durable actors, or org-structure changes, report the write as administrative v1 and preserve the follow-up need for a governed proposal/approval path.
• A Agent Membership record is organization identity and authority context. It is not an Agent Team MemberRun, provider-native session, or runtime health row.

ADR 0052: AgentMember Identity Cutover CLI

ADR 0052 (docs/decisions/0052-nested-agent-teams-are-the-agent-organization.md) establishes durable AgentMember identities as the Agent Team Organization foundation. The cutover CLI (harness org) manages durable identities independently of runtime sessions, compatibility registry rows, or one-off MemberRuns. Use these commands when creating, converging, inspecting, or auditing durable AgentMember identities and their Host authority relationships.

Durable members

# Create a canonical AgentMember identity through the trust-operation ledger
harness org member create \
  --name <name> \
  --description <description> \
  --role <role> \
  [--id <id>] \
  [--provider-profile <profile>] \
  [--model <model>] \
  [--workspace-policy <policy>] \
  [--project-binding <project-id>] \
  [--business-access-ceiling <ref>]... \
  [--status active|paused|retired] \
  [--created-by-member <member-id>]

# Converge a compatibility AgentMember (members.jsonl) into a durable member
harness org member converge \
  --id <id> \
  [--project-binding <project-id>] \
  [--business-access-ceiling <ref>]... \
  [--created-by-member <member-id>]

# List all durable members (latest-row-wins projection)
harness org member list

# Show a single durable member by id
harness org member show --id <id>

Durable member status: Active, Paused, Retired. Converge maps compatibility statuses deterministically (Stale/Closed/Closing → Paused; Active/Starting/Idle/Busy/Offline → Active). Re-running converge produces the same row; it never silently rewrites an existing identity.

Bootstrap, host resolution, and audit

# Bootstrap compatibility Host authority before canonical Mission/Team authoring
harness org bootstrap-lead \
  --team <team-id> \
  --name <name> \
  --description <description> \
  --role <role> \
  [--provider-profile <profile>] \
  [--model <model>] \
  [--workspace-policy <policy>] \
  [--project-binding <project-id>]

# Resolve the Host authority for an AgentTeam
harness org host --team <team-id>

# Validate organization topology and Host-authority state
harness org cutover-audit

For new authoring, create the durable Host Agent first, then the Mission and ExecutionNode, and finally team create --mission-id ... --host-agent-id ... --node-id .... host resolves the one canonical host_agent_id. cutover-audit validates flat topology, one-Team-per-Mission identity, Host existence, and Node placement. bootstrap-lead remains a compatibility helper; it does not define a second Host-authority field.

When to use cutover vs. company org

Surface	Scope	Store
harness member-trust mutate	Canonical AgentMember identity for Agent Teams	agentfirm_trust_operations.jsonl
harness company org	Company OS Agent Memberships, Humans, OrgUnits, Memberships	Company Store (company_os_*.jsonl)

The cutover CLI lives at the Execution Space level and feeds the Agent Team kernel. Company OS organization records are a separate durable surface. A Agent Membership may link to an AgentMember via --execution-agent-member-ref, but the two surfaces are independently authored.

Governance model

The first Company OS layer is governance:

• Human Principal / Constitution Owner sets company direction, the root constitutional envelope, and required Human gates.
• Lead Agent manages Governance Agents.
• Docs Governance Agent owns company memory structure.
• Work Governance Agent owns Work routing and commitment visibility.
• Finance Governance Agent owns money state and finance controls.
• Org / HR Governance Agent owns actors, roles, authority, capability, and lifecycle.

Business Agents sit under Org / HR governance. HR/Org may identify capability gaps, reuse existing agents, request temporary execution, propose a new Agent Membership, provision approved tools/skills/permissions, and later evaluate, adjust, or retire the actor. Skills are tools; they never grant authority.

Root Company delegation model

Model the operating hierarchy as durable Organization truth:

Human Principal / Constitution Owner / required Human gates
  -> Company Lead
     -> Governance Leads and Domain Leads
        -> bounded Agent Memberships, Humans, services, or external collaborators

The Supervisor preserves intake provenance, runtime delivery, emergency control acknowledgements, and runtime generation. It is not a Company actor, grantor, work planner, or source of business authority. The Company Lead continuously triages accepted Human intent and Company-wide Work, balances priorities against explicit availability/capacity, assigns accountability to the right Domain Lead, and replans when evidence, blockers, or capacity changes.

A Domain Lead may autonomously delegate operational work only inside the currently implemented policy and its declared responsibility, accepted Work classifications, data/tool scope, budget/permission ceiling, and capacity. Recursive child-grant issuance and approved-template Agent Membership creation are target capabilities until the hierarchical grant lifecycle and authenticated transport are implemented and accepted.

Every delegation attenuates authority: the recipient gets only the subset needed for the Work, never broader access, spending, approval, legal, organization-change, or external-commitment authority than the delegator holds, and a child grant must be strictly narrower in at least one authority-bearing dimension. Delegated work keeps one accountable owner and an explicit Work ownership and delivery in Work; provider subagents and MemberRuns do not become durable reports.

Current truth is the Human-admin Organization CLI v1 plus canonical AgentMember membership projections. Target truth is one hierarchical ScopedPermissionGrant family with exact root constitution/generation/digest, parent and approved-template lineage, bounded action/module/project/GitHub scope, TTL/budget/concurrency/depth ceilings, atomic sibling reservations, and ancestor expiry/suspension/revocation fencing. Skills, runtime receipts, or danger-full-access never substitute for that grant. Do not describe target fields, autonomous child creation, or effective-authority UI as implemented.

Route to a Human queue only when policy names a Human gate, the action would expand authority or Organization, a protected effect is requested, no safe bounded actor has capacity, or policy/evidence conflict cannot be resolved. Routine prioritization, routing, status updates, and bounded execution belong to the Company Lead and Domain Leads rather than a universal Human approval queue. Apply the decision test: known policy, reversible effect, bounded blast radius, and no material external commitment may proceed autonomously with audit; otherwise route the exact exception reason and evidence. Current Organization CLI v1 does not implement this full delegation policy lifecycle; record unimplemented controls as partial or planned.

Safe workflow

1. Inspect the actor, org unit, role, and permission context before proposing a change. If the request comes from a Docs page, inspect its page contract and related Work records so the actor is linked to the intended business responsibility.
2. Classify the request: view current org, route work to existing actor, propose new business agent, update permission, pause/retire actor, or review capability.
3. Prefer reuse. Check whether an existing Human, Agent Membership, external collaborator, service, Agent Team, Dynamic Workflow, or Host execution path can do the work before adding a durable actor.
4. For new actors or permission expansion, use the Org CLI only when the Human administrative boundary is acceptable; otherwise prepare an Organization change proposal and route required Human/Lead approval once that lifecycle exists.
5. Provision only approved tools, skills, budgets, and permissions. Do not infer authority from a prompt, profile, avatar, or UI card.
6. For delegation, prove the parent relation and calculate the recipient's effective ceiling as an explicit subset of both Organization policy and the Work's needs. Escalate instead of silently widening either boundary.
7. Link initial Work records and maintained Docs so the actor's purpose is observable.
8. Record evaluation and lifecycle changes as durable Organization records.

Validation checklist

• Actor kind is explicit: Human, Agent Membership, external collaborator, service, or one-off execution participant.
• Reporting line and OrgUnit are explicit.
• Role and permission set are bounded.
• Required approval exists for adding actors or expanding authority.
• Related Work records and maintained Docs are linked.
• Skill/tool list is treated as capability, not authority.
• AgentTeam MemberRun/provider session is not mistaken for a durable Agent.
• Docs pages show actor refs from Organization, not copied names or inferred permissions.

Report format

When handing off, state:

• organization capability status: implemented, partial, planned, or design-only;
• actor/org-unit ids;
• role and permission changes;
• approval refs;
• linked Work records and Docs;
• capability/evaluation evidence;
• remaining system gaps.