Installation

If you've never opened a terminal before, this page is written for you. Two commands are all it takes to go from nothing to a working sphere — a fully structured AI-run company folder — on your own computer. This page walks through exactly what each command does, and what the installer builds before it hands control back to you.

Two things you need first

A terminal is the plain, mostly-black window already on your Mac or Linux computer where you type commands instead of clicking buttons. It's been there the whole time, usually filed under "Utilities" or found by searching "Terminal." git is a free tool that keeps a full history of every change to every file in a project — the same idea as Google Docs' "see edit history," except it applies to your whole project folder, not just one document. You don't need to understand git deeply to use AIBOS. You just need it installed, which on most Macs it already is.

You'll also want an AI coding agent — Claude Code or Codex are the two in common use — because that's what you'll actually talk to once the sphere exists. The installer builds the structure; it doesn't run agents for you.

The two commands

Type these into your terminal exactly as written, on the machine where you want your sphere to live:

git clone https://github.com/erikhansenepost-pixel/aibos.git ~/aibos
bash ~/aibos/installer/install.sh --name my-business --owner "Your Name"

The first line downloads the standard itself onto your computer — a copy of everything AIBOS is, sitting in a folder called aibos in your home directory. The second line runs the installer against that copy, and that's the command that actually raises your sphere.

The five flags, in plain words

A flag is just an option you add to a command, written as --something, to tell it exactly what you want.

What the installer actually builds

Running the second command does a lot of quiet work before it prints anything back to you:

• A founding file recording which version of AIBOS you're on, and a short statement of working spirit every sphere is stamped with at birth.
• A short entry-point file that any agent reads first, pointing to everything else rather than dumping it all at once.
• A core folder holding the sphere's own rules, its list of skills, its decision log, and the results of its own health checks.
• Empty folders ready to receive real work: for new projects, for nested departments, for read-only links to neighboring spheres, and for anything retired.
• Your lead agent — the first agent every sphere gets, already able to talk with you the moment installation finishes.
• The caretaker — a nightly maintenance job, exactly one per sphere, that tidies things up while you're not there. It's wired into your machine's own scheduler automatically, unless you skipped that with --uten-scheduler.
• Your own personal folder inside the sphere, seeded with a starting profile instead of left blank.
• A learning track, with the onboarding command already installed and ready to walk you through the basics.
• Version history for every file, starting from the very first save — the git piece, working from minute one.
• A guard that scans for dangerous commands before anything gets saved, so a destructive mistake can't slip through quietly.
• A health check, run once at the very end, comparing what got built against what the standard actually requires.

The success line

When everything checks out, your terminal prints something like this:

✅ Instans 'my-business' reist og COMPLIANT mot AIBOS 5.4.0

That's Norwegian for: "Instance 'my-business' raised and COMPLIANT with AIBOS 5.4.0." You'll also see a pointer toward a separate tool, /importer, for when you're bringing an existing project into AIBOS rather than starting from an empty folder.

Safe to run twice, and honest when it fails

Running the installer again — say, because your first attempt got interrupted — doesn't break anything or duplicate anything. Every step only writes a file if that file doesn't already exist, so a second run just confirms everything is in order.

The installer also checks its own work, and it's built to fail loudly rather than quietly hand you something broken. If that closing health check finds a real problem, the install stops right there and tells you exactly what's wrong. That's the same standard AIBOS holds itself to for the rest of the sphere's life: a health check every night, measuring distance from where you're supposed to be, rather than a box ticked once and forgotten.

Choosing when to update

Naming a version with --aibos-version is what makes your sphere a subscriber to the standard, rather than a one-time copy frozen at whatever release existed the day you cloned it. Updates are something you pull in yourself, one version at a time, and you can roll back if a new one doesn't land well. The nightly health check exists specifically to tell you how far your sphere currently sits from the version you've chosen, so upgrading is always a decision made with real information.