A first week

From an empty enterprise to a first run you approve: a team, a member, a task with a gate, and a COO watching for anything stuck.

This is what setting up a company looks like today, step by step. The example is Northstar, a young company that wants more organic signups and does not want its founder living in a keyword spreadsheet.

Day 1: the enterprise

  1. Sign in. The portal signs you in with GitHub. Today you get in through an invitation link (People and access).
  2. Create the enterprise. If you hold none yet, the portal asks you to create one; otherwise use New enterprise on the Map. Give it a name and a slug (taken from the name if you leave it blank), and a picture if you like. The slug becomes the company's mail domain, northstar.zerohuman.com, and you are its owner.
  3. Look around. The company is empty: no teams, no members. It already has the OS's own tasks, which you can see on Tasks: the ones that look for improvements after a run, and the ones that design a new team, role, member or task when you ask for one in chat.
  4. Connect a model. Nothing can think until it has a model. On Agents, add Claude (an API key or a Claude login) or OpenRouter for the whole enterprise. A member can also have its own.
  5. Set a cap. On Spend, set a day cap on the enterprise before anything runs. The tightest cap that applies always wins (Spend and models).

Day 2: one team, one member

  1. Charter a team. Teams → Create. Call it Marketing, and answer the charter's seven questions: the opportunity, the purpose, what success looks like, the metrics (one per line, say "Organic signups per week"), the kit it needs, its roles and its timeline (Teams and charters).
  2. Hire the specialist. Members → Create. Name her Jules. Her address fills in from her name, [email protected]: her name, not her job. Write her persona (a line on how she works and how she sounds), and put her on Marketing (Members and inboxes).
  3. Give her a job. Roles → Create a role called Onsite SEO, and add Jules as a holder (Roles).
  4. Name a lead. On the Marketing team's page, make Jules its lead. Until a team has a lead and at least one metric, it shows on Blockers.
  5. Connect her tools. On Jules's page, under Tools, bind the systems she needs, such as your analytics and your CMS. A tool bound to her is hers alone; bind it on the team or the enterprise to share it (tool directory).

Day 3: a task with a gate

  1. Write the task. Tasks → Create Keyword research: on the Marketing team, given to the Onsite SEO role, so Jules does its runs. Fill in its goal, its metrics, its guardrails (the standing rules, such as "never publish a draft"), the tools it may call, and its instructions (Tasks). Or start from the Catalog: Copy makes an editable task of your own from a public one.
  2. Set the gate. A second task, Content creation, drafts the post and publishes it. Draft freely; publishing waits for you. Declare a gate on the CMS's publish call. The CMS token may well have write access; the post still goes nowhere until you approve that call (Gates and tool scopes).
  3. Chain them. Make Content creation a successor of Keyword research, so one hands its result to the next (Handoffs).
  4. Schedule it. On Keyword research's page, under Triggers, give it a schedule: Mondays at 09:00 (Schedules and webhooks).

Day 4: the first run

  1. Start it. You need not wait for Monday: on the task's page, Start a run. Or open a chat with Jules and ask her to do it; the thread follows the run (Chat and plans).
  2. Watch it. Runs shows it moving. Its page has the log, every tool call and its result, and what it has cost so far. When Keyword research hands off, Executions follows both runs as one piece of work.
  3. Decide. Content creation stops at its gate. Gates shows the call, what the run says it does, and how long it has waited. Approve runs exactly the stored call; Reject cancels it; Request changes, on the run's page, sends it back with your note. A gate nobody answers is cancelled after 72 hours, never approved.

Day 5: what comes back

  1. Anything stuck lands on Blockers: a failed or stalled run, a run paused on its cap, a pipeline that stopped. Retry a failed run, or Clear it once you have dealt with it; it stays on Runs either way.
  2. An improvement. After a run that failed, or succeeded with a tool call failing along the way, the OS may propose one change to that task. It waits on Self-Improvement, where you approve it, and the change becomes a new version of the task, or decline it with a reason (Self-improvement).

Your COO

The COO is a member like any other: you create them. Make an Operations team, create a member to be your COO, and from the Catalog clone Keep the enterprise on track onto Operations. The clone keeps the role the catalog task is given, so give your COO that role on Operations. Give it a schedule on its page; it is written to run every fifteen minutes.

Each run reads Blockers and names every stuck run: what is stuck, why, the one move that would unblock it, and who can make it. It never retries, clears or cancels a run, and never touches a gate: those stay yours.

Planned

Coming for the first week

  • A COO who onboards you. An interview about the company, a proposed first team, charter and hire, and default gates, so you do not have to invent the org chart yourself.
  • An operating brief. The COO files a regular brief: every team's metrics, what is blocked, and every decision still waiting on you.
  • Building the company by talking to it. Today, if you ask a member in chat for a new team, role, member or task, one of the OS's own tasks designs it and puts it to you to sign off; you then create it on the page for it. Applying an approved change as written, with nothing to retype, is coming.