Apps & Marketplace

#Two things under one word

Marketplace is the shop inside your workspace: every module sSystm has, with a switch. That is the part most people use.

Underneath it is something less obvious and more interesting: a workspace can publish its own apps. An app is a small piece of code you wrote, running in the same place the built-in modules run, adding its own commands to Command Center. If your agency has a process nobody else has, this is where it stops being a document and becomes something you can ask for in a sentence.

#Turning modules on and off

The Marketplace lists every module, grouped by suite, and each one is in one of three states:

The switch is the same truth the sidebar reads, so switching a module on in the shop makes it appear in navigation, and switching it off removes it. Nothing is deleted by switching off — a module you turn back on has the data it had.

The lock is enforced by the server, not by the button. That is why a locked module does not offer to install and then fail: showing “install” on something the server will refuse would be a promise made and immediately broken.

#What an app actually is

An app is three things together:

• A Worker — the code that does the work, as a set of files.
• A purpose — one sentence, in the words your team would use, describing what the app is for. It is how a spoken request finds its way to this app rather than another.
• Its tools — the individual things it can do. Each has a name, a description the model reads when choosing, a schema for its arguments, and the clearance level a person must hold to call it: operator, admin or owner.

That last field is the important one. An app declares what its tools require, and the core enforces it before the app is ever reached — the same check the built-in modules go through, from the same table. An app cannot grant itself an audience it was not given, because it is not the thing doing the checking.

#How publishing works

Publishing runs in a fixed order, and it stops at the first thing that is wrong rather than half-completing:

1. Validate. The manifest is checked: a lowercase-kebab app id, a title and purpose, at least one file, and every tool carrying a real clearance level. Tool names must be unique across the whole workspace — including the names the built-in modules already hold — and a collision is refused here, before anything is uploaded.
2. Migrate. If the app ships database tables, the SQL runs against your own database first. If it fails, nothing is published.
3. Upload. The Worker is uploaded into sSystm’s app namespace under a name derived from the app id.
4. Register. The app and its tools are recorded, and Command Center can call them immediately — no redeploy of sSystm, and no waiting.

Publishing again with the same app id replaces what was there. Send the complete app every time: tools you leave out are dropped, and files you leave out are gone. There is no merge with the previous version, which is deliberate — a half-remembered publish that quietly kept old code would be far harder to reason about than one that replaces.

#Where the code runs, and where the data stays

These are two different questions, and the answers differ.

The outbound restriction is worth being explicit about, because it is the part that would otherwise be quietly missing. An uploaded app holds, for the length of one call, access to a customer’s database. Without a gate it could simply post that somewhere. So every outbound request an app makes is checked against the one address the core handed it for that call, and everything else is refused with a readable error and a log line. There is no allow-list to maintain and nothing to keep in sync: the permitted address is whatever this call was given, and only for this call.

The limits behave the same way. An app that loops forever hits the ceiling in a fraction of a second and the call fails with a clear reason, rather than grinding on somebody else’s budget.

#Publishing from your own AI

Both halves are reachable over MCP, which is how most of this is likely to be done in practice: your AI writes the Worker, lists what tool names are already taken, and publishes.

• Listing is a read, and shows every app this workspace has published, with the tools each exposes and the clearance each requires. It is the way to see which names are taken before writing a new one.
• Publishing requires admin. An app becomes callable by everyone in the workspace, so it is not a change an ordinary member makes on their own.

Size is capped at 256 KB per file, 60 files, and 8 MB in total. That is a small app on purpose. A tool that reads a table, decides something and writes a row is well inside it; a bundled framework is not, and is not what this surface is for.

Like every other write over MCP, a publish waits in the approval queue for a person. See Security & tokens.