| 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.mddocs/current/company-os/governance-agent-workspaces.mddocs/current/company-os/collaboration-and-agent-work.mddocs/current/company-os/implementation-truth-matrix.mddocs/current/company-os/skill-contracts.mddocs/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:
HumanMemberAgentMember / 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
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>]
harness org member converge \
--id <id> \
[--project-binding <project-id>] \
[--business-access-ceiling <ref>]... \
[--created-by-member <member-id>]
harness org member list
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
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>]
harness org host --team <team-id>
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
- 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.
- Classify the request: view current org, route work to existing actor, propose
new business agent, update permission, pause/retire actor, or review
capability.
- 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.
- 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.
- Provision only approved tools, skills, budgets, and permissions. Do not infer
authority from a prompt, profile, avatar, or UI card.
- 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.
- Link initial Work records and maintained Docs so the actor's purpose is
observable.
- 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.
