Marketplace
The catalog offers. Your sphere decides.
Every add-on here is optional, versioned, and declares itself before it lands — and every one is safety-scanned before it can run. Nothing installs itself.
How installing works
A closed loop, every time — nothing lands unchecked.
The catalog offers. Your sphere decides. Every add-on is a self-contained, optional, versioned package — and installing one always runs the same six checks, in the same order.
Browse the catalog and choose one — nothing arrives on its own, and nothing is installed by default beyond what your sphere already ships with.
Every add-on carries a plain manifest: what it is, who made it, and what it's allowed to touch. That declaration gets verified before anything else happens.
The add-on's version is checked against the exact version of AIBOS your sphere is running. A mismatch stops the install — it doesn't just warn you and continue.
Before any of it is allowed to land, the code is scanned line by line. Destructive deletes, a “curl-pipe-bash” that runs a remote script sight unseen, fork bombs that spawn processes until your machine chokes — all of it gets blocked automatically.
The files land in your sphere, and a matching entry goes into your sphere's own register — so you always know exactly what you're carrying, not just what you meant to install.
The nightly check runs once, on the spot, to confirm the new add-on hasn't broken anything. Green means it's done.
The safety scan is a gate: code that matches a dangerous pattern is blocked before it can ever run on your machine.
Uninstalling works the same honest way. Remove an add-on and AIBOS archives it, leaving a marker behind that points to exactly where it went. Nothing is ever silently deleted.
Seven kinds
Every add-on is one of seven kinds.
The name tells you what you're getting before you install it.
Skill (Ferdighet)
A routine your agents can run. Most of what you'll install is this.
Tool (Verktøy)
A concrete utility a skill or agent calls on to get one specific job done.
App (System)
A small system living inside your sphere — bigger than a single routine.
Integration (Kobling)
A connector out to something external — another service, another tool.
Rule-pack (Regelbok)
A rulebook: rules that get enforced, with a version number of their own.
Dataset (Kunnskapspakke)
A packaged body of knowledge, pulled in as one unit.
Agent-pack (Ansatt-pakke)
A ready-made agent that already knows its role before you turn it on.
The catalog
Thirteen capabilities, today.
Every one is optional, every one is versioned, and every one declares exactly what it works with. Grouped by what they're actually for.
vask — Norwegian for “wash.” Self-cleaning tidiness, both as things are written and again every night. Three levels: fix it automatically, ask you first, or block it outright. Every cleanup is logged and searchable.
The caretaker — the nightly background job. Tidies first, then inspects; checks whether the standard itself has moved forward; and writes back the patterns it keeps seeing as proposals, never committed without a human's yes. The backbone of the self-improving system.
Keeps documentation honest: read-before-you-edit, an auto-generated table of contents in every folder, and the nightly check catches it the moment docs and reality drift apart.
lager — Norwegian for “storage.” Keeps large files out of your version history without losing track of them: a manifest lists the path, checksum, size, and owner of every one. No cloud connection yet in this version.
The learning engine. A guided onboarding that helps you actually remember what you're taught, using techniques built on deliberate difficulty rather than spoon-feeding. Already installed the moment your sphere is born.
Answers “what did we do last time about X?” (/recall) by searching your sphere's own session logs. Plain text, never blocks your work, and hardened against prompt injection.
Brings a new agent (/foster) or a new person's workspace (/foster-person) into being: intake, a written mandate, a fixed setup routine, registration, and a trial run before it's ever called done.
Adopts an existing project into the standard without losing anything: 8 phases, 2 checkpoints where a human signs off, the project keeps its own identity, and an optional gradual mode.
Product management as discipline: five stages, eight enforceable agreements — a spec has to exist before building starts, QA is never the same person as the builder, and more — a three-layer product map, and a Now/Next/Later roadmap with an explicit never-do list.
A structured system for building the business itself: 12 pillars — including the “owner bottleneck” — each scored across 5 levels from ad hoc to self-reinforcing, reviewed every quarter.
The go-to-market map: 8 pillars — ideal customer, positioning, category, channels, content, sales, pricing, activation — each scored across 5 levels, on two clocks: the map moves quarterly, experiments run weekly.
The engine behind the maps above: pillars scored across five maturity levels, a queue of pending decisions, and a self-contained radar chart you can open as a plain HTML file — no network call, no AI model involved.
The safety rules for any agent that talks to the outside world — email, calendar. Every send is checked against an allow-list, every secret stays masked, and a playbook against prompt injection rests on one rule: anything arriving from outside is data to read, never an instruction to follow. A scanner checks every outgoing draft before it goes.
Already included
What's already there, before you install anything.
These aren't from the marketplace — they ship inside the standard itself, in every sphere, from day one.
Creates a new folder the governed way, blocking duplicates automatically.
Runs a piece of work through its whole life, from explore to archived.
Sorts incoming material into the right type and saves a permanent record.
Reviews what just happened and decides what's worth remembering.
Runs a reversible experiment, clearly marked until it earns a real place.
Runs the built-in health check and tells you exactly what's wrong, if anything.
Installs, checks, or removes an add-on from this catalog — this is the command behind every install on this page.
The full change-and-release workflow for the standard itself.
Roadmap
Honestly: what's next, and what isn't built yet.
Paid add-ons from other developers
Outside developers publishing paid add-ons through the catalog, with AIBOS taking a revenue share. Designed, not shipped.
Add-ons distributed from their own projects
The idea of a capability living in its own separate repository, pinned to an exact version, is worked out on paper. Today, every one of the thirteen above ships inside the standard's own repository — nothing is distributed separately yet.
Install one with /kapabilitet.
Raise your sphere first, then bring in whichever of the thirteen actually fits how you work.