Hubs & distribution

In one line. Package what you built, publish it to a Hub, and install it into another project — so a solution you build once can run for many teams or tenants. You’ll be able to. Publish an agent (or a whole project) to a Hub, and install a published item into a different project, resolving its dependencies correctly. Where this lives. Studio ▸ Hubs (the registries), an object’s ⋮ ▸ Publish, and Studio ▸ Hubs ▸ Solutions ▸ Publish to Hub (whole-project publish).

Structure travels, data doesn’t

You’ve built something that works. The next team wants it. The next tenant wants it. You do not rebuild it by hand each time — you package it once and install it everywhere.

The single load-bearing idea of this whole page:

Structure travels; data doesn’t.

A package carries the shape of your solution — agent instructions, schemas, pipeline steps, guard rails, dashboards. It deliberately leaves behind everything that is local, private, or environment-specific: your documents, your vector index, your model credentials, your tenant ids. Those are either re-created empty at the destination, required to already exist there, or wired up at install time to the destination’s own objects.

That is what makes a package safe to share across teams and tenants: nothing sensitive ships. A published item is a recipe, not a copy of your data. The rest of this page is the three verbs that make this real: package, publish, install.

The Hubs surface

Studio ▸ Hubs shows two tabs — the two registries you’ll actually use:

Hub tab	What it’s a registry of
Solutions	The signed Solution marketplace — publish this project as a signed Solution, and install Solutions from a shared, environment-independent Hub.
Agents	Published single Agents (the Hub List screen).

The same Hub List screen also serves the other object registries — Teams (Multi-Agents), XFlows, Guard Rails, Functions — at their own routes; they are just no longer top-level tabs. Learn the screen once and you know all five.

Under the hood. Two distinct hub systems sit behind this surface. The object registries use a per-environment hub catalog with an admin approval workflow. The Solutions tab talks to an environment-independent signed Hub (/api/hub/*). They look similar; they are different stores. This page teaches both and says which is which at each step.

The Hub List — layout

Every object registry renders a two-pane layout:

List rail (left, ~400px): a search box; a card per published item showing its logo (or generated initials on a gradient when there’s no logo), name, tags, and “Created At”. As a consumer you simply see the items available to you.
Detail pane (right): the selected item’s title, logo, a facts grid (name, tags), a Suggested Prompts section, and the full rich-text description the publisher wrote.
Empty states: “No Results” in the rail, “No Selection — please select an item” in the detail pane.

The single action you’ll use as a builder is the Import button in the detail pane.

The status model — published / installed / available

Every published item carries a status. As a builder, what you mainly care about is whether an item is available to import; the other statuses are the moderation lifecycle behind it.

Status	Means	Who sees it
Active	Pending review — published but not yet approved. (The label says “Active”; read it as “pending”.)	Admins, in moderation.
Approved	Cleared for use — this is the catalog everyone imports from.	Everyone.
Rejected	Turned down in review.	Admins.
Inhouse	Curated / featured, with suggested prompts attached.	Everyone (merged into the import catalog).

Tip. As a consumer the rail only ever shows you Approved items (with Inhouse merged in). The [All] [Approved] [Active] [Rejected] [Inhouse] filter chips and the status pills are admin-only — if you don’t see them, that’s expected, not a permissions bug.

Role-gated. The moderation buttons (Approve / Reject / Inhouse / Remove, plus Edit and Delete) only appear on the admin view of the Hub List. As an ordinary builder you publish and import; an admin approves.

Publishing

Two ways to start a publish

You can publish at two granularities:

A single object — open the object in its builder, use the ⋮ menu, choose Publish. This puts one Agent / Team / XFlow / Guard Rail / Function into the matching object registry.
A whole project — Studio ▸ Hubs ▸ Solutions ▸ Publish to Hub. This packages the entire project as a signed Solution on the Hub (see “The Solutions marketplace” below). The older Studio ▸ Project ▸ Publish form (the per-environment project template) still exists, but the signed Hub is the shipping path.

Both open a publish dialog. The single-object dialog is shown here; the Solution publish modal is covered under “The Solutions marketplace” below. The idea is identical: describe the package and confirm what ships.

┌─ Publish Your Agent - Contract Reviewer ───────────────────[×]┐
│ Choose a Template or Upload                                    │
│ [ Upload ] [img] [img] [img] [img]     (≤ 2 MB, ≤ 1024×1024)  │
│ Name *            [______________________________]            │
│ Description *     [ rich-text editor ..................... ]   │
│ Tags              [ legal × ] [ nlp × ] [ + add ]  (max 10)    │
│ Publisher Name    [______________________________]            │
│ Template Setup Tabs  [ Data Sheet ▾ ]   (Data Sheet / Drive)  │
│ ── shown ONLY if this object needs them ──                    │
│ LLM Model Description *   [ "any GPT-4-class model" ]          │
│ View Description *        [ "the invoices view" ]              │
│ Datasheet Description *   [ "the line-items sheet" ]           │
│                                          [ Publish ]          │
└───────────────────────────────────────────────────────────────┘

What every control does

Control	What it does	Notes
Logo	Upload an image or pick one of 4 defaults.	Upload ≤ 2 MB, ≤ 1024×1024 px (checked in-browser).
Name *	The published name.	Required; letters/numbers/`_`, must not start with `_`; max 100 chars.
Description *	Rich-text explainer for importers.	Required. This is what someone reads before importing.
Tags	Searchable labels.	Up to 10. For a project Solution, at least 1 tag is required to publish.
Publisher Name	Your name / org.	Max 100 chars.
Template Setup Tabs	Which extra surfaces ship — Data Sheet, Drive.	Object publish. The project Publish form has a much larger “Template Setup Tabs” panel (which Studio modules appear in the tour).
Dependent-description fields	One required textarea per unresolved dependency the object references.	Appear only when the object actually has that dependency — see next.
Publish	Publishes the package.	Enabled only when the form is valid (and, for a project Solution, has at least 1 tag). For an item that already exists this button reads Update.

The dependency closure — EMBED, DECLARE, REBIND

When you publish, the platform walks the object’s dependency closure — every other object it needs to run — and classifies each one. This is the heart of “structure travels, data doesn’t”, and it’s why some dependency fields appear in the dialog and others don’t.

Class	Meaning	Ships in the package?	Example
EMBED	Pure configuration, carried by value. Re-created with fresh ids at install.	Yes — by value.	An agent’s sub-agents, its skills / skill packs, its guard rails.
DECLARE	An environment capability that must already exist at the destination. Verified at install; never shipped.	No.	The LLM model class; MCP servers and their credentials; platform version.
REBIND	A project-local data dependency. The package carries a named slot + description, and the importer wires it to a local object at install.	No (the binding travels, not the data).	A knowledge collection; a legacy View or Datasheet the agent reads.

Concretely, for the Contract Reviewer agent above: its sub-agents and guard rails EMBED — they travel inside the package and are re-created in the destination project. Its LLM model DECLAREs — the package says “I need a GPT-4-class model”; it does not carry your endpoint or API key. Its knowledge collection / view / datasheet REBIND — the package carries a slot described in plain language, and the importer maps it to one of their collections at install.

This is why the dialog grows extra textareas: for each REBIND (and DECLARE) dependency the object actually has, you write a one-line description so the importer knows what to pick. “LLM Model Description: any GPT-4-class chat model.” “Datasheet Description: a table of contract line-items with clause and risk columns.” Those descriptions are shown to the importer at the exact moment they choose the local object to bind.

Tip. Good dependency descriptions are the difference between an install that just works and one that confuses the next team. Write them for someone who has never seen your project.

Installing

Importing a published item into your project is the mirror image of publishing. Open the Hub tab for the object type, select the item, read its description, and click Import.

The import / install flow

Browse & select. Open the Hub tab (e.g. Agents), find the item, read its description and suggested prompts. The catalog you see is the Approved + Inhouse set.
Import. Click Import. If the item has no unresolved dependencies (common for XFlows, Guard Rails, and simple Functions), it imports straight away — you’ll get a “<Name> imported successfully” toast and it appears in your project.

Resolve REBIND slots. If the item does have dependencies, a configuration dialog opens. For each slot you must pick a local object:

┌─ Import: Contract Reviewer ────────────────────────────────[×]┐
│ This agent needs you to map the following to your project:     │
│ LLM Model *   [ Select a model ▾ ]                             │
│   "any GPT-4-class chat model"        ← the publisher's note   │
│ View *        [ Select a view ▾ ]                              │
│   "the contracts view"                                         │
│ Datasheet *   [ Select a datasheet ▾ ]                         │
│   "contract line-items table"                                  │
│                                          [ Import ]            │
└────────────────────────────────────────────────────────────────┘

Agents / Multi-Agents require an LLM Model, plus a View and/or Datasheet if the object referenced one. Functions vary by type: a prompt function needs a Prompt; a widget-download function cascades Dashboard → Widget; a view-download function cascades Collection → View. Each field shows the description the publisher wrote so you know exactly what to pick.

Execute. Confirm. The platform mints fresh ids for the embedded pieces and binds the slots to the local objects you chose.

The Solutions marketplace — the signed Hub

The object registries import from your environment’s own catalog. The Solutions tab is different: a marketplace browser over signed packages on a shared Hub.

The page opens on a collapsible Featured rail (the top-installed Solutions), then a split master–detail browser: a master list on the left (search box, category facet, sort by Most installed or Name) and a detail pane on the right for the selected Solution — its icon, a Signed pill, a version picker, the install buttons (Install here into the current project, or Install as new which names and creates a project), and a ⋯ menu (ship to the next ring, request production release, roll back, remove from Hub). Stat tiles show installs, module/model counts and the current version, above four inline tabs:

Detail tab	What it shows
Overview	Summary, the environment promotion ladder (dev → stg → prod, with each ring’s version), the signature & compatibility check, and adoption stats.
Setup guide	The publisher’s markdown guide, rendered inline.
Version history	Every published version with its summary, publisher and date.
Samples	Sample/demo files shipped with the Solution, downloadable.

Publishing here is the header’s Publish to Hub modal: name, version, category, summary, a listing icon, the setup-guide markdown, optional sample files and a demo entry point (where “Run demo” lands after install). The receipt shows exactly what shipped — asset count, bytes, content hash — with secrets redacted.

Because packages cross environments, the marketplace layers on trust + preflight + approval:

Verify — the package is signed; the signature is checked before anything installs.
Preflight — Check install compatibility in the Overview tab lists each requirement as met or missing before you commit. The platform row is real: a Solution is stamped with the platform version of the ring it was built on, so installing onto an older ring fails preflight instead of failing later.
Credentials preview — the same check tells you up front “you’ll need to configure N credentials” (counts and where — connection keys, script secrets — never values), so the key-configuration work is known before install, not a surprise wall after.
Approval — some installs are approval-required and offer a one-click Approve & install. Shipping to prod is governed harder: it’s a request that lands in a superadmin Hub Release Approvals queue, and the target hub is frozen at request time — if the destination changes before approval, the approval is refused. Managing the Hub-server registry itself (which hubs you publish to and install from) is a workspace-Admin-only action.
Upgrades & rollback — an installed project shows an update banner when a newer version is published: upgrade in place (keeps documents, queues and history; auto-saves a rollback snapshot) or install side-by-side. Roll back returns the project to a prior published version.

What an installed object looks like afterwards

This is the reassuring part: an installed object is just a normal project object. An imported Agent shows up in your Agent Builder ▸ Agents list like any agent you built by hand. An imported XFlow appears in your XFlows. There’s no special “imported” mode to learn — once the REBIND slots are wired, it’s yours, editable in the usual builders, picked from the usual pickers.

Solutions vs Object Packages

There are two grains of packaging. Choosing the right one is mostly about where the result lands.

	Solution (whole project)	Object Package (single object)
You publish	An entire project	One Agent / Team / XFlow / Guard Rail / Function
Where it installs	Creates a NEW project (Install as new) or, from the marketplace, into the current one (Install here)	Drops into an EXISTING project
Use when	Standing up a complete, repeatable solution for a new team/tenant (“the whole Invoice Processing app”)	Adding one reusable piece to a project you already have (“just the Contract Reviewer agent”)
Maturity	Shipped — the established path.	Partly forward-looking — see below.

Watch out — maturity. The whole-project Solution path is the established, shipped way to distribute a solution today: publish a project, install it as a new project. The per-object Object Package path is partly forward-looking. What ships today is the per-object publish → import → REBIND flow you used above (single Agents/Teams/XFlows/Guard Rails/Functions, with dependencies rebound at import). The fuller Object-Package design — signed single-object packages with a formal EMBED/DECLARE/REBIND closure, an install wizard with schema-compatibility verdicts, upgrade-in-place, and a rollback ledger — is designed but not fully built. Treat EMBED/DECLARE/REBIND as the mental model (it already explains today’s behaviour); don’t expect the full wizard yet. When in doubt, ship a Solution.

Under the hood. The EMBED/DECLARE/REBIND trichotomy is realised in today’s UI as: the agent’s embedded config travels in the package payload (EMBED); the model/MCP are required, not shipped (DECLARE); and the import configuration dialog’s model/view/datasheet/prompt pickers are exactly the REBIND step. The named-slot + schema-contract install wizard is the design’s next increment.

Try it yourself

Publish an agent, then install it into a different project.

Part A — publish (in Project A):

Open an agent you’ve built — ideally the one from A3 · Your first agent — in Agent Builder ▸ Agents.
Open its ⋮ menu and choose Publish.
In the dialog: pick a logo, give it a clear Name and Description, add a couple of Tags (e.g. demo, extractor).
Fill in any dependency-description textareas that appear — note which ones appear and tie each back to EMBED / DECLARE / REBIND (model = DECLARE; knowledge/view/datasheet = REBIND).
Click Publish. (If an admin approval workflow is in place, your item starts as Active / pending until an admin approves it.)

Part B — install (in Project B):

Switch to a different project, open Studio ▸ Hubs ▸ Agents.
Find your agent (it must be Approved to appear), select it, read the description.
Click Import. When the configuration dialog opens, map each REBIND slot to a local object — pick this project’s model, and its view/datasheet/collection as prompted.
Confirm. Then open Agent Builder ▸ Agents in Project B — your imported agent is there as a plain project agent. Open it; everything resolved to this project’s objects.

You just moved a solution between projects without copying a single document. Structure travelled; data didn’t.

Where to go next

B10 · Package & ship a solution — the full publish-and-install walkthrough on a real solution.
A3 · Your first agent — build the agent you’ll publish.
D1 · Collections & schema — the data dependencies your packages REBIND to.
R0 · Glossary — Solution, Object Package, Hub, EMBED / DECLARE / REBIND.