Company Onboarding

Company Onboarding prepares AigenLabs Desktop to act like a practical Business OS for a company. It gives the agent a company workspace and setup contract so the COO-style assistant knows what the company is, what still needs setup, and how to avoid creating disconnected AI staff profiles.

It is not a separate runtime. Normal chat, tools, skills, profiles, sessions, Kanban, gateway, cron, and model routing still work the same way.

Business OS onboarding is the default company setup path for Desktop/business profiles. Until it is enabled, AigenLabs can still handle generic one-off agent tasks, but company, workflow, and AI staff surfaces should treat the profile as setup-required rather than production-ready. The declined state is kept only for legacy profiles that skipped earlier prompts.

What It Creates

Business OS onboarding writes files the existing runtime already understands:

Artifact	Purpose
SOUL.md	Adds the default COO / Business OS identity for the active AigenLabs profile.
memories/USER.md	Stores lightweight user/company memory.
workspace/company/AIGENLABS.md	Gives the company workspace short operating instructions.
workspace/company/company.manifest.json	Records the company setup contract, role list, staff profile creation policy, Kanban board naming policy, approval expectations, and readiness state.
workspace/company/company-setup-checklist.md	Gives the COO a readable setup sequence before building profiles or workflows.
config.yaml business_os.*	Stores the active profile's Business OS state: undecided until setup creates artifacts, enabled after setup, or declined for legacy compatibility.
terminal.cwd	Points Desktop/gateway sessions at the company workspace only when no explicit working directory was already set.

AIGENLABS.md stays short on purpose. It orients the workspace; it is not a full company database.

All Skills Stay Available

In the Business OS model, every AI staff profile can use every available skill.

Roles such as COO, Content AI, Sales AI, Finance AI, Customer Success AI, and Reviewer AI are role focus labels. They help route work and explain ownership, but they are not permission boundaries.

Use this language:

• All skills available
• Role focus
• Suggested owner
• Profile workspace
• Reviewer present
• Approval expected

Avoid this language:

• Allowed skills
• Required skills
• Locked skills
• Skill permissions
• Only these skills
• Business skills for this role only

Why The Manifest Exists

company.manifest.json is the setup source of truth. It tells the COO:

• which workspace belongs to the company;
• whether setup questions are complete;
• which roles are required or optional;
• which profile names are expected;
• that specialist profiles are not auto-created;
• that new AI staff profiles need user approval, shared company workspace, role context, and approval context;
• that every role uses skill_access: "all";
• which actions need explicit approval;
• which setup questions are still missing.

The manifest is not a runtime permission file. If a role says "Content AI", the profile still has access to sales, finance, research, coding, browser, and other skills when those are useful.

Why The Checklist Exists

company-setup-checklist.md prevents a common bad setup: creating profile names that are not connected to the company workspace or do not know their role.

Before treating the company as ready, the COO should:

1. Confirm the company workspace.
2. Read AIGENLABS.md.
3. Read company.manifest.json.
4. Read company-setup-checklist.md.
5. Confirm all profiles keep all skills available.
6. Confirm or create the COO/default profile.
7. Confirm or create the reviewer profile.
8. Confirm specialist profiles are not auto-created.
9. Suggest optional specialist profiles only after understanding the business.
10. Make sure company profiles use the shared company workspace.
11. Give each company profile role context and approval context.
12. Define approval expectations before external or durable side effects.
13. Define Kanban board names as department or workstream task scopes.
14. Create boards or workflows only after user approval.
15. Report missing readiness pieces clearly.

First Conversation After Onboarding

Provider onboarding can finish before AigenLabs knows the real company details. When Business OS is still undecided, the first fresh chat should guide the user through setup before implying that company operations, AI staff, or workflows are ready. If the user asks an unrelated one-off task, the app should handle it normally without claiming the Business OS setup is complete.

The assistant should act like a COO setup consultant, not a form. It should summarize what it already knows, explain why the next missing item matters, ask one to three prioritized questions, and accept unknown / not sure yet when the user is still clarifying the business.

The assistant should usually ask for:

• company or project name;
• what the company sells or builds;
• target customer;
• current stage;
• top 1-3 bottlenecks;
• first desired outcome.

This is normal chat guidance, not a separate wizard. If the user asks an unrelated one-off task, the app should still behave like normal AigenLabs.

After each answer, the COO should store durable facts with the existing Business OS context path and suggest the next practical use: a weekly operating review, first workflow/Kanban plan, AI staff profile mapping, approval packet, or report/handoff artifact.

Readiness Status

Company readiness answers a narrow question: is the Business OS company setup coherent enough to start company operations?

It can report:

• workspace created;
• AIGENLABS.md created;
• manifest present;
• checklist present;
• skill policy is all-skills-open;
• COO profile ready;
• reviewer profile ready;
• profile workspace mismatches;
• setup questions incomplete;
• approval expectations defined.

Incomplete readiness does not mean AigenLabs is broken. It means the company operating setup still needs context before the app should imply workflows or AI staff are production-ready.

Reviewer And Approval Expectations

A reviewer profile is recommended before real workflows because business work often has side effects: publishing, outreach, spending, pricing changes, handling PII, installing connectors, or writing to production/source systems.

This is a soft operating contract unless a separate hard policy wrapper is implemented. The runtime still uses normal AigenLabs tools and approvals.

Workflow Builder After Onboarding

Company onboarding gives the COO enough context to draft business workflows, but it should not start execution by itself.

Use this sequence:

1. Draft or edit the workflow in Workflow Builder.
2. Confirm stages, nodes, intended profiles, inputs, expected outputs, acceptance criteria, and approval gates with the user.
3. Name the Kanban board by department/workstream, not by a private staff memory. The slug is the stable id; the board name should be readable, for example Marketing Department, Sales Department, Product Department, or Company Operations. These are examples only; the COO can create different names that match the company's real departments or workflows.
4. Create a draft Kanban board only after confirmation.
5. Start the workflow only when the user is ready for Kanban runtime execution.

After board creation, the cards are ordinary Kanban tasks with dependency links and workflow metadata. The existing Kanban dispatcher remains the only worker runtime; Workflow Builder does not create a separate agent runtime.

Plain Flow

Business OS onboarding
-> company workspace
-> manifest + checklist
-> COO reads setup contract
-> profiles are created or checked with shared workspace
-> readiness status
-> draft workflow
-> start workflow after approval

The important rule is simple: onboarding should make the agent start with better business context, not reduce what AigenLabs can do.